From nobody Mon Apr 2 13:26:18 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F78112D941 for ; Mon, 2 Apr 2018 13:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYPFuWnZt0rn for ; Mon, 2 Apr 2018 13:26:13 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFE812D892 for ; Mon, 2 Apr 2018 13:26:13 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id u9so2926021qkk.11 for ; Mon, 02 Apr 2018 13:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qa4XekDVlg5P37HqInwzx964hqqCz48qo0IXi2XDUiQ=; b=D7ium78SbGQbrcvaJT9elgGFtkUWVL4ZHatw5uvTHSpP5Th5eViKecUO0Nr6c0BM8t YgLattHMutXbXJTJV18CXnFh+fiXFhjCmR1Cde+DNARf0asdT6xx8moiaVfG6Zyuqt2u ZDR9r9cODJQD5sMirriF2RvCz8Oo83mrKH4aTKj3WmRUviyjuyP/uvFGXLYxsNvj6+K+ JLOCJnVFi1iDcVKLoKrC7dTuq1Bn2chQUA293OiISwMfu4Dqp2ZumKUa311cDH/1k7Jc FaNbHiOzHDj3Ymg6HvnhfwYqWshG/4dvFALvGN8cyOJXFbip1Qx26Z15qUbYtbbpFVGu b2dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qa4XekDVlg5P37HqInwzx964hqqCz48qo0IXi2XDUiQ=; b=gMi3+MihYCEWtjQvxtmKgoywtml2PsghyZY+rtjCMcWb6lU6E070/9Rmlo0E4Suets aHOLSIdfPDQU7F3NSJaP4TQPV9ddJZxwj/VNifbQRs6W0jcn3Rd9S/Z3lJGo7qIuBgjo 3Plj+o17J8DlFC+mB9iCohwqgcb29G0GOTRt0MLixGH5ksWQoh9feKejawEEshRjjWfJ 0MnrxMPBkwtMwExbjluAeRuUvpDh1Hw5DcZ7+Gt8lzoCfwWZT57eKWMiZveDcomM6uBb smNLlWMNdfUIjfq9z5OGXDSPyIPbIx3j3K8F7J9mq4HdUpNtmbxWJLh4QD1GeYDIaX7V HmWg== X-Gm-Message-State: ALQs6tB0o8zDWhtRCmSGj4EQaITlhEoPD41M6pe1fet1F+sGA3IKMzyc TukVzcx3auQ40Or0E0G3NT5QXWVqY9QQMGFsslFJkg== X-Google-Smtp-Source: AIpwx4/YkTvaVYK3DctdJJ1vsDW7qhjMqWGG6A0Qcw9N4EwCe9KQyluKDfzdG3KmGoelVlBobmier2OznDYNNqB9wLE= X-Received: by 10.55.140.2 with SMTP id o2mr14959245qkd.298.1522700771952; Mon, 02 Apr 2018 13:26:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.56.97 with HTTP; Mon, 2 Apr 2018 13:25:51 -0700 (PDT) In-Reply-To: <7e489950-5f18-9ea8-5c49-d8e175a5606f@verizon.net> References: <7e489950-5f18-9ea8-5c49-d8e175a5606f@verizon.net> From: Nick Harper Date: Mon, 2 Apr 2018 13:25:51 -0700 Message-ID: To: Stephen Kent Cc: secdir@ietf.org, Leif Johansson , uta@ietf.org, IETF Tokbind WG , Eric Rescorla Content-Type: multipart/alternative; boundary="94eb2c06252a9d436c0568e366b5" Archived-At: Subject: Re: [secdir] SECDIR early review of draft-ietf-tokbind-tls13-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 20:26:16 -0000 --94eb2c06252a9d436c0568e366b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 22, 2018 at 8:00 AM, Stephen Kent wrote: > SECDIR *early* review of draft-ietf-tokbind-tls13-00 > > > > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. = These > comments were written with the intent of improving security requirements > and considerations in IETF drafts. Comments not addressed in last call > may be included in AD reviews during the IESG review. Document editors > and WG chairs should treat these comments just like any other last call > comments. > > > > This (very brief) document defines how to negotiate Token Binding for TLS > v1.3. Existing IETF documents (IDs) define this protocol and how to > negotiate it capability only for earlier versions of TLS. > > > > The first question that comes to mind is why there is a need for a new ID= , > instead of adding text to draft-ietf-tokbind-negotiation-10. I realize > that draft-ietf-tokbind-negotiation-10 is in last call, but the text here > is so small that it seems overkill to create a separate RFC. I=E2=80=99m = guessing > that the argument is that this document references TLS 1.3, which is not > yet an RFC, and thus the author is trying to avoid creating a down > reference problem with draft-ietf-tokbind-negotiation-10. Right? > That sounds right. My recollection of WG discussions on whether to add this TLS 1.3 language to draft-ietf-tokbind-negotiation was that it was unclear how the tokbind drafts would get sequenced with respect to draft-ietf-tls-tls13 in IETF last call and the RFC Editor's queue, and didn't want the tokbind drafts to get delayed waiting for draft-ietf-tls-tls13 to get published. > > > Section 2 notes that the format of the extension is the same as defined i= n > draft-ietf-tokbind-negotiation-10, so nothing new there. The section > cites two differences from the behavior in draft-ietf-tokbind-negotiation= -10, > which are described in just two sentences. Section 3 adds one paragraph t= o > deal with 0-RTT, a TLS 1.3 feature not present in earlier versions. Sect= ion > 4 is non-normative, but, presumably useful. The security concerns are > asserted to be the same as for draft-ietf-tokbind-negotiation-10, plus a > sentence discussing why the 0-RTT exclusion avoids other potential securi= ty > concerns. > > > > So, if folks don=E2=80=99t want to delay publication of draft-ietf-tokbin= d-negotiation-10, > I guess this is OK as a separate document, updating that RFC. > --94eb2c06252a9d436c0568e366b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 22, 2018 at 8:00 AM, Stephen Kent <stkent@verizon.net= > wrote:
=20 =20 =20

=20

SECDIR early review of draft-ietf-tokbind-tls13-00

=C2=A0

=C2=A0

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.=C2=A0 These comments were written with the intent of improving security requirements and considerations in IETF drafts.=C2=A0 Comments not addressed in last call may be included in AD reviews during the IESG review.=C2=A0 Document editors and WG chairs should treat these comments just like any other last call comments.

=C2=A0

This (very brief) document defines how to negotiate Token Binding for TLS v1.3. Existing IETF documents (IDs) define this protocol and how to negotiate it capability only for earlier versions of TLS.

=C2=A0

The first question that comes to mind is why there is a need for a new ID, instead of adding text to draft-ietf-tokbind-negotiation-10. I realize that draft-ietf-tokbind-negotiation-10 is in last call, but the text here is so small that it seems overkill to create a separate RFC. I=E2=80=99m guessing that the argument is that this document references TLS 1.3, which is not yet an RFC, and thus the author is trying to avoid creating a down reference problem with draft-ietf-tokbind-negotiation-10. Right?


That sounds right. My recollection of WG = discussions on whether to add this TLS 1.3 language to draft-ietf-tokbind-n= egotiation was that it was unclear how the tokbind drafts would get sequenc= ed with respect to draft-ietf-tls-tls13 in IETF last call and the RFC Edito= r's queue, and didn't want the tokbind drafts to get delayed waitin= g for draft-ietf-tls-tls13 to get published.=C2=A0

=C2=A0

Section 2 notes that the format of the extension is the same as defined in draft-ietf-tokbind-negotiation-10, so nothing new there. The section cites two differences from the behavior in draft-ietf-tokbind-negotiation-10, which are described in just two sentences. Section 3 adds one paragraph to deal with 0-RTT, a TLS 1.3 feature not present in earlier versions.=C2=A0 Section 4 is non-normative, but, presumably useful. The security concerns are asserted to be the same as for draft-ietf-tokbind-negotiation-10, plus a sentence discussing why the 0-RTT exclusion avoids other potential security concerns.

=C2=A0

So, if folks don=E2=80=99t want to delay publication of draft-ietf-tokbind-negotiation-10, I guess this is OK as a separate document, updating that RFC. =


--94eb2c06252a9d436c0568e366b5-- From nobody Tue Apr 3 04:30:10 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658C612E89F; Tue, 3 Apr 2018 04:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C11iLR_TH3Rf; Tue, 3 Apr 2018 04:30:05 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C94712E89E; Tue, 3 Apr 2018 04:30:05 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id 71-v6so15599242oie.12; Tue, 03 Apr 2018 04:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tfcaMVimnPuifGgsBn5bC6GPcjZrkEF6801aFHjJuDU=; b=skKuQYNqQ5PLVLF/XJ0Bm7EGegq/sBiZDPOcFi6GCHrNSpGqKg3RAbaj/fCnAfoTgO YWrTjsIzMdzeizEOwkjwFunZejf7z02CnfkWadzw/T8DF47yKXWrR4F3Lp6cxCWsZDWJ LBCPQdgckuUAuPOs8eMmQuHfn+ZU4Ea7IU34axTFi5Aduu5VIt5eaDtS6PUmysj1nOmG Aso16DzTutVpx1gFGkDnnYz9DIPIPLXhFPjhEG2jdVo9JF1zjbKPo7QlESEi3YucFj4d EUrjcszXLRDVIhGgllXwfXePTb5OYI6Fve7dJproCJWxNEDVCw/apFmBryS0QtZyMk8k kgeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tfcaMVimnPuifGgsBn5bC6GPcjZrkEF6801aFHjJuDU=; b=gC2D21BOKrrmZl6aJg2eIOmP3NZFzfPcZCurTuqOzlT2RSfQzpen63mK9fQb9Lmn+X DhJ2Dy+37/VWmD2xEvMRb1Qmk4BaxMM6YMIR8Amu8Z5KDN7SyYaJDQ7MreoB6GWERB5T 2lteNoq/GEd4pEGGgFx8HKD2XtpJlyEDU8ULT+AjYw1YtCdTtRABpejvW2crrh4hTeDb XBgkCGz6nph0Zexw+o+38r39gwYoP+hbGIgBk/nKypoFeM1dpb+MUwYx8WDH1fahqDJM DNkHU61pQdG9QxfhO2LZ6lbe5hPq/iGmEAhYhU9TyO6K6/D/k1Yry8JDCfbZS00l1AEd 4Wfg== X-Gm-Message-State: ALQs6tCJ5RWYmtjLHxLkYjV29MLUZt2AbE3kh3cQEXfVWWWS1hnvPbPp mosuTf0KPNXg9PoMAurLD9xiVCmCca92eXpwQ3c= X-Google-Smtp-Source: AIpwx48QAZg0IWbMw65FOT15vYSSPmhRQyb1+DZ7GyEUsujafORkeuN7crSE31xjEGTTHxABqBRLYDJGLGz4zdiwIU8= X-Received: by 2002:aca:dc04:: with SMTP id t4-v6mr7843528oig.28.1522755004662; Tue, 03 Apr 2018 04:30:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.155.70 with HTTP; Tue, 3 Apr 2018 04:30:04 -0700 (PDT) In-Reply-To: References: From: Alexander Mayrhofer Date: Tue, 3 Apr 2018 13:30:04 +0200 Message-ID: To: Charlie Kaufman Cc: "secdir@ietf.org" , "draft-ietf-dprive-padding-policy.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-dprive-padding-policy-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 11:30:07 -0000 Charlie, thanks for the detailed review. I will prepare an updated revision once the Last Call is over, so that the IESG can work on an updated revision. best, Alex On Sun, Apr 1, 2018 at 5:59 AM, Charlie Kaufman wrote: > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > > Summary: Ready to advance to Experimental if typos are fixed unless someone > wants to quibble with the details of the algorithm. The proposed algorithm > has an empirical study to back it up. > > > This document proposes a padding policy for encrypted DNS requests designed > to make such requests less susceptible to traffic analysis based on packet > length. RFC7830 specifies extension mechanisms to DNS to allow optional > padding but makes no recommendations concerning how much padding to use. > While no agreement is necessary to assure interoperability between the two > ends of a connection, this document gives operational guidance to > implementers of reasonable policies to apply. > > > There is a complex tradeoff between the privacy benefits of large amounts of > padding vs. the performance benefits of minimal padding, so there can be no > one "optimal" scheme. This document does a good job of enumerating the > important considerations for an implementer and the recommended strategy is > (in my opinion) a reasonable one for most scenarios. I believe, however, > that no padding (listed in Appendix A as a Non-sensible Padding Policy) may > be sensible in certain situations where performance is at a premium, and > that servers should take their cues from clients and omit padding in a > response if the client has omitted it in the request. > > > I disagree with the "disadvantage" listed in section 4.3 that generating a > pseudo-random byte per packet sent could be a "hindrance" on servers. High > quality randomness is not needed (e.g., ARC4 would work just fine), and so I > would favor a scheme like the one listed in section 4.4. But I don't believe > the document should be held up to debate this. If anything, publishing this > document would get more people thinking about the problem and perhaps find a > reason to revise it later. > > > Typos: > > Page 4: "pading" -> "padding" > Page 5: "(pseudo) which" -> "(pseudo) random values which" > Page 5: "transction" -> "transaction" > Page 6: "does apply only" -> "applies only" > Page 5: "inffective" -> "ineffective" > > > --Charlie > > > > From nobody Wed Apr 4 23:30:59 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22129126D74; Wed, 4 Apr 2018 23:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE8BmcZ4PwhY; Wed, 4 Apr 2018 23:30:52 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0138.outbound.protection.outlook.com [104.47.36.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23DC12426E; Wed, 4 Apr 2018 23:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eOd3y+pSu2Zcn7hIdwfPzk+4pAaPGubQoo8baCM8RQE=; b=LW0ugJrDM5c0HogPfQMdo18aYXSDCVOMilKUB1pppnwzEcaJhiYud/d7LRH/RM+zQuiFoKkcfey0ILVIl/V4uTUJqom8O4YARnm4hjUr6ieI6nfJL8+6QifptXShuaPv59YuJDnjLC4kmcL9d7/BehHbvHPP1AVA1EvwbwIiNnM= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0378.namprd00.prod.outlook.com (52.132.148.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.693.0; Thu, 5 Apr 2018 06:30:46 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d57f:b97f:30db:5eb2]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d57f:b97f:30db:5eb2%2]) with mapi id 15.20.0695.000; Thu, 5 Apr 2018 06:30:45 +0000 From: Mike Jones To: Russ Housley , Benjamin Kaduk CC: "secdir@ietf.org" , "draft-ietf-secevent-token.all@ietf.org" , "id-event@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-secevent-token-07 Thread-Index: AQHTxgx+n9kmL68NKUaCk4qM4oa4eKPlnPEAgAwkVDA= Date: Thu, 5 Apr 2018 06:30:45 +0000 Message-ID: References: <152218349510.5239.9026903316972844190@ietfa.amsl.com> <20180328125852.GC76724@kduck.kaduk.org> In-Reply-To: <20180328125852.GC76724@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [209.37.97.194] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0378; 7:1kCJbdBcU/s+I/LZZuP3CsYlr2pZNXvLl4mrr1iN4+VQI9naMKe1D+Eu86G/7GbkvUN9Zb1y8/i8DyC+btLOWHYZb0CnAU9z/qDE+xe4pvA+DCmkb9k8412jbDF86WbVZL35CxbTI4izw7uW6o7NVuhvfV1UoDB6EYltWK8SoCmIU5TaDg9P80kfqQ8eZ2/jJGmeKUtm2uZeBBak6ODsyilqFjCfcpMwhpQGfbEUsHqRZdNsq0FJI7WZC6UKJglY; 20:kfnhY0wkcaqPRgDnSFYzk/rRpakhcNPi7fhLP5ef3UcQ9IQr+lFuKSzRadj8eX4EgqGVbaUulcARs32VewUm5vboJnQlRTJ+pitUp7gf5hktD4Ycwv8K4TZ5N7cf+vVN6Z4vhlRM6Ji0o6SU8++mxsL/aXxbXspQcWMP0o/+4KU= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8aafeb23-06fd-47d7-1437-08d59abec3aa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:MW2PR00MB0378; x-ms-traffictypediagnostic: MW2PR00MB0378: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MW2PR00MB0378; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0378; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(376002)(346002)(39380400002)(396003)(13464003)(51914003)(189003)(199004)(377424004)(105586002)(229853002)(478600001)(5250100002)(25786009)(33656002)(4326008)(8676002)(6116002)(3846002)(81166006)(81156014)(8936002)(3660700001)(72206003)(5660300001)(66066001)(10290500003)(106356001)(3280700002)(74316002)(2906002)(305945005)(7736002)(2900100001)(97736004)(53936002)(53546011)(59450400001)(86612001)(6506007)(6246003)(55016002)(68736007)(2171002)(14454004)(6306002)(966005)(102836004)(9686003)(86362001)(26005)(10090500001)(446003)(316002)(486006)(6436002)(186003)(11346002)(8990500004)(110136005)(22452003)(54906003)(476003)(76176011)(99286004)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0378; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ZqcOuzi7WKZ4sPtxRngfMHVP1h3Dp8ddVSY6C/5em+HWpqjaczC4QqQVblnjtTNXRUtFm5YIobN3jHK3PdDlX5ldHYeY9RxNpNsaloJBdV5I6OEYHUcrEYuMJLts/5++/qz+tufeS8VLN7DfGexs6/UusP709XJbWYcjZ3cRrwjex+12aXNw1NheYTmWM3Fu5eFAi+6GhY790oXvsY87hsG5//hcwmFJVTenNn1x2W0luO1KzVwS3fUBGHXCKN46ACtJM+E8A5KvIWPPCFgld5Dtt/0ayW9qF/c2PSt3QuAhFpKdV5YH1kTDBP/oHiJBP+ai1Rbecr4cGSnRjE9q3WiEGeRMypJd4ih/AQNv/7K74TL6ECNLQmJ2NNGX1pmvfkg7LKTAQqwbnFD3lFyQB0KjctouVGPqMGP3gcnMbgQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8aafeb23-06fd-47d7-1437-08d59abec3aa X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 06:30:45.8889 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0378 Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-secevent-token-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 06:30:54 -0000 Hi Russ (and Ben), Thanks for the useful review, Russ. https://tools.ietf.org/html/draft-ietf-= secevent-token-08 is intended to address your review comments. See the inl= ine responses below. -- Mike -----Original Message----- From: Benjamin Kaduk =20 Sent: Wednesday, March 28, 2018 5:59 AM To: Russ Housley Cc: secdir@ietf.org; draft-ietf-secevent-token.all@ietf.org; id-event@ietf.= org Subject: Re: Secdir telechat review of draft-ietf-secevent-token-07 Hi Russ, On Tue, Mar 27, 2018 at 01:44:55PM -0700, Russ Housley wrote: > Reviewer: Russ Housley > Review result: Has Issues >=20 > I reviewed this document as part of the Security Directorate's ongoing=20 > effort to review all IETF documents being processed by the IESG. =20 > These comments were written primarily for the benefit of the Security=20 > Area Directors. Document authors, document editors, and WG chairs=20 > should treat these comments just like any other IETF Last Call comments. >=20 > Document: draft-ietf-secevent-token-07 > Reviewer: Russ Housley > Review Date: 2018-03-27 > IETF LC End Date: unknown > IESG Telechat date: 2018-05-10 >=20 > Summary: Has Issues >=20 > Process concern >=20 > A request for a telechat review of draft-ietf-secevent-token was=20 > assigned to me. However, there has not yet been an IETF Last Call=20 > announced for this document. Thanks for the review, and for pointing out the process nit. Getting on a telechat is pretty hard at the moment due to the large spike i= n documents we saw prior to the IESG cutover. I should still have time to = complete my AD review and issue the IETF LC with time to spare before 2018-= 05-10, though. Authors, please feel free to address Russ's comments in a new revision if y= ou can do so before the IETF LC is issued. Thanks, Ben >=20 > Major Concerns >=20 > All of the examples in Section 2.1 are non-normative. Instead of=20 > staying that in each of the subsections, please add some text at the=20 > top of Section 2.1 that says so. Done > I do not understand the first paragraph of Section 3. I think you are=20 > trying to impose some rules on future specifications that use SET to=20 > define events. Please reword. I reworked the beginning of the paragraph to try to provide more context fo= r the statements that follow. =20 > Minor Concerns >=20 > The Abstract says: >=20 > ... This statement of fact > represents an event that occurred to the security subject. In some > use cases, the security subject may be a digitial identity, but SETs > are also applicable to non-identity use cases. ... >=20 > Please correct the spelling of digital identity. Done (but then removed, per the next item) > I do not think this tells the reader when they might want to employ=20 > this specification. The following sentence from the Introduction does=20 > a better job: >=20 > This specification is scoped to security and identity related events. I replaced the previous statement in the abstract with a version of the sen= tence from the introduction that you cited. > In Section 2, the last bullet on page 5 talks about the "events" JSON=20 > object. The last sentence caught me by surprise, and I had to read it=20 > a few times to figure out the intent. The events object cannot be=20 > "{}", but the payload for an event in that object can be "{}". I=20 > think that a MUST statement about there being at least one URI string=20 > value would have helped me. The MUST statement that you asked for is now there (at the end of the previ= ous bullet item, where it makes better sense). Thanks again, -- Mike From nobody Thu Apr 5 15:57:53 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 934251267BB for ; Thu, 5 Apr 2018 15:57:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <152296907259.3805.9115964401570924207.idtracker@ietfa.amsl.com> Date: Thu, 05 Apr 2018 15:57:52 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 22:57:52 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-04-05 Reviewer LC end Draft Shaun Cooley 2018-03-06 draft-ietf-trill-over-ip-16 Donald Eastlake 2018-03-28 draft-ietf-teas-scheduled-resources-06 Daniel Gillmor 2018-03-26 draft-ietf-l2sm-l2vpn-service-model-09 Ben Laurie 2018-03-26 draft-ietf-6tisch-6top-protocol-11 Chris Lonvick R2018-03-06 draft-ietf-6lo-rfc6775-update-17 For telechat 2018-04-19 Reviewer LC end Draft Daniel Franke 2018-03-30 draft-ietf-mmusic-rid-14 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Steve Hanna 2018-03-30 draft-ietf-core-senml-14 Christian Huitema 2018-04-06 draft-ietf-stir-rph-03 Klaas Wierenga 2018-02-23 draft-ietf-nfsv4-layout-types-10 For telechat 2018-05-10 Reviewer LC end Draft John Bradley 2018-04-18 draft-ietf-acme-acme-11 Tobias Gondrom 2018-03-12 draft-ietf-tokbind-https-12 Paul Hoffman None draft-ietf-uta-mta-sts-15 Leif Johansson R2018-02-26 draft-ietf-homenet-babel-profile-06 Barry Leiba 2018-04-10 draft-ietf-bess-evpn-prefix-advertisement-10 Chris Lonvick 2018-04-19 draft-ietf-mtgvenue-meeting-policy-04 For telechat 2018-05-24 Reviewer LC end Draft Tina Tsou 2018-02-26 draft-ietf-softwire-dslite-yang-15 Last calls: Reviewer LC end Draft Scott Kelly 2018-04-23 draft-kucherawy-dispatch-zstd-01 Watson Ladd 2018-04-20 draft-hoffman-dns-in-json-13 David Mandelberg 2018-04-12 draft-ietf-dime-rfc4006bis-07 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-12 Taylor Yu 2018-04-24 draft-housley-suite-b-to-historic-04 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Ólafur Guðmundsson 2018-01-09 draft-ietf-opsawg-nat-yang-09 Dan Harkins 2018-05-31 draft-ietf-dtn-bpsec-06 Next in the reviewer rotation: Catherine Meadows Alexey Melnikov Daniel Migault Matthew Miller Adam Montville Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom From nobody Fri Apr 6 08:55:14 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB620127369; Fri, 6 Apr 2018 08:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523030019; bh=vQqfrTrJHVY7VPUMeGEpTZ9fJ5/PaRFRQE5r6zakcpA=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=lVQdMCu+9kbsukiqaH6X/1vw1rMkU49v7qaUdSbv1CxYAGo2vpexS8vag3Nj3V7KK cSQ89oRmgFKgE2+7II4xVABO9ud4sxQnSBU1Y7BZQ3IeNiCiYY1fmjZ0iZp2LpUqd1 cygLj0+z449QJGu9GOGuj8av1WdCoXHf+/zUUaMM= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Apr 6 08:53:38 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74426120724; Fri, 6 Apr 2018 08:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523030018; bh=vQqfrTrJHVY7VPUMeGEpTZ9fJ5/PaRFRQE5r6zakcpA=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=rKZRVvUD34XwZUSLT6zp0ejXGH6frAQ9CJXJVsCuhLSs3UIpwBWyNxMftGIKJuqM5 k3J5Cmo3Kj9cinnM5P7zM44PXLwhcDCDhlIXoab5cQ/MdCDRY29K51HiM/gNUI7LuG 1+bTuHaYYIBeJlAv2aZbfCMlRaz8zcl/Kq17wXKQ= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918D1120724 for ; Fri, 6 Apr 2018 08:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5KgmFfdau7A for ; Fri, 6 Apr 2018 08:53:34 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D719F1204DA for ; Fri, 6 Apr 2018 08:53:33 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id p67so1640073qke.13 for ; Fri, 06 Apr 2018 08:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=JkeN+vZqFL2KLFvrM4BBbEQjsTx3UeHKKE8Z41YEwus=; b=q7TAMqMRX+zYC1uBzy4/qFBpbmh9dd79WJmFUlNwkuPv25PXJqebqnuXsAVyaWTBfV 1BXXGb9h8b9g4Q44fWIi3gfy5PHMkfFjn5B31KN2z66nfsvWbsOSHNPjy8Zrk2JrqPhg BfzeFviNt8y+Ym45yW+uDGnG92YincAdkzjuAZMvHDHk3wu6TM2aoVnAQiH8LZYdYEGd cuDVn/lPsiYjjBhRM5bbXkUnumtmRGnrzolrDnMrYCsboyj7oirxboelV5m8ig3F5Xsx KIuUeAE9l95uF1ema4OiRzOuchyI+9cneOCjDJF9M/+a/eTehHa0poIChqGBi8QE3FUv fWjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=JkeN+vZqFL2KLFvrM4BBbEQjsTx3UeHKKE8Z41YEwus=; b=f6FuHmy6keXehbNbX+FH1JArOOPezTpA6QL7VNDZAI1eBS5Ldq1+hAN5UmaOubJkr8 PooHsCcXgA2pY6RNZjXEVaLAWNJZdN9qLcCAZRZiUxfKXXXrp2Oqecs/vdelCp4yrmXs KsM9tfmAYehcoflGvnb5VbtEw23bgD/iHdGtmyTBvXtBab/y+HUFYliShJS7cxBNRHO3 m2G47p9VzBrsqcFd5amsEz7bZbExR6vBcQLS3hkDvoCO19DxpwXZGiqWoYrKNINFbhGP HR+FFbXKnw0DQ44OkB7EtBltSGLP5vU4Od2fQ8ejWFQRs+US7TLclV3tbMRaXdAFKg92 9Fqg== X-Gm-Message-State: ALQs6tC800S+CZnogz+CJu5db/Cic8pFD27r1V45zQ4ms6Rp+8kAgzzb 2BnDhWVoBiWJ4Lt2YOQEzlEyEat8 X-Google-Smtp-Source: AIpwx49MgccAmKkMltPegF9AVv2CfJpyWiWj5Sj95Fjet9SyvkicQxl5zZASJ6kTe8kBLlbNFOPq+w== X-Received: by 10.55.128.67 with SMTP id b64mr37314717qkd.78.1523030012836; Fri, 06 Apr 2018 08:53:32 -0700 (PDT) Received: from DESKTOPGUNUVB7 (pool-98-117-240-238.hrbgpa.ftas.verizon.net. [98.117.240.238]) by smtp.gmail.com with ESMTPSA id e46sm8578550qtc.27.2018.04.06.08.53.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Apr 2018 08:53:32 -0700 (PDT) From: "John DAmbrosia" To: Date: Fri, 6 Apr 2018 11:53:36 -0400 Message-ID: <062c01d3cdbf$6d038070$470a8150$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdPNv2xSWAnLtDuEQaKrpeZ7Y7ntVg== Content-Language: en-us Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Precedence: list Cc: 'Paul Nikolich' Content-Type: multipart/mixed; boundary="===============7357751001451515574==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 06 Apr 2018 08:55:13 -0700 Subject: [secdir] [new-work] IEEE 802 Mar 2018 Plenary - New Study Groups X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 15:53:40 -0000 This is a multipart message in MIME format. --===============7357751001451515574== Content-Type: multipart/alternative; boundary="----=_NextPart_000_062D_01D3CD9D.E5F36710" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_062D_01D3CD9D.E5F36710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Members of the IETF; In the spirit of continuing cooperation between IEEE 802 and IETF, the following communication addresses new work items for information and potential coordination with the respective IEEE 802 WG. One of the first steps in the IEEE Standards Association's standards development process is the creation of a Study Group. Study groups are chartered to create a formal Project Authorization Request (PAR) document that includes a description of the project's scope and purpose. The following Study Group were approved at the March 2018 IEEE 802 Plenary - * IEEE 802.3 Bidirectional 10Gb/s and 25Gb/s Optical Access PHYs study group * IEEE 802.11 Broadcast Services Study Group * IEEE 802.11 Next Generation V2X (NGV) Study Group Further information about Study Groups may be found at http://www.ieee802.org/StudyGroups.shtml. Please note, per the IEEE 802 Policies and Procedures that a Study Group is chartered to operate until the next plenary session, a period of four months and, if it wishes to continue, must request a charter extension. Study Groups may also terminate between plenary sessions if their proposed project is approved by the IEEE Standards Association Standards Board. Additionally, within the IEEE 802 family of standards, there is a requirement that each new project proposal attaches additional documentation that describes its engineering feasibility, market potential, assurance of coexistence and distinct identity relative to previous standards (referred to as the "CSD" in 802, which also includes the "5 criteria"). The "Criteria for Standards Development (CSD)" used by IEEE 802 can be found in document: https://mentor.ieee.org/802-ec/dcn/14/ec-14-0028-00-00EC-csd-informative-ext ract.pdf Also, please note that IEEE meetings are open and may be attended by any individuals who register and fulfill any registration fees. Details regarding future IEEE 802 plenary meeting schedules may be found at http://802world.org/plenary/future-plenary-sessions/. Please refer to individual working groups for their interim meeting schedules. A listing of all working groups may be found at http://www.ieee802.org/. Sincerely, John D'Ambrosia Recording Secretary, IEEE 802 LMSC jdambrosia@ieee.org ------=_NextPart_000_062D_01D3CD9D.E5F36710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IEEE 802 Mar 2018 Plenary - New Study Groups

Dear Members of the IETF;

In the spirit of = continuing cooperation between IEEE 802 and = IETF, the = following communication addresses new = work items for information and potential coordination with the = respective IEEE 802 WG.

One of the first steps in the IEEE Standards = Association’s standards development process is the creation of a = Study Group. Study groups are chartered to create a formal Project = Authorization Request (PAR) document that includes a description of the = project’s scope and purpose.

The following Study Group were approved at the March 2018 = IEEE 802 Plenary –

·       = IEEE = 802.3 Bidirectional 10Gb/s and 25Gb/s Optical Access PHYs study = group =

·       IEEE 802.11 = Broadcast Services Study Group

·       IEEE 802.11 = Next Generation V2X (NGV) Study Group

Further information about Study Groups may be found = at http://www.ieee802.org/StudyGroups.shtml= . 

Please note, per the IEEE 802 Policies and Procedures = that a Study Group is chartered to operate until the next plenary = session, a period of four months and, if it wishes to continue, must = request a charter extension. Study Groups may also terminate between = plenary sessions if their proposed project is approved by the IEEE = Standards Association Standards Board.

Additionally, within the IEEE 802 family of standards, = there is a requirement that each new project proposal attaches = additional documentation that describes its engineering feasibility, = market potential, assurance of coexistence and distinct identity = relative to previous standards (referred to as the “CSD” in = 802, which also includes the “5 criteria”). The = “Criteria for Standards Development (CSD)” used by IEEE 802 = can be found in document:

https://mentor.ieee.org/802-ec/dcn/14/ec-14-0028-00-00EC-c= sd-informative-extract.pdf 

Also, please note that IEEE meetings are open and may be = attended by any individuals who register and fulfill any registration = fees. Details regarding future IEEE 802 plenary meeting schedules may be = found at http://802world.org/plenary/future-plenary-sessions/.  Please refer to individual working groups for their = interim meeting schedules. A listing of all working groups may be found = at http://www.ieee802.org/. 

Sincerely,

John D’Ambrosia

Recording Secretary, IEEE 802 LMSC

jdambrosia@ieee.org

------=_NextPart_000_062D_01D3CD9D.E5F36710-- --===============7357751001451515574== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============7357751001451515574==-- From nobody Fri Apr 6 09:12:49 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B57FF12EA76; Fri, 6 Apr 2018 09:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523030829; bh=j4rc9izduZWqNz40yDfTpDgUhj6jr21ZlPZKKKQm9c0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=pelPT6TrugReuKHR8o240DbvEl6wm+AerbXxdaiwSCwyfhQfJk1nFJkE+dZg0V2J2 5dvcg6ai+iZGHr9mwpM76zprsBJxZUO5vQubo5tgcU4n1bLcRBQFs57yTWlS06evfW ZBqsj4/szw7+uhQz3addBqkZRs1YR6LRIKjqEEx0= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Apr 6 09:07:07 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98504127136; Fri, 6 Apr 2018 09:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523030824; bh=j4rc9izduZWqNz40yDfTpDgUhj6jr21ZlPZKKKQm9c0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=jgbTyfTropZ50edTA42w2uZrCUet/6vkcswPHSeIJP8DxdCojVphSUliZKikQxfzZ PqZA+Lrf9zviMx0+gAqEpl8ERv80WaCsruAmCl55TwiWmO6IbHj6ZD9LquQAZ9CwCA GUK8caWPVMdHluM6Ysbrce4Zc9iQfDoJevzd5CoA= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D537E127136 for ; Fri, 6 Apr 2018 09:06:56 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <152303081686.3739.16537829965896183622.idtracker@ietfa.amsl.com> Date: Fri, 06 Apr 2018 09:06:56 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 06 Apr 2018 09:12:46 -0700 Subject: [secdir] [new-work] WG Review: IETF Administrative Support Activity 2 (iasa2) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 16:07:18 -0000 A new IETF WG has been proposed in the General Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2018-04-16. In November 2016, the IETF Chair kicked off the IASA 2.0 project [1]. Throughout 2017 and 2018, community discussions occurred on the iasa20@ietf.org mailing list, in two virtual workshops [2], by way of individual drafts [3][4][5], and at BoF sessions at IETF 98, 99, 100, and 101. In 2017 the IETF Chair convened a design team to evaluate potential legal and organizational options for the IETF's administrative structure. The design team examined types of organizational models and made initial recommendations [6] prior to IETF 100. As a result of that discussion, the design team working with the IETF Chair asked the Internet Society's tax law attorneys to outline a series of specific legal options [7][8][9]. These options, together with proposed elements of a specific organizational structure [10] were discussed at IETF 101. The design team's recommendation [11] and the rough consensus in the room as confirmed on the iasa20@ietf.org list in favor of a specific legal option -- a limited liability corporation that is treated as a branch or division of ISOC for tax purposes -- is embedded in the charter text below. [1] https://mailarchive.ietf.org/arch/msg/ietf/IkZfIBfM5jSrMflbY9k4cOzK8Ps [2] https://tools.ietf.org/html/draft-hall-iasa20-workshops-report-00 [3] https://tools.ietf.org/html/draft-daigle-iasa-retrospective-01 [4] https://tools.ietf.org/html/draft-arkko-ietf-iasa-thoughts-00 [5] https://tools.ietf.org/html/draft-arkko-ietf-finance-thoughts-00 [6] https://tools.ietf.org/html/draft-haberman-iasa20dt-recs-01 [7] https://mailarchive.ietf.org/arch/msg/iasa20/XT_3vfd3OWVFCW335mRrvWuusaI/ [8] https://mailarchive.ietf.org/arch/msg/iasa20/cPK6ei47a-VG3vERO0JqpT144uE [9] https://mailarchive.ietf.org/arch/msg/iasa20/UiGdiDEXyiT1x0WM8iUkxJkq1OI [10] https://tools.ietf.org/html/draft-hall-iasa2-struct-01 [11] https://tools.ietf.org/html/draft-dt-iasa20-proposal-00 IETF Administrative Support Activity 2 (iasa2) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Alissa Cooper General Area Directors: Alissa Cooper Mailing list: Address: iasa20@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/iasa20 Archive: https://mailarchive.ietf.org/arch/search/?email_list=iasa20 Group page: https://datatracker.ietf.org/group/iasa2/ Charter: https://datatracker.ietf.org/doc/charter-ietf-iasa2/ The arrangements relating to administrative support for the IETF (referred to as the "IETF Administrative Support Activity" (IASA) [RFC4071]) were created more than ten years ago, when the IETF initially took charge of its own administration. The arrangements have served the IETF reasonably well, but there have been considerable changes in the size and scope of the IASA work, in the world around the IETF, and in the IETF community's own expectations since the creation of IASA. As documented in [draft-haberman-iasa20dt-recs], the current administrative arrangements are facing a number of challenges. The range of IETF administrative tasks have grown considerably; the IASA organizational structure is not as clear, efficient, or as fully resourced as it should be; the division of responsibilities between the IETF and ISOC continues to evolve; expectations about transparency have changed; and the IETF faces continued challenges related to funding IETF activities against a backdrop of increasing costs and lack of predictability in our funding streams. In November 2016, the IETF Chair launched a project in the community to re-assess the IETF's administrative arrangements. Since then, the IETF community has discussed the challenges we face, the properties we expect from future arrangements, options for the legal structure of future arrangements, and options for the organizational structure of future arrangements. For legal purposes, IASA is currently organized as an activity of ISOC. Among multiple legal structure options that were considered by the IETF community, a new limited liability corporation (LLC) that is a disregarded entity of ISOC (i.e., it is treated as a branch or division of ISOC for tax purposes) will be created to house the administration of the IETF. ISOC supports this plan. This working group is chartered to document the normative changes to IETF administrative structures and processes necessary to effectuate this change. The main deliverable will be a document that obsoletes RFC 4071. The working group will produce other supporting documents as necessary to achieve its charter objective. In parallel, the legal documents necessary to establish the LLC will be developed outside the working group with the support of legal counsel. These documents will not be products of the working group, but this working group will be the venue where these documents will be presented to the IETF community for review and discussion before they are finalized. Aside from instances where they presently relate to IASA, it is outside the scope of this working group to consider any changes to anything related to the oversight or steering of the standards process as currently conducted by the IESG and IAB, the appeal chain, the confirming bodies for existing IETF and IAB appointments, the IRTF, or ISOC's memberships in other organizations. Milestones: Nov 2018 - Document obsoleting RFC 4071 sent to IESG Nov 2018 - Document obsoleting RFC 4371 sent to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Apr 6 11:30:42 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6779F127342 for ; Fri, 6 Apr 2018 11:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzLuYojqs5eQ for ; Fri, 6 Apr 2018 11:30:34 -0700 (PDT) Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1AA127136 for ; Fri, 6 Apr 2018 11:30:34 -0700 (PDT) Received: from smtp5.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp5.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 19E7525AE7; Fri, 6 Apr 2018 14:30:31 -0400 (EDT) Received: from app52.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp5.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 08F4D25545; Fri, 6 Apr 2018 14:30:31 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app52.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 06 Apr 2018 14:30:31 -0400 Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app52.wa-webapps.iad3a (Postfix) with ESMTP id ECA47E1A15; Fri, 6 Apr 2018 14:30:30 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 6 Apr 2018 11:30:30 -0700 (PDT) X-Auth-ID: scott@hyperthought.com Date: Fri, 6 Apr 2018 11:30:30 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-kucherawy-dispatch-zstd.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1523039430.96715938@apps.rackspace.com> X-Mailer: webmail/13.0.0-RC Archived-At: Subject: [secdir] secdir review of draft-kucherawy-dispatch-zstd-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 18:30:36 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments.=0A=0AThe summary of the review is ready.=0A=0AT= his document describes the Zstandard data compression mechanism, and regist= ers a MIME media type.=0A=0AThe security considerations section covers all = relevant points, I see no security issues with this doc. I did notice a min= or typo: page 3, "2.1.1.1.1. Frame Header Descrptor"=0A=0ASorry this revie= w is late, hope it is still helpful.=0A=0A--Scott=0A From nobody Tue Apr 10 21:16:23 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914AD124D68 for ; Tue, 10 Apr 2018 21:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8XyMLQzg8AJ for ; Tue, 10 Apr 2018 21:16:14 -0700 (PDT) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2F2127023 for ; Tue, 10 Apr 2018 21:16:12 -0700 (PDT) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=SsPS07G0 c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=Kd1tUaAdevIA:10 a=bmmO2AaSJ7QA:10 a=BTUBnpS-AAAA:8 a=iiazv-oawmH03g7Men8A:9 a=QEXdDO2ut3YA:10 a=pblkFgjdBCuYZ9-HdJ6i:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=david+work@mandelberg.org; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=david+work@mandelberg.org; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.43.168 is neither permitted nor denied by domain of mandelberg.org) Received: from [209.6.43.168] ([209.6.43.168:48232] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 2E/B9-15426-B0C8DCA5; Wed, 11 Apr 2018 00:16:11 -0400 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 64EDA1C603B; Wed, 11 Apr 2018 00:16:10 -0400 (EDT) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dime-rfc4006bis.all@ietf.org From: David Mandelberg Organization: David Mandelberg, LLC Message-ID: Date: Wed, 11 Apr 2018 00:16:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-dime-rfc4006bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 04:16:15 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with nits. (nit) The term AVP is used extensively, and I don't see a definition. Would its definition be obvious to anybody implementing this spec? I'm assuming it means attribute-value pair. (nit, section 5.1.1) "For time based services, the quota is continuously consumed at the regular rate of 60 seconds per minute." Are leap seconds a problem? -- Freelance cyber security consultant, software developer, and more https://david.mandelberg.org/ From nobody Tue Apr 10 22:29:32 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BBB12D87A for ; Tue, 10 Apr 2018 22:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6902CrjxkxNG for ; Tue, 10 Apr 2018 22:29:29 -0700 (PDT) Received: from sonic315-15.consmr.mail.bf2.yahoo.com (sonic315-15.consmr.mail.bf2.yahoo.com [74.6.134.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F172C1241FC for ; Tue, 10 Apr 2018 22:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1523424568; bh=ffKfFzSoRxqZn/RBOzhjFoN34z9e8Pu8EAjJQZXmlq0=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=o0Q1ttK8Y+hvyuW85JfvzJRetMbmqPwnQCKy9CEpV7KozHDJr/hnFXiB1JK+Dj2vkNXia4F7tmXEcLAID9XnD/27YoZSsXBfeKy15SrdEegrvfSCWzJdgyrg5H3EOULEYMDIgaU8xmVE690tRW/DE+9ihlY2fFTd323ojsK/vhVZQGrLrAVrO1mAvTu0dmWQ42rkNj8r2UCO+eq0PRZ+JrrXlpcGGTpTy2VlbAumNT8y5UDKFwl978NrkQC7+qqpMZQE8SuhQuvqEWc5Lla17BEYF118C2/GQpffG75FywVpWKIBL9mJvvLMD71rpkY6BL/DcMb1epVAsV/wjb2CrA== X-YMail-OSG: xv_H8bcVM1nnFPjrgirLYYvBPQy_hMKw5rCfw.3RayfgvFlRTE3RmrnqarGEXxA 9aWzqjeQ5mvjHZShj2FNhNs03i8g1_CcGCngFzOhsYCfe3Lz5s9zvuMQ1GG4RH8kQsJZYzAcxZyZ GKD2dGX0UpvBcqrSDmt9i_beIpK2uZs2oaa88PqQp7AuHaDf6abFCbaPKSKs8UlSZlE.H3IUSMPh exycHA8WJ7qvyOq8q1OQt3v7anrXRl7BEHFg0z1V38.B7USF2CD6TlSoubwlUW9VuU5MaAJMenSS 4ogu7Ha4LRb.QK4KDHV6Birm0XwaBD08BIW.WtWxPbrcrfbdN5HjmV11EXpwLTcvA1QZV_9UkxT2 fZmZvxKm9aHBiRMQ0v_hFWiVWg37hS55OqffYfLtpBe1IMnvKlLAcN7FjVirtrprA809tUeQuWtw 5vQtOJZrWDtAeCHlcEmubxZaAOM27xdC37hGgjpHWuo9xgWl3Azc3GLS5pZQFkxyaaFUMZcBvg1s tZBv.BcbnqjsfMNxRXk.vNLM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Wed, 11 Apr 2018 05:29:28 +0000 Date: Wed, 11 Apr 2018 05:29:24 +0000 (UTC) From: Yuval Lifshitz To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dime-rfc4006bis.all@ietf.org, David Mandelberg Message-ID: <1688903973.1637579.1523424564269@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1637578_84829322.1523424564267" X-Mailer: WebService/1.1.11745 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-dime-rfc4006bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 05:29:31 -0000 ------=_Part_1637578_84829322.1523424564267 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David, * The term AVP is well known for anyone implementing a Diameter spec. It is= also defined in the base spec (https://tools.ietf.org/html/rfc6733#section= -1.2).* IMO, one second of inaccuracy is not considered overcharge or reven= ue leakage in time based service Yuval On Wednesday, April 11, 2018, 7:16:15 a.m. GMT+3, David Mandelberg wrote: =20 =20 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with nits. (nit) The term AVP is used extensively, and I don't see a definition.=20 Would its definition be obvious to anybody implementing this spec? I'm=20 assuming it means attribute-value pair. (nit, section 5.1.1) "For time based services, the quota is continuously=20 consumed at the regular rate of 60 seconds per minute." Are leap seconds=20 a problem? --=20 Freelance cyber security consultant, software developer, and more https://david.mandelberg.org/ =20 ------=_Part_1637578_84829322.1523424564267 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David,

* The term AVP is well = known for anyone implementing a Diameter spec. It is also defined in the ba= se spec (https://tools.ietf.org/html/rfc6733#section-1.= 2).
* IMO, one second of inaccuracy is not considered overcha= rge or revenue leakage in time based service

Y= uval

=20
=20
On Wednesday, April 11, 2018, 7:16:15 a.m. GMT+3, D= avid Mandelberg <david+work@mandelberg.org> wrote:


I have reviewed this document as = part of the security directorate's
ongoing effort= to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of th= e
security area directors.  Document editors= and WG chairs should treat
these comments just l= ike any other last call comments.

The summary of the review is Ready with nits.

(nit) The term AVP is used extensively,= and I don't see a definition.
Would its definit= ion be obvious to anybody implementing this spec? I'm
assuming it means attribute-value pair.
(nit, section 5.1.1) "For time based services, the = quota is continuously
consumed at the regular ra= te of 60 seconds per minute." Are leap seconds
a= problem?

--
Freelance cyber security consultant, software developer, = and more
------=_Part_1637578_84829322.1523424564267-- From nobody Wed Apr 11 07:46:07 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDCD12D775; Wed, 11 Apr 2018 07:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWJP11dmhZjS; Wed, 11 Apr 2018 07:45:57 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8EEA1200F1; Wed, 11 Apr 2018 07:45:56 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3BEjsL5069176 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Apr 2018 09:45:55 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: <7B2D7604-059F-415B-8DFB-ECB5E2F37C0D@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_928DA161-464C-44B0-B57A-FB12EC2F9C71"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 11 Apr 2018 09:45:53 -0500 In-Reply-To: <1688903973.1637579.1523424564269@mail.yahoo.com> Cc: iesg@ietf.org, secdir@ietf.org, draft-ietf-dime-rfc4006bis.all@ietf.org, David Mandelberg To: Yuval Lifshitz References: <1688903973.1637579.1523424564269@mail.yahoo.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-dime-rfc4006bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 14:46:01 -0000 --Apple-Mail=_928DA161-464C-44B0-B57A-FB12EC2F9C71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, The term =E2=80=9CAVP=E2=80=9D is on the IETF=E2=80=99s =E2=80=9Cwell = known=E2=80=9D abbreviation list. (Both for Attribute Value Pair and = Audio Visual Profile) Thanks! Ben. > On Apr 11, 2018, at 12:29 AM, Yuval Lifshitz = wrote: >=20 > Hi David, >=20 > * The term AVP is well known for anyone implementing a Diameter spec. = It is also defined in the base spec = (https://tools.ietf.org/html/rfc6733#section-1.2). > * IMO, one second of inaccuracy is not considered overcharge or = revenue leakage in time based service >=20 > Yuval >=20 > On Wednesday, April 11, 2018, 7:16:15 a.m. GMT+3, David Mandelberg = wrote: >=20 >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > The summary of the review is Ready with nits. >=20 > (nit) The term AVP is used extensively, and I don't see a definition. > Would its definition be obvious to anybody implementing this spec? I'm > assuming it means attribute-value pair. >=20 > (nit, section 5.1.1) "For time based services, the quota is = continuously > consumed at the regular rate of 60 seconds per minute." Are leap = seconds > a problem? >=20 > -- > Freelance cyber security consultant, software developer, and more > https://david.mandelberg.org/ --Apple-Mail=_928DA161-464C-44B0-B57A-FB12EC2F9C71 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrOH6EACgkQgFZKbJXz 1A3Asw//T6z8fzSIp4mQnnoVRsne+hGwuDvwwHpkfqhemwhlx9lclH/K9zWT2LHz LRd1cFoa2M141pWEBn2q6h5radrkVSqv7Ob9+VaOLf+i8ymlqfndT4/kUCe4fDTj D/B9diR/jXy91XMOF8UmKsJmlNDHTnOBPF4Rmmi3ihBVwEfhxLCGG29SRLTeRZdD OTlI+jWdmae1/B0Rsuy9wjsTmTEzx6AdK3wp5JI35a9pxuaDOIN7rxJ33scGSVwq Esxxk7X+A0IL+sF5ooQHuj2wPfzucXwTqI0lSsGkmOkmVMUQOMJsf2WAgEqlvb6U sMKtASw6KeL3gWq0+OrZTMToBIAur+IBabajyrFl2C9AQxAKlnTMXXYYcpxjo8jn dxq7rxz0FG2qip48A0JiZ9PDhtdCTDbuK01rJRbYTkOmMHIoqj/R92SkSy+rsWcT 9ftNMnljeO3Z89Nor7w00cGXmuxPCGkT3tV/dZ4IX7AFCK0BiAVuhxc+UxUbVgSh qqaYGEroCdfFv2hbD/FLynDGyZvA/w1zU++V0zPICjttBWE4d9m3A+7/SFaVDXjr I+nC+BUCrPrvMoT1eOlYDrWe2rfrOK82hD8GtAuBdgik+hNHMw4st3jajFStDgGd k7TTAlNO4g//kBqKMUEHQMhUCTutC+84Y0cXYctdxfJQzoWGeZU= =z2HD -----END PGP SIGNATURE----- --Apple-Mail=_928DA161-464C-44B0-B57A-FB12EC2F9C71-- From nobody Fri Apr 13 13:11:38 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD084128896; Fri, 13 Apr 2018 13:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfWg7tsP0B6q; Fri, 13 Apr 2018 13:11:23 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4643127AD4; Fri, 13 Apr 2018 13:11:22 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w3DK7eXI036239; Fri, 13 Apr 2018 16:11:19 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2hb1ky2t3q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Apr 2018 16:11:19 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w3DKBI1w019638; Fri, 13 Apr 2018 16:11:19 -0400 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [135.66.87.31]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w3DKB3gn019319; Fri, 13 Apr 2018 16:11:03 -0400 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [127.0.0.1]) by zlp27127.vci.att.com (Service) with ESMTP id 73C7C40002B5; Fri, 13 Apr 2018 20:11:03 +0000 (GMT) Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (unknown [130.9.129.151]) by zlp27127.vci.att.com (Service) with ESMTPS id 5FD5C40006F9; Fri, 13 Apr 2018 20:11:03 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.210]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0361.001; Fri, 13 Apr 2018 16:11:02 -0400 From: "BRUNGARD, DEBORAH A" To: "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" , "ops-dir@ietf.org" , "secdir@ietf.org" CC: " (rtg-ads@ietf.org)" , "ops-ads@ietf.org" , "" , "Stewart Bryant (stewart.bryant@gmail.com)" , "Jeffrey Haas (jhaas@pfrc.org)" , "Acee Lindem (acee) (acee@cisco.com)" , "'russ@riw.us'" Thread-Topic: New Routing Area Security Design Team Thread-Index: AdPTYCpdxrWraEBxSTyykispJqF3TQ== Date: Fri, 13 Apr 2018 20:11:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.240.56] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8882C74A7MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-13_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=758 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804130186 Archived-At: Subject: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 20:11:25 -0000 --_000_F64C10EAA68C8044B33656FA214632C8882C74A7MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Routing ADs have chartered a design team as described below. I will be the AD-contact: db3546@att.com Routing Area Security Design Team Charter Internet security threats have evolved in the last couple of years and ques= tions are arising about the security properties of many long-standing IETF = routing protocols and new protocols under development. This is an opportuni= ty for the Routing Area to evaluate current assumptions and make recommenda= tions for new work. The Routing Area will kick off a Routing Area-wide Design team with support= from the OPS Area and Security Area. The first phase will consist of a sma= ll team: Stewart Bryant stewart.bryant@gmail.com Jeff Haas jhaas@pfrc.org Acee Lindem acee@cisco.com Russ White russ@riw.us They will be responsible to set up an environment (e.g. wiki), identify wor= k items, and coordinating overall the work effort. It is the expectation th= is initial phase will be done by May 1. A second phase will consist of smal= l teams working on targeted items. Work items will include review of curren= t deployments (use models) and threat models, evaluation criteria and usefu= l advice when doing new work (on existing protocols and new protocols), and= recommendations on where new work is needed in cooperation with the respon= sible working group. The work will have support from the Security Area and = OPS Area. The design team will have a private mailing list for this first phase and c= an be reached at rt-dt-security@ietf.org. Regards, Deborah --_000_F64C10EAA68C8044B33656FA214632C8882C74A7MISOUT7MSGUSRDE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Routing ADs have chartered a design team as desc= ribed below.

 

I will be the AD-contact: db3546@att.com

 

Routing Area Security Design Team Charter=

 

Internet security threats have evolved in the last c= ouple of years and questions are arising about the security properties of m= any long-standing IETF routing protocols and new protocols under developmen= t. This is an opportunity for the Routing Area to evaluate current assumptions and make recommendations for = new work.

 

The Routing Area will kick off a Routing Area-wide D= esign team with support from the OPS Area and Security Area. The first phas= e will consist of a small team:

 

Stewart Bryant stewart.bryant@gmail.com

Jeff Haas jhaas@pf= rc.org

Acee Lindem acee@c= isco.com

Russ White russ@riw.u= s

 

They will be responsible to set up an environment (e= .g. wiki), identify work items, and coordinating overall the work effort. I= t is the expectation this initial phase will be done by May 1. A second pha= se will consist of small teams working on targeted items. Work items will include review of current deployments (= use models) and threat models, evaluation criteria and useful advice when d= oing new work (on existing protocols and new protocols), and recommendation= s on where new work is needed in cooperation with the responsible working group. The work will have support= from the Security Area and OPS Area.

 

The design team will have a private mailing list for= this first phase and can be reached at rt-dt-security@ietf.org.

 

Regards,

Deborah

 

 

--_000_F64C10EAA68C8044B33656FA214632C8882C74A7MISOUT7MSGUSRDE_-- From nobody Fri Apr 13 13:21:03 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFE212946D for ; Fri, 13 Apr 2018 13:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMzVpXIKe4Gn for ; Fri, 13 Apr 2018 13:20:57 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5561C127978 for ; Fri, 13 Apr 2018 13:20:57 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id u84-v6so9474682oie.10 for ; Fri, 13 Apr 2018 13:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wYVp8teNfbphqk6s09Cm088UuJXpHnpnPp02xznmG60=; b=NXAF0lvwxYPk//BfWNxaxsOvWRQuc5TPW36vSsuEfBa5sBojtDTnyFLt0tfAcSoZ2B E/HwX2NYTT8c79uSeV2sbY6mefdX7SnmWBNHUiPZ6NOiIIO4VDv3796SzAUt/o7/PtPI s+eyELMp7G/YcxhFOGZCs5o1Sh4nBttw4R8hw90WTW3uaVPkob/t2RCtGXpgC0mUHwAT mC3Z5KNQ7yNUO5ukW70mmg1DZvz8xwn9snCwIt6suniFXGLBksnqGIi1/5EpJGoKnw99 wLMze9RQuwOnD9MXDK/yzNxmfTdOukTRPljWMekq6wjgdQyZfIwnLJQWCd6folwZ7AVp dq2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wYVp8teNfbphqk6s09Cm088UuJXpHnpnPp02xznmG60=; b=ZG3PcKGpIpaxDkV2n7t09XvKFTx8KCjTJT7aP0t+g30v2W/2/D/MZx9yTybQ9I0RQx BYvoDHPuVQRxuxrjV1Ta4CmztX082lNiN0BiPj7Xjo9gk29CcoGVgtel+5ysF+rwA2Rg 29MS2/UUqpuX2hLklGDWil1Zyw+BFdVwt+bbcie2DVLPZaakdcKHPrjpnkWnrRdVhEn2 XzSr+cwac7Nm6HEZF9zhKwmg+XCIV3aRPmH+FFh8Nh833/WQizeLPtkv+4wUZ5BjJ3gU zN/7++VA2VJojDKM0SCoZFyU2cCIjkE72LnoR8Pw6PaE63D4Og0pJU2kyzgkES0wIgNx SwXg== X-Gm-Message-State: ALQs6tCqchfvhPw1NEdRWV1trwUcK95ALrqDYfYPJqdY/d8Z7jW7BGp5 zQZlv90AHmZSuC8JR2/L844fhqngM+NQerd1rTTANw== X-Google-Smtp-Source: AIpwx4+pLAwghi0SNi9cFKTJLmcQepRfIvTG/G3s9EyNVkfiLA4NxQyTAqa7QlmyTP7UY9YTk38vMJD1chBBAs+iI4U= X-Received: by 2002:aca:30c6:: with SMTP id w189-v6mr8894010oiw.29.1523650856524; Fri, 13 Apr 2018 13:20:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Fri, 13 Apr 2018 13:20:56 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Fri, 13 Apr 2018 16:20:56 -0400 Message-ID: To: "BRUNGARD, DEBORAH A" Cc: "secdir@ietf.org" , "russ@riw.us" , "Jeffrey Haas (jhaas@pfrc.org)" , "Stewart Bryant (stewart.bryant@gmail.com)" , "Acee Lindem (acee) (acee@cisco.com)" Content-Type: multipart/alternative; boundary="00000000000010de750569c09c95" Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 20:21:02 -0000 --00000000000010de750569c09c95 Content-Type: text/plain; charset="UTF-8" (trimming the CC list a bit) Hey Deborah, Delighted to hear this news. Do you have an idea of what the initial deliverables are for this group? What security problems are they going to try to address? TBH, it seems like the headline problem at the Internet level is BGP abuse. The base RPKI docs have been out for several years now, and BGPSEC is pretty much finished, but the deployment numbers continue to hover around 8-9% for even the most basic protections. It would be delightful to have a group take a look at what the deployment blockers are here, and whether there's anything the IETF could do to help, whether it's updating protocols, producing deployment guides, writing code, etc. We shouldn't think that RFCs are the only tool in our arsenal. Thanks, --Richard [1] https://rpki-monitor.antd.nist.gov/ On Fri, Apr 13, 2018 at 4:11 PM, BRUNGARD, DEBORAH A wrote: > The Routing ADs have chartered a design team as described below. > > > > I will be the AD-contact: db3546@att.com > > > > Routing Area Security Design Team Charter > > > > Internet security threats have evolved in the last couple of years and > questions are arising about the security properties of many long-standing > IETF routing protocols and new protocols under development. This is an > opportunity for the Routing Area to evaluate current assumptions and make > recommendations for new work. > > > > The Routing Area will kick off a Routing Area-wide Design team with > support from the OPS Area and Security Area. The first phase will consist > of a small team: > > > > Stewart Bryant stewart.bryant@gmail.com > > Jeff Haas jhaas@pfrc.org > > Acee Lindem acee@cisco.com > > Russ White russ@riw.us > > > > They will be responsible to set up an environment (e..g. wiki), identify > work items, and coordinating overall the work effort. It is the expectation > this initial phase will be done by May 1. A second phase will consist of > small teams working on targeted items. Work items will include review of > current deployments (use models) and threat models, evaluation criteria and > useful advice when doing new work (on existing protocols and new > protocols), and recommendations on where new work is needed in cooperation > with the responsible working group. The work will have support from the > Security Area and OPS Area. > > > > The design team will have a private mailing list for this first phase and > can be reached at rt-dt-security@ietf.org. > > > > Regards, > > Deborah > > > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > --00000000000010de750569c09c95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(trimming the CC list a bit)

=
Hey Deborah,

Delighted to hear this news.=C2= =A0 Do you have an idea of what the initial deliverables are for this group= ?=C2=A0 What security problems are they going to try to address?
=
TBH, it seems like the headline problem at the Internet leve= l is BGP abuse.=C2=A0 The base RPKI docs have been out for several years no= w, and BGPSEC is pretty much finished, but the deployment numbers continue = to hover around 8-9% for even the most basic protections.=C2=A0 It would be= delightful to have a group take a look at what the deployment blockers are= here, and whether there's anything the IETF could do to help, whether = it's updating protocols, producing deployment guides, writing code, etc= .=C2=A0 We shouldn't think that RFCs are the only tool in our arsenal.<= br>

Thanks,
--Richard

=


On Fri, Apr 13, 2018 at 4:1= 1 PM, BRUNGARD, DEBORAH A <db3546@att.com> wrote:

The Routing ADs have chartered a design team as desc= ribed below.

=C2=A0

I will be the AD-contact: db3546@att.com

=C2=A0

Routing Area Security Design Team Charter<= /u>

=C2=A0

Internet security threats have evolved in the last c= ouple of years and questions are arising about the security properties of m= any long-standing IETF routing protocols and new protocols under developmen= t. This is an opportunity for the Routing Area to evaluate current assumptions and make recommendations for = new work.

=C2=A0

The Routing Area will kick off a Routing Area-wide D= esign team with support from the OPS Area and Security Area. The first phas= e will consist of a small team:

=C2=A0

Stewart Bryant stewart.bryant@gmail.com

Jeff Haas jhaas@pfrc.org

Acee Lindem acee@cisco.com

Russ White russ@riw.us

=C2=A0

They will be responsible to set up an environment (e= ..g. wiki), identify work items, and coordinating overall the work effort. = It is the expectation this initial phase will be done by May 1. A second ph= ase will consist of small teams working on targeted items. Work items will include review of current deployments (= use models) and threat models, evaluation criteria and useful advice when d= oing new work (on existing protocols and new protocols), and recommendation= s on where new work is needed in cooperation with the responsible working group. The work will have support= from the Security Area and OPS Area.

=C2=A0

The design team will have a private mailing list for= this first phase and can be reached at rt-dt-security= @ietf.org.

=C2=A0

Regards,

Deborah

=C2=A0

=C2=A0


_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/= wiki/SecDirReview


--00000000000010de750569c09c95-- From nobody Fri Apr 13 14:25:22 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9828012D574 for ; Fri, 13 Apr 2018 14:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UWzSwGsUBdk for ; Fri, 13 Apr 2018 14:25:19 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4267129C6D for ; Fri, 13 Apr 2018 14:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4846; q=dns/txt; s=iport; t=1523654718; x=1524864318; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9+FdOKsVQaVGuKNoSZiaKiE2RbzZjjmiZBWd2jFIXnE=; b=He//bwrPKf+sixJOWIV1NF+PxRSJD45hiNM2quR8VVW+APvSb4VDdWqg A9U8dQmNPGbKjV5oaJTeNLxzxJxWEI7o7eHvDnCWoXgjGXwKtBCuixevS n7oY53q8fpu4AUGPSFqcGH4B5SKiG9OStOMAXLR9iq0wW+VDZr1RRLAqk 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AAAiH9Fa/4ENJK1SChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDEwQrYXooCoNaiAKNEYF0dRqGZ4wBgXsLGAuEFUsCGoI?= =?us-ascii?q?TITQYAQIBAQEBAQECbBwMhSIBAQEBAwEBIRE6CxACAQgOAwMBAgMCIwMCAgI?= =?us-ascii?q?fBgsUAQgIAQEEDgUYAoRbAxUPqE6CHIcLDYErgi+BCYZ7ghOBDgEjgjMHLoJ?= =?us-ascii?q?PQgEBA4EyKyaCWjCCJAKHTo9kLAgChVaFZYJ9gW6KWYklP4YMAhETAYEkARw?= =?us-ascii?q?4gVJwFTsqAYIYCYMoAQOERoMVhT5vAQuNVYEXAQE?= X-IronPort-AV: E=Sophos;i="5.48,446,1517875200"; d="scan'208";a="380802669" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2018 21:25:17 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w3DLPHXl008556 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Apr 2018 21:25:17 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 13 Apr 2018 17:25:16 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Fri, 13 Apr 2018 17:25:16 -0400 From: "Acee Lindem (acee)" To: Richard Barnes , "BRUNGARD, DEBORAH A" CC: "secdir@ietf.org" , "russ@riw.us" , "Jeffrey Haas (jhaas@pfrc.org)" , "Stewart Bryant (stewart.bryant@gmail.com)" Thread-Topic: [secdir] New Routing Area Security Design Team Thread-Index: AdPTYCpdxrWraEBxSTyykispJqF3TQAJkpIA///O6wA= Date: Fri, 13 Apr 2018 21:25:16 +0000 Message-ID: <187AE9A0-E125-4B54-A286-488F52CB88B6@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.200] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 21:25:21 -0000 SGkgUmljaGFyZCwgDQoNCldoZW4geW91IHRhbGsgYWJvdXQgUm91dGluZyBTZWN1cml0eSwgaXQg aXMgbGlrZSB0aGUgYmxpbmQgbWVuIGFuZCBlbGVwaGFudCwgZXZlcnlvbmUgaGFzIGEgZGlmZmVy ZW50IG9waW5pb24gb24gd2hhdCB0aGUgcHJpb3JpdGllcyBhcmUuIEZyb20gbXkgdmlld3BvaW50 IChhbmQgSSBkbyBoYXZlIG9uZSBiYWQgZXllIDteKSwgb25lIG9mIHRoZSBvdXRjb21lcyBzaG91 bGQgYmUgZmluZGluZyB0aGUgcmlnaHQgc2V0IG9mIGF1dGhvcnMgZm9yIHByb3RvY29sIHNwZWNp ZmljIOKAnFhYWFggU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnPigJ0gZG9jdW1lbnRzIHdoZXJlIFhY WFggaXMgQkdQLCBJUy1JUywgT1NQRiwgTERQLCBQSU0sIGV0Yy4gQWRkaXRpb25hbGx5LCB3ZeKA mWQgcHJvdmlkZSBhIGdlbmVyaWMgb3V0bGluZSBmb3IgdGhlc2UgZG9jdW1lbnRzLiANCg0KVGhh bmtzLA0KQWNlZSANCg0KRnJvbTogUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+DQpEYXRlOiBG cmlkYXksIEFwcmlsIDEzLCAyMDE4IGF0IDQ6MjEgUE0NClRvOiBEZWJvcmFoIEJydW5nYXJkIDxk YjM1NDZAYXR0LmNvbT4NCkNjOiAic2VjZGlyQGlldGYub3JnIiA8c2VjZGlyQGlldGYub3JnPiwg UnVzcyBXaGl0ZSA8cnVzc0ByaXcudXM+LCBKZWZmIEhhYXMgPGpoYWFzQHBmcmMub3JnPiwgU3Rl d2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4sIEFjZWUgTGluZGVtIDxhY2Vl QGNpc2NvLmNvbT4NClN1YmplY3Q6IFJlOiBbc2VjZGlyXSBOZXcgUm91dGluZyBBcmVhIFNlY3Vy aXR5IERlc2lnbiBUZWFtDQoNCih0cmltbWluZyB0aGUgQ0MgbGlzdCBhIGJpdCkNCg0KSGV5IERl Ym9yYWgsDQoNCkRlbGlnaHRlZCB0byBoZWFyIHRoaXMgbmV3cy7CoCBEbyB5b3UgaGF2ZSBhbiBp ZGVhIG9mIHdoYXQgdGhlIGluaXRpYWwgZGVsaXZlcmFibGVzIGFyZSBmb3IgdGhpcyBncm91cD/C oCBXaGF0IHNlY3VyaXR5IHByb2JsZW1zIGFyZSB0aGV5IGdvaW5nIHRvIHRyeSB0byBhZGRyZXNz Pw0KDQpUQkgsIGl0IHNlZW1zIGxpa2UgdGhlIGhlYWRsaW5lIHByb2JsZW0gYXQgdGhlIEludGVy bmV0IGxldmVsIGlzIEJHUCBhYnVzZS7CoCBUaGUgYmFzZSBSUEtJIGRvY3MgaGF2ZSBiZWVuIG91 dCBmb3Igc2V2ZXJhbCB5ZWFycyBub3csIGFuZCBCR1BTRUMgaXMgcHJldHR5IG11Y2ggZmluaXNo ZWQsIGJ1dCB0aGUgZGVwbG95bWVudCBudW1iZXJzIGNvbnRpbnVlIHRvIGhvdmVyIGFyb3VuZCA4 LTklIGZvciBldmVuIHRoZSBtb3N0IGJhc2ljIHByb3RlY3Rpb25zLsKgIEl0IHdvdWxkIGJlIGRl bGlnaHRmdWwgdG8gaGF2ZSBhIGdyb3VwIHRha2UgYSBsb29rIGF0IHdoYXQgdGhlIGRlcGxveW1l bnQgYmxvY2tlcnMgYXJlIGhlcmUsIGFuZCB3aGV0aGVyIHRoZXJlJ3MgYW55dGhpbmcgdGhlIElF VEYgY291bGQgZG8gdG8gaGVscCwgd2hldGhlciBpdCdzIHVwZGF0aW5nIHByb3RvY29scywgcHJv ZHVjaW5nIGRlcGxveW1lbnQgZ3VpZGVzLCB3cml0aW5nIGNvZGUsIGV0Yy7CoCBXZSBzaG91bGRu J3QgdGhpbmsgdGhhdCBSRkNzIGFyZSB0aGUgb25seSB0b29sIGluIG91ciBhcnNlbmFsLg0KDQpU aGFua3MsDQotLVJpY2hhcmQNCg0KWzFdIGh0dHBzOi8vcnBraS1tb25pdG9yLmFudGQubmlzdC5n b3YvwqAgDQoNCg0KT24gRnJpLCBBcHIgMTMsIDIwMTggYXQgNDoxMSBQTSwgQlJVTkdBUkQsIERF Qk9SQUggQSA8bWFpbHRvOmRiMzU0NkBhdHQuY29tPiB3cm90ZToNClRoZSBSb3V0aW5nIEFEcyBo YXZlIGNoYXJ0ZXJlZCBhIGRlc2lnbiB0ZWFtIGFzIGRlc2NyaWJlZCBiZWxvdy4NCsKgDQpJIHdp bGwgYmUgdGhlIEFELWNvbnRhY3Q6IG1haWx0bzpkYjM1NDZAYXR0LmNvbQ0KwqANClJvdXRpbmcg QXJlYSBTZWN1cml0eSBEZXNpZ24gVGVhbSBDaGFydGVyDQrCoA0KSW50ZXJuZXQgc2VjdXJpdHkg dGhyZWF0cyBoYXZlIGV2b2x2ZWQgaW4gdGhlIGxhc3QgY291cGxlIG9mIHllYXJzIGFuZCBxdWVz dGlvbnMgYXJlIGFyaXNpbmcgYWJvdXQgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgbWFueSBs b25nLXN0YW5kaW5nIElFVEYgcm91dGluZyBwcm90b2NvbHMgYW5kIG5ldyBwcm90b2NvbHMgdW5k ZXIgZGV2ZWxvcG1lbnQuIFRoaXMgaXMgYW4gb3Bwb3J0dW5pdHkgZm9yIHRoZSBSb3V0aW5nIEFy ZWEgdG8gZXZhbHVhdGUgY3VycmVudCBhc3N1bXB0aW9ucyBhbmQgbWFrZSByZWNvbW1lbmRhdGlv bnMgZm9yIG5ldyB3b3JrLg0KwqANClRoZSBSb3V0aW5nIEFyZWEgd2lsbCBraWNrIG9mZiBhIFJv dXRpbmcgQXJlYS13aWRlIERlc2lnbiB0ZWFtIHdpdGggc3VwcG9ydCBmcm9tIHRoZSBPUFMgQXJl YSBhbmQgU2VjdXJpdHkgQXJlYS4gVGhlIGZpcnN0IHBoYXNlIHdpbGwgY29uc2lzdCBvZiBhIHNt YWxsIHRlYW06DQrCoA0KU3Rld2FydCBCcnlhbnQgbWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWls LmNvbQ0KSmVmZiBIYWFzIG1haWx0bzpqaGFhc0BwZnJjLm9yZw0KQWNlZSBMaW5kZW0gbWFpbHRv OmFjZWVAY2lzY28uY29tDQpSdXNzIFdoaXRlIG1haWx0bzpydXNzQHJpdy51cw0KwqANClRoZXkg d2lsbCBiZSByZXNwb25zaWJsZSB0byBzZXQgdXAgYW4gZW52aXJvbm1lbnQgKGUuLmcuIHdpa2kp LCBpZGVudGlmeSB3b3JrIGl0ZW1zLCBhbmQgY29vcmRpbmF0aW5nIG92ZXJhbGwgdGhlIHdvcmsg ZWZmb3J0LiBJdCBpcyB0aGUgZXhwZWN0YXRpb24gdGhpcyBpbml0aWFsIHBoYXNlIHdpbGwgYmUg ZG9uZSBieSBNYXkgMS4gQSBzZWNvbmQgcGhhc2Ugd2lsbCBjb25zaXN0IG9mIHNtYWxsIHRlYW1z IHdvcmtpbmcgb24gdGFyZ2V0ZWQgaXRlbXMuIFdvcmsgaXRlbXMgd2lsbCBpbmNsdWRlIHJldmll dyBvZiBjdXJyZW50IGRlcGxveW1lbnRzICh1c2UgbW9kZWxzKSBhbmQgdGhyZWF0IG1vZGVscywg ZXZhbHVhdGlvbiBjcml0ZXJpYSBhbmQgdXNlZnVsIGFkdmljZSB3aGVuIGRvaW5nIG5ldyB3b3Jr IChvbiBleGlzdGluZyBwcm90b2NvbHMgYW5kIG5ldyBwcm90b2NvbHMpLCBhbmQgcmVjb21tZW5k YXRpb25zIG9uIHdoZXJlIG5ldyB3b3JrIGlzIG5lZWRlZCBpbiBjb29wZXJhdGlvbiB3aXRoIHRo ZSByZXNwb25zaWJsZSB3b3JraW5nIGdyb3VwLiBUaGUgd29yayB3aWxsIGhhdmUgc3VwcG9ydCBm cm9tIHRoZSBTZWN1cml0eSBBcmVhIGFuZCBPUFMgQXJlYS4NCsKgDQpUaGUgZGVzaWduIHRlYW0g d2lsbCBoYXZlIGEgcHJpdmF0ZSBtYWlsaW5nIGxpc3QgZm9yIHRoaXMgZmlyc3QgcGhhc2UgYW5k IGNhbiBiZSByZWFjaGVkIGF0IG1haWx0bzpydC1kdC1zZWN1cml0eUBpZXRmLm9yZy4NCsKgDQpS ZWdhcmRzLA0KRGVib3JhaA0KwqANCsKgDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzZWNkaXIgbWFpbGluZyBsaXN0DQptYWlsdG86c2VjZGlyQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpcg0Kd2lr aTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZpZXcN Cg0KDQo= From nobody Fri Apr 13 14:57:22 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4232E12D869 for ; Fri, 13 Apr 2018 14:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4-WmWPizovF for ; Fri, 13 Apr 2018 14:57:18 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCA2C129C6D for ; Fri, 13 Apr 2018 14:57:17 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id 188-v6so9673291oih.8 for ; Fri, 13 Apr 2018 14:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WRFMwKUQVNxgGirnBpPESUL586YDAhBDYmv1e7G86vg=; b=cYZxVAjQYTXsp4lvZYqiJjdlZ/0IrmHdN+ylFmMEv5gHPAfaOXgXaBC5hhQuj6IQBJ 5nT2l+A00OAHkadFQ1kQflfnZyy04Ez6wWDt3Ynfk8tOikT5PJzWmi5YgBRScRLZj4EJ s1aPGSWWcPNCy4F/feYWDPMuO5ai/HzHI7SSUbTn/716ODzyDT0WZXBuZWkBS6HqusoU 8/Pm1D9UhO4XFaAXnhrmh2yiDFUt1ouAsQ44ZI5U3pvOf5RsME8EGwWVuV0c/MdrRTka wWtmtxgUPpfN0rHD7GXch6eaOLHw4bbdpJGMGRYgS9qNld5r4OZuy6cRtVLXRKAM6EPy x1hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WRFMwKUQVNxgGirnBpPESUL586YDAhBDYmv1e7G86vg=; b=uI+y8FX1sNxAmXjtx0Y9RbrAxa0FFyMhaaLXA0LgsCScKNC1ChG8ju9SUvIQxRrh2Q XXAFSYWkFeuIS8uYCyamUmFBTiIYRI9z7FpHk7I80pkAJp4EoBfgazdXDd3pw4pRf+bu Won3/g9TosBoY0srCGU30S1gKE8hotWdUcOyNkzX8y+NWvE+20LEf5N2sayMTlXBmR6I hxDCHlzSqSLGglxHvP4jgVDXIrbec9oVVNaMQ2/WUWyBauZV0TAYlXJAQWsXeeBBnzrq RxpfQoVjKq034eaoYlpkvppvjl2xSovIidlZiBDY32Pf4PFQgZdVg+c1lncJ75Vcdgb3 KWow== X-Gm-Message-State: ALQs6tAc5WbxLEQ8Q3Owxl4q6dK1UECML+4qWgnoEo8Y/zCusVVoUvrT rRDWRJ5KEn03kIEWzkqBgUm4qI9RZ+rIY80FxN1iXQ== X-Google-Smtp-Source: AIpwx48/aInNzc+WfLkY+Nm/YC7dYXAGxOl8LnLmkhw20zkbqa6Yy59bEG02QEDQsn/2MZExLoNpvWLA98KTTnonhWs= X-Received: by 2002:aca:df44:: with SMTP id w65-v6mr8994117oig.155.1523656636824; Fri, 13 Apr 2018 14:57:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Fri, 13 Apr 2018 14:57:15 -0700 (PDT) In-Reply-To: <187AE9A0-E125-4B54-A286-488F52CB88B6@cisco.com> References: <187AE9A0-E125-4B54-A286-488F52CB88B6@cisco.com> From: Richard Barnes Date: Fri, 13 Apr 2018 17:57:15 -0400 Message-ID: To: "Acee Lindem (acee)" Cc: "BRUNGARD, DEBORAH A" , "secdir@ietf.org" , "russ@riw.us" , "Jeffrey Haas (jhaas@pfrc.org)" , "Stewart Bryant (stewart.bryant@gmail.com)" Content-Type: multipart/alternative; boundary="0000000000009915d80569c1f4e7" Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 21:57:21 -0000 --0000000000009915d80569c1f4e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, the elephant problem is part of why I was asking about deliverables -- it seems like even having the discussion could help us assemble a more complete picture of the elephant. I appreciate that "Security Considerations for X" can be a tempting target, but I honestly wonder whether they're worthwhile. Writing a guide to BGP that pounds its shoe on the table and says "DO BGPSEC!" is not going to substantively move the needle, just like all our shouting about IPsec and DNSSEC has been basically for nought. It would be good to avoid all the spinning of wheels that has been done in those domains in the cases where we're looking to improve routing security. FWIW, HTTPS is the one domain where there has been some real progress toward universal security. I would be glad to compare notes on what worked there, and see if we can translate anything to the routing domain. I wonder if it would be useful to start by evaluating what change needs to be made in the Internet. Which part of the elephant is the bleeding the worst? What are the risks that are causing the most harm today, which we should put the most effort into fixing? On Fri, Apr 13, 2018 at 5:25 PM, Acee Lindem (acee) wrote: > Hi Richard, > > When you talk about Routing Security, it is like the blind men and > elephant, everyone has a different opinion on what the priorities are. Fr= om > my viewpoint (and I do have one bad eye ;^), one of the outcomes should b= e > finding the right set of authors for protocol specific =E2=80=9CXXXX Secu= rity > Considerations=E2=80=9D documents where XXXX is BGP, IS-IS, OSPF, LDP, PI= M, etc. > Additionally, we=E2=80=99d provide a generic outline for these documents. > > Thanks, > Acee > > From: Richard Barnes > Date: Friday, April 13, 2018 at 4:21 PM > To: Deborah Brungard > Cc: "secdir@ietf.org" , Russ White , Jeff > Haas , Stewart Bryant , Acee > Lindem > Subject: Re: [secdir] New Routing Area Security Design Team > > (trimming the CC list a bit) > > Hey Deborah, > > Delighted to hear this news. Do you have an idea of what the initial > deliverables are for this group? What security problems are they going t= o > try to address? > > TBH, it seems like the headline problem at the Internet level is BGP > abuse. The base RPKI docs have been out for several years now, and BGPSE= C > is pretty much finished, but the deployment numbers continue to hover > around 8-9% for even the most basic protections. It would be delightful = to > have a group take a look at what the deployment blockers are here, and > whether there's anything the IETF could do to help, whether it's updating > protocols, producing deployment guides, writing code, etc. We shouldn't > think that RFCs are the only tool in our arsenal. > > Thanks, > --Richard > > [1] https://rpki-monitor.antd.nist.gov/ > > > On Fri, Apr 13, 2018 at 4:11 PM, BRUNGARD, DEBORAH A db3546@att.com> wrote: > The Routing ADs have chartered a design team as described below. > > I will be the AD-contact: mailto:db3546@att.com > > Routing Area Security Design Team Charter > > Internet security threats have evolved in the last couple of years and > questions are arising about the security properties of many long-standing > IETF routing protocols and new protocols under development. This is an > opportunity for the Routing Area to evaluate current assumptions and make > recommendations for new work. > > The Routing Area will kick off a Routing Area-wide Design team with > support from the OPS Area and Security Area. The first phase will consist > of a small team: > > Stewart Bryant mailto:stewart.bryant@gmail.com > Jeff Haas mailto:jhaas@pfrc.org > Acee Lindem mailto:acee@cisco.com > Russ White mailto:russ@riw.us > > They will be responsible to set up an environment (e..g. wiki), identify > work items, and coordinating overall the work effort. It is the expectati= on > this initial phase will be done by May 1. A second phase will consist of > small teams working on targeted items. Work items will include review of > current deployments (use models) and threat models, evaluation criteria a= nd > useful advice when doing new work (on existing protocols and new > protocols), and recommendations on where new work is needed in cooperatio= n > with the responsible working group. The work will have support from the > Security Area and OPS Area. > > The design team will have a private mailing list for this first phase and > can be reached at mailto:rt-dt-security@ietf.org. > > Regards, > Deborah > > > > _______________________________________________ > secdir mailing list > mailto:secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > > --0000000000009915d80569c1f4e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, the elephant problem is part of why I was askin= g about deliverables -- it seems like even having the discussion could help= us assemble a more complete picture of the elephant.

<= div>I appreciate that "Security Considerations for X" can be a te= mpting target, but I honestly wonder whether they're worthwhile.=C2=A0 = Writing a guide to BGP that pounds its shoe on the table and says "DO = BGPSEC!" is not going to substantively move the needle, just like all = our shouting about IPsec and DNSSEC has been basically for nought.

It would be good to avoid all the spinning of wheels that = has been done in those domains in the cases where we're looking to impr= ove routing security.=C2=A0 FWIW, HTTPS is the one domain where there has b= een some real progress toward universal security.=C2=A0 I would be glad to = compare notes on what worked there, and see if we can translate anything to= the routing domain.

I wonder if it would be u= seful to start by evaluating what change needs to be made in the Internet.= =C2=A0 Which part of the elephant is the bleeding the worst?=C2=A0 What are= the risks that are causing the most harm today, which we should put the mo= st effort into fixing?


On Fri, Apr 13, 2018 at 5:25 PM, Acee L= indem (acee) <acee@cisco.com> wrote:
Hi Richard,

When you talk about Routing Security, it is like the blind men and elephant= , everyone has a different opinion on what the priorities are. From my view= point (and I do have one bad eye ;^), one of the outcomes should be finding= the right set of authors for protocol specific =E2=80=9CXXXX Security Cons= iderations=E2=80=9D documents where XXXX is BGP, IS-IS, OSPF, LDP, PIM, etc= . Additionally, we=E2=80=99d provide a generic outline for these documents.=

Thanks,
Acee

From: Richard Barnes <rlb@ipv.sx>
Date: Friday, April 13, 2018 at 4:21 PM
To: Deborah Brungard <db3546@att.com>
Cc: "secdir@ietf.org" <= secdir@ietf.org>, Russ White <= russ@riw.us>, Jeff Haas <jhaas@pfrc.org>, Stewart Bryant <stewart.bryant@gmail.com>, Ac= ee Lindem <acee@cisco.com>
Subject: Re: [secdir] New Routing Area Security Design Team

(trimming the CC list a bit)

Hey Deborah,

Delighted to hear this news.=C2=A0 Do you have an idea of what the initial = deliverables are for this group?=C2=A0 What security problems are they goin= g to try to address?

TBH, it seems like the headline problem at the Internet level is BGP abuse.= =C2=A0 The base RPKI docs have been out for several years now, and BGPSEC i= s pretty much finished, but the deployment numbers continue to hover around= 8-9% for even the most basic protections.=C2=A0 It would be delightful to = have a group take a look at what the deployment blockers are here, and whet= her there's anything the IETF could do to help, whether it's updati= ng protocols, producing deployment guides, writing code, etc.=C2=A0 We shou= ldn't think that RFCs are the only tool in our arsenal.

Thanks,
--Richard

[1] https://rpki-monitor.antd.nist.gov/=C2=A0


On Fri, Apr 13, 2018 at 4:11 PM, BRUNGARD, DEBORAH = A <mailto:db3546@att.com> wrote= :
The Routing ADs have chartered a design team as described below.
=C2=A0
I will be the AD-contact: mailto:d= b3546@att.com
=C2=A0
Routing Area Security Design Team Charter
=C2=A0
Internet security threats have evolved in the last couple of years and ques= tions are arising about the security properties of many long-standing IETF = routing protocols and new protocols under development. This is an opportuni= ty for the Routing Area to evaluate current assumptions and make recommenda= tions for new work.
=C2=A0
The Routing Area will kick off a Routing Area-wide Design team with support= from the OPS Area and Security Area. The first phase will consist of a sma= ll team:
=C2=A0
Stewart Bryant mailto:st= ewart.bryant@gmail.com
Jeff Haas mailto:jhaas@pfrc.org
Acee Lindem mailto:acee@cisco.com
Russ White mailto:russ@riw.us
=C2=A0
They will be responsible to set up an environment (e..g. wiki), identify wo= rk items, and coordinating overall the work effort. It is the expectation t= his initial phase will be done by May 1. A second phase will consist of sma= ll teams working on targeted items. Work items will include review of curre= nt deployments (use models) and threat models, evaluation criteria and usef= ul advice when doing new work (on existing protocols and new protocols), an= d recommendations on where new work is needed in cooperation with the respo= nsible working group. The work will have support from the Security Area and= OPS Area.
=C2=A0
The design team will have a private mailing list for this first phas= e and can be reached at mailto:r= t-dt-security@ietf.org.
=C2=A0
Regards,
Deborah
=C2=A0
=C2=A0

_______________________________________________
secdir mailing list
mailto:secdir@ietf.org
https://www.ietf= .org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/= wiki/SecDirReview



--0000000000009915d80569c1f4e7-- From nobody Fri Apr 13 15:00:56 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18B6129C6D for ; Fri, 13 Apr 2018 15:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-Ei9XbD6r1P for ; Fri, 13 Apr 2018 15:00:52 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE52129C59 for ; Fri, 13 Apr 2018 15:00:52 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w3DLtnwN002537; Fri, 13 Apr 2018 18:00:49 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 2hb2mmb8nr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Apr 2018 18:00:49 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w3DLtlwk012421; Fri, 13 Apr 2018 17:55:47 -0400 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w3DLteSs012341; Fri, 13 Apr 2018 17:55:40 -0400 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id 6A4124014782; Fri, 13 Apr 2018 21:55:40 +0000 (GMT) Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (unknown [130.9.129.146]) by zlp27126.vci.att.com (Service) with ESMTPS id 54AB840006BE; Fri, 13 Apr 2018 21:55:40 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.210]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0361.001; Fri, 13 Apr 2018 17:55:40 -0400 From: "BRUNGARD, DEBORAH A" To: Richard Barnes CC: "secdir@ietf.org" , "russ@riw.us" , "Jeffrey Haas (jhaas@pfrc.org)" , "Stewart Bryant (stewart.bryant@gmail.com)" , "Acee Lindem (acee) (acee@cisco.com)" Thread-Topic: [secdir] New Routing Area Security Design Team Thread-Index: AdPTYCpdxrWraEBxSTyykispJqF3TQAJkpIAAAdQxTA= Date: Fri, 13 Apr 2018 21:55:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.240.56] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8882C7627MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-13_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804130202 Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 22:00:55 -0000 --_000_F64C10EAA68C8044B33656FA214632C8882C7627MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmljaGFyZCwNCg0KVGhhbmtzIGZvciB0aGUgbWFpbC0NCg0KSSBzZWUgQWNlZSBoYXMgYWxy ZWFkeSBhbnN3ZXJlZCDigJMgYXMgaGUgc2F5cyDigJMgdGhlIGZpcnN0IHN0ZXAgaXMgdG8gbmFp bCBkb3duIHdoYXQgYXJlIHRoZSByZWFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHZzLiB0aGUg YmxhbmtldCBvdmVyIHRvcCDigJxObyBuZXcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW50cm9k dWNlZOKAnS4NCg0KV2UgYWxsIGtub3cgdGhlcmUgaXMgYSBzaWduaWZpY2FudCB0aW1lIHdpbmRv dyBmb3IgZGVwbG95bWVudCBvZiBhbnkgbmV3IGNhcGFiaWxpdHkuIFRoZXJlIGFyZSBtYW55IGRl cGVuZGVuY2llcywgdmVuZG9ycyBub3Qgc3VwcG9ydGluZywgb3BlcmF0b3JzIG5vdCBnaXZpbmcg cHJpb3JpdHkuIEFuZCB0aGUg4oCcYmlnIG9uZeKAnSwgaXQgaXMgdmVyeSBkaWZmaWN1bHQgZm9y IGFuIG9wZXJhdG9yIHRvIHVwZ3JhZGUgaWYgZXZlcnl0aGluZyBpcyB3b3JraW5nIGZpbmUgdG9k YXkgYmVjYXVzZSB3ZSBhbGwga25vdyBhdCBsZWFzdCBvbmUgdXBncmFkZSBjbGFpbWluZyB0byBi ZSBmYWlsc2FmZSB3aGljaCB3ZW50IHdyb25nLiBXZSBjYW4gd3JpdGUgTU9Qcy9zaW11bGF0ZS90 ZXN0IGFsbCBkYXkgbG9uZywgYnV0IHRoZSBmb2xrcyDigJxwdXNoaW5nIHRoZSBidXR0b27igJ0g aW50byBwcm9kdWN0aW9uIGFyZSB0aGUgb25lcyB3aXRoIHRoZSBuZXJ2b3VzIGJyZWFrZG93bnMu DQoNCldlIHRyaWVkIHdpdGggS0FSUCB0byBpbXByb3ZlLCBidXQgaXQgd2FzIHZlcnkgZGlmZmlj dWx0LiBXaXRoIHRoaXMgdGVhbSwgd2Ugd2FudCB0byByZXZpZXcg4oCcd2hhdCBhcmUgdGhlIHVz ZSBjYXNlcy90aHJlYXQgbW9kZWxz4oCdLCDigJx3aGF0IHNob3VsZCBiZSB0aGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnPigJ0uIFRoZSB0YXJnZXQgaXMgdG8gdW5kZXJzdGFuZCB3aGVyZSB3ZSBj YW4gaW1wcm92ZSAtIGhhdmUgd2UgKElFVEYpIG1hZGUgYSBzbW9vdGggdHJhbnNpdGlvbiBvcGVy YXRpb25hbGx5IHBvc3NpYmxlPyBBcmUgdGhlcmUgZ2FwcyDigJMgc2VjdXJpdHkgb3Igb3BlcmF0 aW9uYWxseSB3aGljaCB3b3VsZCBoZWxwIGRlcGxveW1lbnRzPyBXZeKAmXZlIGFscmVhZHkgZGlz Y3Vzc2VkIHdpdGggdGhlIFNlY3VyaXR5IEFEcyBhbmQgT1BTIEFEcyDigJMgYW5kIHRoZXkgYXJl IHJlYWR5IHRvIHN1cHBvcnQgdXMgIOKAkyBob3BlZnVsbHkgdGhpcyB0aW1lIHdlIGNhbiBkbyBi ZXR0ZXIuDQoNCkFzIHlvdSBzYXkg4oCTIHdlIG5lZWQgbW9yZSB0aGFuIFJGQ3MgaWYgd2UgYXJl IHRvIHJhaXNlIGF3YXJlbmVzcy9zdXBwb3J0IGRlcGxveW1lbnQuIEFsbCBwb3NzaWJpbGl0aWVz IGFyZSBvbiB0aGUgdGFibGUuDQoNCkRlYm9yYWgNCg0KDQpGcm9tOiBSaWNoYXJkIEJhcm5lcyBb bWFpbHRvOnJsYkBpcHYuc3hdDQpTZW50OiBGcmlkYXksIEFwcmlsIDEzLCAyMDE4IDQ6MjEgUE0N ClRvOiBCUlVOR0FSRCwgREVCT1JBSCBBIDxkYjM1NDZAYXR0LmNvbT4NCkNjOiBzZWNkaXJAaWV0 Zi5vcmc7IHJ1c3NAcml3LnVzOyBKZWZmcmV5IEhhYXMgKGpoYWFzQHBmcmMub3JnKSA8amhhYXNA cGZyYy5vcmc+OyBTdGV3YXJ0IEJyeWFudCAoc3Rld2FydC5icnlhbnRAZ21haWwuY29tKSA8c3Rl d2FydC5icnlhbnRAZ21haWwuY29tPjsgQWNlZSBMaW5kZW0gKGFjZWUpIChhY2VlQGNpc2NvLmNv bSkgPGFjZWVAY2lzY28uY29tPg0KU3ViamVjdDogUmU6IFtzZWNkaXJdIE5ldyBSb3V0aW5nIEFy ZWEgU2VjdXJpdHkgRGVzaWduIFRlYW0NCg0KKHRyaW1taW5nIHRoZSBDQyBsaXN0IGEgYml0KQ0K DQpIZXkgRGVib3JhaCwNCg0KRGVsaWdodGVkIHRvIGhlYXIgdGhpcyBuZXdzLiAgRG8geW91IGhh dmUgYW4gaWRlYSBvZiB3aGF0IHRoZSBpbml0aWFsIGRlbGl2ZXJhYmxlcyBhcmUgZm9yIHRoaXMg Z3JvdXA/ICBXaGF0IHNlY3VyaXR5IHByb2JsZW1zIGFyZSB0aGV5IGdvaW5nIHRvIHRyeSB0byBh ZGRyZXNzPw0KDQpUQkgsIGl0IHNlZW1zIGxpa2UgdGhlIGhlYWRsaW5lIHByb2JsZW0gYXQgdGhl IEludGVybmV0IGxldmVsIGlzIEJHUCBhYnVzZS4gIFRoZSBiYXNlIFJQS0kgZG9jcyBoYXZlIGJl ZW4gb3V0IGZvciBzZXZlcmFsIHllYXJzIG5vdywgYW5kIEJHUFNFQyBpcyBwcmV0dHkgbXVjaCBm aW5pc2hlZCwgYnV0IHRoZSBkZXBsb3ltZW50IG51bWJlcnMgY29udGludWUgdG8gaG92ZXIgYXJv dW5kIDgtOSUgZm9yIGV2ZW4gdGhlIG1vc3QgYmFzaWMgcHJvdGVjdGlvbnMuICBJdCB3b3VsZCBi ZSBkZWxpZ2h0ZnVsIHRvIGhhdmUgYSBncm91cCB0YWtlIGEgbG9vayBhdCB3aGF0IHRoZSBkZXBs b3ltZW50IGJsb2NrZXJzIGFyZSBoZXJlLCBhbmQgd2hldGhlciB0aGVyZSdzIGFueXRoaW5nIHRo ZSBJRVRGIGNvdWxkIGRvIHRvIGhlbHAsIHdoZXRoZXIgaXQncyB1cGRhdGluZyBwcm90b2NvbHMs IHByb2R1Y2luZyBkZXBsb3ltZW50IGd1aWRlcywgd3JpdGluZyBjb2RlLCBldGMuICBXZSBzaG91 bGRuJ3QgdGhpbmsgdGhhdCBSRkNzIGFyZSB0aGUgb25seSB0b29sIGluIG91ciBhcnNlbmFsLg0K DQpUaGFua3MsDQotLVJpY2hhcmQNCg0KWzFdIGh0dHBzOi8vcnBraS1tb25pdG9yLmFudGQubmlz dC5nb3YvPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fcnBraS0yRG1vbml0b3IuYW50ZC5uaXN0Lmdvdl8mZD1Ed01GYVEmYz1MRllaLW85X0hVTWVN VFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZtPXRKZC1rclYySjdCWTE2MG1KN0Fo ME41M05HOUVKNU5xaWxvQ3h3cFhqd00mcz1EbXBEUUw4d0xGc1hiNkJ5cXpLT0dWV3V4ZEx0QzhC MGM5b2piTDE1M3JzJmU9Pg0KDQoNCk9uIEZyaSwgQXByIDEzLCAyMDE4IGF0IDQ6MTEgUE0sIEJS VU5HQVJELCBERUJPUkFIIEEgPGRiMzU0NkBhdHQuY29tPG1haWx0bzpkYjM1NDZAYXR0LmNvbT4+ IHdyb3RlOg0KVGhlIFJvdXRpbmcgQURzIGhhdmUgY2hhcnRlcmVkIGEgZGVzaWduIHRlYW0gYXMg ZGVzY3JpYmVkIGJlbG93Lg0KDQpJIHdpbGwgYmUgdGhlIEFELWNvbnRhY3Q6IGRiMzU0NkBhdHQu Y29tPG1haWx0bzpkYjM1NDZAYXR0LmNvbT4NCg0KUm91dGluZyBBcmVhIFNlY3VyaXR5IERlc2ln biBUZWFtIENoYXJ0ZXINCg0KSW50ZXJuZXQgc2VjdXJpdHkgdGhyZWF0cyBoYXZlIGV2b2x2ZWQg aW4gdGhlIGxhc3QgY291cGxlIG9mIHllYXJzIGFuZCBxdWVzdGlvbnMgYXJlIGFyaXNpbmcgYWJv dXQgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgbWFueSBsb25nLXN0YW5kaW5nIElFVEYgcm91 dGluZyBwcm90b2NvbHMgYW5kIG5ldyBwcm90b2NvbHMgdW5kZXIgZGV2ZWxvcG1lbnQuIFRoaXMg aXMgYW4gb3Bwb3J0dW5pdHkgZm9yIHRoZSBSb3V0aW5nIEFyZWEgdG8gZXZhbHVhdGUgY3VycmVu dCBhc3N1bXB0aW9ucyBhbmQgbWFrZSByZWNvbW1lbmRhdGlvbnMgZm9yIG5ldyB3b3JrLg0KDQpU aGUgUm91dGluZyBBcmVhIHdpbGwga2ljayBvZmYgYSBSb3V0aW5nIEFyZWEtd2lkZSBEZXNpZ24g dGVhbSB3aXRoIHN1cHBvcnQgZnJvbSB0aGUgT1BTIEFyZWEgYW5kIFNlY3VyaXR5IEFyZWEuIFRo ZSBmaXJzdCBwaGFzZSB3aWxsIGNvbnNpc3Qgb2YgYSBzbWFsbCB0ZWFtOg0KDQpTdGV3YXJ0IEJy eWFudCBzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb208bWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWls LmNvbT4NCkplZmYgSGFhcyBqaGFhc0BwZnJjLm9yZzxtYWlsdG86amhhYXNAcGZyYy5vcmc+DQpB Y2VlIExpbmRlbSBhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+DQpSdXNzIFdo aXRlIHJ1c3NAcml3LnVzPG1haWx0bzpydXNzQHJpdy51cz4NCg0KVGhleSB3aWxsIGJlIHJlc3Bv bnNpYmxlIHRvIHNldCB1cCBhbiBlbnZpcm9ubWVudCAoZS4uZy4gd2lraSksIGlkZW50aWZ5IHdv cmsgaXRlbXMsIGFuZCBjb29yZGluYXRpbmcgb3ZlcmFsbCB0aGUgd29yayBlZmZvcnQuIEl0IGlz IHRoZSBleHBlY3RhdGlvbiB0aGlzIGluaXRpYWwgcGhhc2Ugd2lsbCBiZSBkb25lIGJ5IE1heSAx LiBBIHNlY29uZCBwaGFzZSB3aWxsIGNvbnNpc3Qgb2Ygc21hbGwgdGVhbXMgd29ya2luZyBvbiB0 YXJnZXRlZCBpdGVtcy4gV29yayBpdGVtcyB3aWxsIGluY2x1ZGUgcmV2aWV3IG9mIGN1cnJlbnQg ZGVwbG95bWVudHMgKHVzZSBtb2RlbHMpIGFuZCB0aHJlYXQgbW9kZWxzLCBldmFsdWF0aW9uIGNy aXRlcmlhIGFuZCB1c2VmdWwgYWR2aWNlIHdoZW4gZG9pbmcgbmV3IHdvcmsgKG9uIGV4aXN0aW5n IHByb3RvY29scyBhbmQgbmV3IHByb3RvY29scyksIGFuZCByZWNvbW1lbmRhdGlvbnMgb24gd2hl cmUgbmV3IHdvcmsgaXMgbmVlZGVkIGluIGNvb3BlcmF0aW9uIHdpdGggdGhlIHJlc3BvbnNpYmxl IHdvcmtpbmcgZ3JvdXAuIFRoZSB3b3JrIHdpbGwgaGF2ZSBzdXBwb3J0IGZyb20gdGhlIFNlY3Vy aXR5IEFyZWEgYW5kIE9QUyBBcmVhLg0KDQpUaGUgZGVzaWduIHRlYW0gd2lsbCBoYXZlIGEgcHJp dmF0ZSBtYWlsaW5nIGxpc3QgZm9yIHRoaXMgZmlyc3QgcGhhc2UgYW5kIGNhbiBiZSByZWFjaGVk IGF0IHJ0LWR0LXNlY3VyaXR5QGlldGYub3JnPG1haWx0bzpydC1kdC1zZWN1cml0eUBpZXRmLm9y Zz4uDQoNClJlZ2FyZHMsDQpEZWJvcmFoDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kc2VjZGlyIG1haWxpbmcgbGlzdA0Kc2VjZGlyQGlldGYu b3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NlY2RpcjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3NlY2RpciZkPUR3TUZh USZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3Jm09dEpk LWtyVjJKN0JZMTYwbUo3QWgwTjUzTkc5RUo1TnFpbG9DeHdwWGp3TSZzPTlPVlZwdHRPdmo2RVZI bjM0UC1NallvYk5aYzFxbThwSzRwUkhyYzB4ZFEmZT0+DQp3aWtpOiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvYXJlYS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldzxodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fdG9vbHMuaWV0Zi5vcmdfYXJlYV9zZWNf dHJhY193aWtpX1NlY0RpclJldmlldyZkPUR3TUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcm cj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3Jm09dEpkLWtyVjJKN0JZMTYwbUo3QWgwTjUzTkc5RUo1 TnFpbG9DeHdwWGp3TSZzPWUxbVg2ejdEZ2FTazVSTHU2MjRNeVBQQ3Q0bHlLcF81UzJRNEI4Ul9S OVUmZT0+DQoNCg== --_000_F64C10EAA68C8044B33656FA214632C8882C7627MISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSBSaWNoYXJkLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSBtYWlsLTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNlZSBBY2VlIGhhcyBhbHJlYWR5IGFuc3dlcmVkIOKA kyBhcyBoZSBzYXlzIOKAkyB0aGUgZmlyc3Qgc3RlcCBpcyB0byBuYWlsIGRvd24gd2hhdCBhcmUg dGhlIHJlYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdnMuIHRoZSBibGFua2V0IG92ZXIgdG9w IOKAnE5vIG5ldyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbnRyb2R1Y2Vk4oCdLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XZSBhbGwga25vdyB0aGVyZSBpcyBhIHNpZ25pZmljYW50IHRpbWUg d2luZG93IGZvciBkZXBsb3ltZW50IG9mIGFueSBuZXcgY2FwYWJpbGl0eS4gVGhlcmUgYXJlIG1h bnkgZGVwZW5kZW5jaWVzLCB2ZW5kb3JzIG5vdCBzdXBwb3J0aW5nLCBvcGVyYXRvcnMgbm90IGdp dmluZyBwcmlvcml0eS4gQW5kIHRoZSDigJxiaWcgb25l4oCdLCBpdCBpcyB2ZXJ5IGRpZmZpY3Vs dCBmb3IgYW4gb3BlcmF0b3IgdG8gdXBncmFkZQ0KIGlmIGV2ZXJ5dGhpbmcgaXMgd29ya2luZyBm aW5lIHRvZGF5IGJlY2F1c2Ugd2UgYWxsIGtub3cgYXQgbGVhc3Qgb25lIHVwZ3JhZGUgY2xhaW1p bmcgdG8gYmUgZmFpbHNhZmUgd2hpY2ggd2VudCB3cm9uZy4gV2UgY2FuIHdyaXRlIE1PUHMvc2lt dWxhdGUvdGVzdCBhbGwgZGF5IGxvbmcsIGJ1dCB0aGUgZm9sa3Mg4oCccHVzaGluZyB0aGUgYnV0 dG9u4oCdIGludG8gcHJvZHVjdGlvbiBhcmUgdGhlIG9uZXMgd2l0aCB0aGUgbmVydm91cyBicmVh a2Rvd25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSB0cmllZCB3aXRoIEtBUlAgdG8gaW1w cm92ZSwgYnV0IGl0IHdhcyB2ZXJ5IGRpZmZpY3VsdC4gV2l0aCB0aGlzIHRlYW0sIHdlIHdhbnQg dG8gcmV2aWV3IOKAnHdoYXQgYXJlIHRoZSB1c2UgY2FzZXMvdGhyZWF0IG1vZGVsc+KAnSwg4oCc d2hhdCBzaG91bGQgYmUgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z4oCdLiBUaGUgdGFyZ2V0 IGlzIHRvIHVuZGVyc3RhbmQgd2hlcmUgd2UgY2FuIGltcHJvdmUgLSBoYXZlIHdlDQogKElFVEYp IG1hZGUgYSBzbW9vdGggdHJhbnNpdGlvbiBvcGVyYXRpb25hbGx5IHBvc3NpYmxlPyBBcmUgdGhl cmUgZ2FwcyDigJMgc2VjdXJpdHkgb3Igb3BlcmF0aW9uYWxseSB3aGljaCB3b3VsZCBoZWxwIGRl cGxveW1lbnRzPyBXZeKAmXZlIGFscmVhZHkgZGlzY3Vzc2VkIHdpdGggdGhlIFNlY3VyaXR5IEFE cyBhbmQgT1BTIEFEcyDigJMgYW5kIHRoZXkgYXJlIHJlYWR5IHRvIHN1cHBvcnQgdXMgJm5ic3A7 4oCTIGhvcGVmdWxseSB0aGlzIHRpbWUgd2UgY2FuIGRvIGJldHRlci48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QXMgeW91IHNheSDigJMgd2UgbmVlZCBtb3JlIHRoYW4gUkZDcyBpZiB3ZSBhcmUg dG8gcmFpc2UgYXdhcmVuZXNzL3N1cHBvcnQgZGVwbG95bWVudC4gQWxsIHBvc3NpYmlsaXRpZXMg YXJlIG9uIHRoZSB0YWJsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVib3JhaDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPkZyb206PC9iPiBSaWNoYXJkIEJhcm5lcyBbbWFpbHRvOnJsYkBpcHYuc3hdIDxicj4N CjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDEzLCAyMDE4IDQ6MjEgUE08YnI+DQo8Yj5Ubzo8 L2I+IEJSVU5HQVJELCBERUJPUkFIIEEgJmx0O2RiMzU0NkBhdHQuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gc2VjZGlyQGlldGYub3JnOyBydXNzQHJpdy51czsgSmVmZnJleSBIYWFzIChqaGFhc0Bw ZnJjLm9yZykgJmx0O2poYWFzQHBmcmMub3JnJmd0OzsgU3Rld2FydCBCcnlhbnQgKHN0ZXdhcnQu YnJ5YW50QGdtYWlsLmNvbSkgJmx0O3N0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbSZndDs7IEFjZWUg TGluZGVtIChhY2VlKSAoYWNlZUBjaXNjby5jb20pICZsdDthY2VlQGNpc2NvLmNvbSZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZWNkaXJdIE5ldyBSb3V0aW5nIEFyZWEgU2VjdXJpdHkg RGVzaWduIFRlYW08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4odHJpbW1p bmcgdGhlIENDIGxpc3QgYSBiaXQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhleSBEZWJvcmFoLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWxpZ2h0ZWQgdG8gaGVhciB0aGlzIG5ld3Mu Jm5ic3A7IERvIHlvdSBoYXZlIGFuIGlkZWEgb2Ygd2hhdCB0aGUgaW5pdGlhbCBkZWxpdmVyYWJs ZXMgYXJlIGZvciB0aGlzIGdyb3VwPyZuYnNwOyBXaGF0IHNlY3VyaXR5IHByb2JsZW1zIGFyZSB0 aGV5IGdvaW5nIHRvIHRyeSB0byBhZGRyZXNzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UQkgsIGl0IHNlZW1zIGxpa2UgdGhlIGhlYWRsaW5l IHByb2JsZW0gYXQgdGhlIEludGVybmV0IGxldmVsIGlzIEJHUCBhYnVzZS4mbmJzcDsgVGhlIGJh c2UgUlBLSSBkb2NzIGhhdmUgYmVlbiBvdXQgZm9yIHNldmVyYWwgeWVhcnMgbm93LCBhbmQgQkdQ U0VDIGlzIHByZXR0eSBtdWNoIGZpbmlzaGVkLCBidXQgdGhlIGRlcGxveW1lbnQgbnVtYmVycyBj b250aW51ZSB0byBob3ZlciBhcm91bmQgOC05JSBmb3IgZXZlbiB0aGUNCiBtb3N0IGJhc2ljIHBy b3RlY3Rpb25zLiZuYnNwOyBJdCB3b3VsZCBiZSBkZWxpZ2h0ZnVsIHRvIGhhdmUgYSBncm91cCB0 YWtlIGEgbG9vayBhdCB3aGF0IHRoZSBkZXBsb3ltZW50IGJsb2NrZXJzIGFyZSBoZXJlLCBhbmQg d2hldGhlciB0aGVyZSdzIGFueXRoaW5nIHRoZSBJRVRGIGNvdWxkIGRvIHRvIGhlbHAsIHdoZXRo ZXIgaXQncyB1cGRhdGluZyBwcm90b2NvbHMsIHByb2R1Y2luZyBkZXBsb3ltZW50IGd1aWRlcywg d3JpdGluZyBjb2RlLCBldGMuJm5ic3A7DQogV2Ugc2hvdWxkbid0IHRoaW5rIHRoYXQgUkZDcyBh cmUgdGhlIG9ubHkgdG9vbCBpbiBvdXIgYXJzZW5hbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS1SaWNoYXJkPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsxXSA8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Jwa2ktMkRt b25pdG9yLmFudGQubmlzdC5nb3ZfJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNR aWN2aklnJmFtcDtyPTZVaEdwVzlsd2k5ZE03allseFhEOHcmYW1wO209dEpkLWtyVjJKN0JZMTYw bUo3QWgwTjUzTkc5RUo1TnFpbG9DeHdwWGp3TSZhbXA7cz1EbXBEUUw4d0xGc1hiNkJ5cXpLT0dW V3V4ZEx0QzhCMGM5b2piTDE1M3JzJmFtcDtlPSI+DQpodHRwczovL3Jwa2ktbW9uaXRvci5hbnRk Lm5pc3QuZ292LzwvYT4mbmJzcDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBcHIgMTMsIDIwMTggYXQgNDoxMSBQTSwgQlJV TkdBUkQsIERFQk9SQUggQSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRiMzU0NkBhdHQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZGIzNTQ2QGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIFJv dXRpbmcgQURzIGhhdmUgY2hhcnRlcmVkIGEgZGVzaWduIHRlYW0gYXMgZGVzY3JpYmVkIGJlbG93 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB3aWxsIGJlIHRoZSBBRC1jb250YWN0Og0K PGEgaHJlZj0ibWFpbHRvOmRiMzU0NkBhdHQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGIzNTQ2QGF0 dC5jb208L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Sb3V0aW5nIEFyZWEgU2VjdXJp dHkgRGVzaWduIFRlYW0gQ2hhcnRlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW50ZXJu ZXQgc2VjdXJpdHkgdGhyZWF0cyBoYXZlIGV2b2x2ZWQgaW4gdGhlIGxhc3QgY291cGxlIG9mIHll YXJzIGFuZCBxdWVzdGlvbnMgYXJlIGFyaXNpbmcgYWJvdXQgdGhlIHNlY3VyaXR5IHByb3BlcnRp ZXMgb2YgbWFueSBsb25nLXN0YW5kaW5nIElFVEYgcm91dGluZyBwcm90b2NvbHMgYW5kIG5ldyBw cm90b2NvbHMNCiB1bmRlciBkZXZlbG9wbWVudC4gVGhpcyBpcyBhbiBvcHBvcnR1bml0eSBmb3Ig dGhlIFJvdXRpbmcgQXJlYSB0byBldmFsdWF0ZSBjdXJyZW50IGFzc3VtcHRpb25zIGFuZCBtYWtl IHJlY29tbWVuZGF0aW9ucyBmb3IgbmV3IHdvcmsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5UaGUgUm91dGluZyBBcmVhIHdpbGwga2ljayBvZmYgYSBSb3V0aW5nIEFyZWEtd2lkZSBEZXNp Z24gdGVhbSB3aXRoIHN1cHBvcnQgZnJvbSB0aGUgT1BTIEFyZWEgYW5kIFNlY3VyaXR5IEFyZWEu IFRoZSBmaXJzdCBwaGFzZSB3aWxsIGNvbnNpc3Qgb2YgYSBzbWFsbCB0ZWFtOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+U3Rld2FydCBCcnlhbnQNCjxhIGhyZWY9Im1haWx0bzpzdGV3YXJ0 LmJyeWFudEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zdGV3YXJ0LmJyeWFudEBnbWFpbC5j b208L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkplZmYgSGFhcw0K PGEgaHJlZj0ibWFpbHRvOmpoYWFzQHBmcmMub3JnIiB0YXJnZXQ9Il9ibGFuayI+amhhYXNAcGZy Yy5vcmc8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFjZWUgTGlu ZGVtDQo8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5hY2Vl QGNpc2NvLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UnVz cyBXaGl0ZQ0KPGEgaHJlZj0ibWFpbHRvOnJ1c3NAcml3LnVzIiB0YXJnZXQ9Il9ibGFuayI+cnVz c0ByaXcudXM8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGV5IHdpbGwgYmUgcmVz cG9uc2libGUgdG8gc2V0IHVwIGFuIGVudmlyb25tZW50IChlLi5nLiB3aWtpKSwgaWRlbnRpZnkg d29yayBpdGVtcywgYW5kIGNvb3JkaW5hdGluZyBvdmVyYWxsIHRoZSB3b3JrIGVmZm9ydC4gSXQg aXMgdGhlIGV4cGVjdGF0aW9uIHRoaXMgaW5pdGlhbCBwaGFzZSB3aWxsIGJlIGRvbmUNCiBieSBN YXkgMS4gQSBzZWNvbmQgcGhhc2Ugd2lsbCBjb25zaXN0IG9mIHNtYWxsIHRlYW1zIHdvcmtpbmcg b24gdGFyZ2V0ZWQgaXRlbXMuIFdvcmsgaXRlbXMgd2lsbCBpbmNsdWRlIHJldmlldyBvZiBjdXJy ZW50IGRlcGxveW1lbnRzICh1c2UgbW9kZWxzKSBhbmQgdGhyZWF0IG1vZGVscywgZXZhbHVhdGlv biBjcml0ZXJpYSBhbmQgdXNlZnVsIGFkdmljZSB3aGVuIGRvaW5nIG5ldyB3b3JrIChvbiBleGlz dGluZyBwcm90b2NvbHMgYW5kIG5ldyBwcm90b2NvbHMpLA0KIGFuZCByZWNvbW1lbmRhdGlvbnMg b24gd2hlcmUgbmV3IHdvcmsgaXMgbmVlZGVkIGluIGNvb3BlcmF0aW9uIHdpdGggdGhlIHJlc3Bv bnNpYmxlIHdvcmtpbmcgZ3JvdXAuIFRoZSB3b3JrIHdpbGwgaGF2ZSBzdXBwb3J0IGZyb20gdGhl IFNlY3VyaXR5IEFyZWEgYW5kIE9QUyBBcmVhLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ VGhlIGRlc2lnbiB0ZWFtIHdpbGwgaGF2ZSBhIHByaXZhdGUgbWFpbGluZyBsaXN0IGZvciB0aGlz IGZpcnN0IHBoYXNlIGFuZCBjYW4gYmUgcmVhY2hlZCBhdA0KPGEgaHJlZj0ibWFpbHRvOnJ0LWR0 LXNlY3VyaXR5QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnQtZHQtc2VjdXJpdHlAaWV0Zi5v cmc8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RGVib3JhaDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNlY2RpciBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19zZWNkaXImYW1wO2Q9 RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9NlVoR3BXOWx3aTlkTTdq WWx4WEQ4dyZhbXA7bT10SmQta3JWMko3QlkxNjBtSjdBaDBONTNORzlFSjVOcWlsb0N4d3BYandN JmFtcDtzPTlPVlZwdHRPdmo2RVZIbjM0UC1NallvYk5aYzFxbThwSzRwUkhyYzB4ZFEmYW1wO2U9 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZWNkaXI8L2E+PGJyPg0Kd2lraTogPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3Rvb2xzLmlldGYub3JnX2FyZWFfc2VjX3RyYWNfd2lr aV9TZWNEaXJSZXZpZXcmYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcm YW1wO3I9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZhbXA7bT10SmQta3JWMko3QlkxNjBtSjdBaDBO NTNORzlFSjVOcWlsb0N4d3BYandNJmFtcDtzPWUxbVg2ejdEZ2FTazVSTHU2MjRNeVBQQ3Q0bHlL cF81UzJRNEI4Ul9SOVUmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvYXJlYS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldzwvYT48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F64C10EAA68C8044B33656FA214632C8882C7627MISOUT7MSGUSRDE_-- From nobody Fri Apr 13 16:51:42 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFB112711B for ; Fri, 13 Apr 2018 16:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5zSyaiH8T7W for ; Fri, 13 Apr 2018 16:51:38 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F32A41270AE for ; Fri, 13 Apr 2018 16:51:37 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 668AB1E403; Fri, 13 Apr 2018 19:52:25 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C4EC7928-869B-433D-B577-1B248B975847" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: Date: Fri, 13 Apr 2018 19:51:35 -0400 Cc: "BRUNGARD, DEBORAH A" , "secdir@ietf.org" , "russ@riw.us" , "Stewart Bryant (stewart.bryant@gmail.com)" , "Acee Lindem (acee) (acee@cisco.com)" Message-Id: References: To: Richard Barnes X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 23:51:41 -0000 --Apple-Mail=_C4EC7928-869B-433D-B577-1B248B975847 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Richard, This is where I have to say that I think we're too broadly chartered. = It's also a bit more than I believed I was signing up for. The initial motivation to start this was the further "what do we do = about tcp-md5" that the MPLS protocols are dealing with now. And = further, it's a bit about how to reduce the frustrating dance we have = between routing (and other areas?) and security-focused groups during = the RFC process. See my slides I did for IEPG to give an idea of some of what at least I = think we'd like to see come out of this: http://iepg.org/2018-03-18-ietf101/haas-iepg-101.pdf I would like to see us start by focusing on transport security = considerations for routing protocols. KARP obviously covered a lot of = this ground, especially surrounding bootstrapping issues. I'd love to = see pragmatic answers that fit into what we want to deploy today and = tomorrow rather than perfect answers which require full new technology = sets to be built. An output of this would be a set of common boilerplates that can be = maintained by the security experts for inclusion into routing protocol = documents. These boilerplates would vary based on needed transport = properties required by the protocol and its data. (And yes, this may = include a null profile, no security, no authentication, no = authorization, and no integrity.) The goal is that when it's time for a = protocol to be written, transport security is understood up front and = may simply be included in the document in text that is consistent with = verbiage expected by the security community, and understandable by the = authors of the new protocol. A related and separate bit of work would be recommendations and = practices for taking older insecure protocols and adding appropriate = transport security on top of them. --- As a complete aside, I think an effort like this is inappropriate for = "BGP abuse". I consider myself moderately studied in a good portion of = the RPKI problem space, although the certificate juggling makes my head = hurt. The issues that are present in that area are deployment related, = chicken-and-egg bootstrapping and honestly simple demand. IMNSHO, the = IETF has done its work. The rest of the work needs to come from = operational forums and vendors. =20 I'm happy to offer commentary there, but I really don't believe this is = the best place to put our initial effort. -- Jeff > On Apr 13, 2018, at 4:20 PM, Richard Barnes wrote: >=20 > (trimming the CC list a bit) >=20 > Hey Deborah, >=20 > Delighted to hear this news. Do you have an idea of what the initial = deliverables are for this group? What security problems are they going = to try to address? >=20 > TBH, it seems like the headline problem at the Internet level is BGP = abuse. The base RPKI docs have been out for several years now, and = BGPSEC is pretty much finished, but the deployment numbers continue to = hover around 8-9% for even the most basic protections. It would be = delightful to have a group take a look at what the deployment blockers = are here, and whether there's anything the IETF could do to help, = whether it's updating protocols, producing deployment guides, writing = code, etc. We shouldn't think that RFCs are the only tool in our = arsenal. >=20 > Thanks, > --Richard >=20 > [1] https://rpki-monitor.antd.nist.gov/ = =20 >=20 >=20 > On Fri, Apr 13, 2018 at 4:11 PM, BRUNGARD, DEBORAH A > wrote: > The Routing ADs have chartered a design team as described below. >=20 > =20 >=20 > I will be the AD-contact: db3546@att.com > =20 >=20 > Routing Area Security Design Team Charter >=20 > =20 >=20 > Internet security threats have evolved in the last couple of years and = questions are arising about the security properties of many = long-standing IETF routing protocols and new protocols under = development. This is an opportunity for the Routing Area to evaluate = current assumptions and make recommendations for new work. >=20 > =20 >=20 > The Routing Area will kick off a Routing Area-wide Design team with = support from the OPS Area and Security Area. The first phase will = consist of a small team: >=20 > =20 >=20 > Stewart Bryant stewart.bryant@gmail.com = > Jeff Haas jhaas@pfrc.org > Acee Lindem acee@cisco.com > Russ White russ@riw.us > =20 >=20 > They will be responsible to set up an environment (e..g. wiki), = identify work items, and coordinating overall the work effort. It is the = expectation this initial phase will be done by May 1. A second phase = will consist of small teams working on targeted items. Work items will = include review of current deployments (use models) and threat models, = evaluation criteria and useful advice when doing new work (on existing = protocols and new protocols), and recommendations on where new work is = needed in cooperation with the responsible working group. The work will = have support from the Security Area and OPS Area. >=20 > =20 >=20 > The design team will have a private mailing list for this first phase = and can be reached at rt-dt-security@ietf.org = . >=20 > =20 >=20 > Regards, >=20 > Deborah >=20 > =20 >=20 > =20 >=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir = > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview = >=20 >=20 --Apple-Mail=_C4EC7928-869B-433D-B577-1B248B975847 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Richard,

This is where I have to say that I think we're too broadly = chartered.  It's also a bit more than I believed I was signing up = for.

The = initial motivation to start this was the further "what do we do about = tcp-md5" that the MPLS protocols are dealing with now.  And = further, it's a bit about how to reduce the frustrating dance we have = between routing (and other areas?) and security-focused groups during = the RFC process.

See my slides I did for IEPG to give an idea of some of what = at least I think we'd like to see come out of this:

http://iepg.org/2018-03-18-ietf101/haas-iepg-101.pdf
<= div class=3D"">
I would like to see = us start by focusing on transport security considerations for routing = protocols.  KARP obviously covered a lot of this ground, especially = surrounding bootstrapping issues. I'd love to see pragmatic answers that = fit into what we want to deploy today and tomorrow rather than perfect = answers which require full new technology sets to be built.

An output of this would = be a set of common boilerplates that can be maintained by the security = experts for inclusion into routing protocol documents.  These = boilerplates would vary based on needed transport properties required by = the protocol and its data.  (And yes, this may include a null = profile, no security, no authentication, no authorization, and no = integrity.)  The goal is that when it's time for a protocol to be = written, transport security is understood up front  and may simply = be included in the document in text that is consistent with verbiage = expected by the security community, and understandable by the authors of = the new protocol.

A related and separate bit of work would be recommendations = and practices for taking older insecure protocols and adding appropriate = transport security on top of them.

---

As a complete aside, I think an effort = like this is inappropriate for "BGP abuse".  I consider myself = moderately studied in a good portion of the RPKI problem space, although = the certificate juggling makes my head hurt.  The issues that are = present in that area are deployment related, chicken-and-egg = bootstrapping and honestly simple demand.  IMNSHO, the IETF has = done its work.  The rest of the work needs to come from operational = forums and vendors.  

I'm happy to offer commentary there, but I really don't = believe this is the best place to put our initial effort.

-- Jeff

On Apr 13, 2018, at 4:20 PM, Richard Barnes <rlb@ipv.sx> wrote:

(trimming the CC list a bit)

Hey = Deborah,

Delighted to hear this news.  Do you have an idea of = what the initial deliverables are for this group?  What security = problems are they going to try to address?

TBH, it seems like the headline problem = at the Internet level is BGP abuse.  The base RPKI docs have been = out for several years now, and BGPSEC is pretty much finished, but the = deployment numbers continue to hover around 8-9% for even the most basic = protections.  It would be delightful to have a group take a look at = what the deployment blockers are here, and whether there's anything the = IETF could do to help, whether it's updating protocols, producing = deployment guides, writing code, etc.  We shouldn't think that RFCs = are the only tool in our arsenal.

Thanks,
--Richard

[1]= https://rpki-monitor.antd.nist.gov/ 


On Fri, = Apr 13, 2018 at 4:11 PM, BRUNGARD, DEBORAH A <db3546@att.com> wrote:

The Routing ADs have chartered a design team as = described below.

 

I will be the AD-contact: db3546@att.com

 

Routing Area Security Design Team Charter

 

Internet= security threats have evolved in the last couple of years and questions = are arising about the security properties of many long-standing IETF = routing protocols and new protocols under development. This is an = opportunity for the Routing Area to evaluate current assumptions and make recommendations = for new work.

 

The Routing Area will kick off a Routing Area-wide = Design team with support from the OPS Area and Security Area. The first = phase will consist of a small team:

 

Stewart Bryant stewart.bryant@gmail.com

Jeff Haas jhaas@pfrc.org

Acee Lindem acee@cisco.com

Russ White russ@riw.us

 

They = will be responsible to set up an environment (e..g. wiki), identify work = items, and coordinating overall the work effort. It is the expectation = this initial phase will be done by May 1. A second phase will consist of = small teams working on targeted items. Work items will include review of current = deployments (use models) and threat models, evaluation criteria and = useful advice when doing new work (on existing protocols and new = protocols), and recommendations on where new work is needed in cooperation with the responsible working group. The work will have = support from the Security Area and OPS Area.

 

The design team will have a = private mailing list for this first phase and can be reached at rt-dt-security@ietf.org.

 

Regards,

Deborah

 

 


_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



= --Apple-Mail=_C4EC7928-869B-433D-B577-1B248B975847-- From nobody Sun Apr 15 10:47:28 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893421241F5 for ; Sun, 15 Apr 2018 10:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42KLNvdBgrj6 for ; Sun, 15 Apr 2018 10:47:24 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD1D12025C for ; Sun, 15 Apr 2018 10:47:24 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1f7lkG-0003GM-Fc for secdir@ietf.org; Sun, 15 Apr 2018 19:47:22 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1f7lkB-0004cc-Uu for secdir@ietf.org; Sun, 15 Apr 2018 13:47:16 -0400 Received: (qmail 17180 invoked from network); 15 Apr 2018 17:47:13 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.78]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 15 Apr 2018 17:47:13 -0000 To: Jeffrey Haas , Richard Barnes Cc: "russ@riw.us" , "Stewart Bryant (stewart.bryant@gmail.com)" , "Acee Lindem (acee) (acee@cisco.com)" , "BRUNGARD, DEBORAH A" , "secdir@ietf.org" References: From: Christian Huitema Openpgp: preference=signencrypt Message-ID: Date: Sun, 15 Apr 2018 10:47:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.190 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.30) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5g/MGf5DVpXP7VnanbAMTDR602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzniiMFxnOFMHTZqw+apvQzTV/3OdXD2Xdo8CfrY5CQSdUyILakm1B6j4EqeBiHxS4yz NJVaeAWax4WOe4pTBX2DwIE7VKe+bqpcdCns72R1x38mofTGICQnWDciwf9bB05EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2Drvl3AsHuisl/RSyh5DLe 1OidX4Ts4xdG+C13IyWeZaKid9CBwzS7yU76bfQz3+/HF8FcHzzV3acxBudgYcInb4eCDr2QZH+Q 37woHP+EKZiZ4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZXUaHqdOKLJ13TYQgD1U8MFwBl1z1+w2zS/h3e6UiVRejQqfk8Q7Mpq4B CSYZAEsuuvj1Dh5lQ3cVGT6zEzwcQmeqA47D/juB1cx4exzYk7wIdHXqmiNP5dvI77+8YOq/647l NwN4qOsSZg+fYhVZG9EQ9b9YI+9ZsqMLtlmzzH7VwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 17:47:26 -0000 On 4/13/2018 4:51 PM, Jeffrey Haas wrote: > The initial motivation to start this was the further "what do we do > about tcp-md5" that the MPLS protocols are dealing with now. =A0And > further, it's a bit about how to reduce the frustrating dance we have > between routing (and other areas?) and security-focused groups during > the RFC process. > > See my slides I did for IEPG to give an idea of some of what at least > I think we'd like to see come out of this: > > http://iepg.org/2018-03-18-ietf101/haas-iepg-101.pdf So basically you are debating which protected transport to use for routing protocols. That's certainly an issue that needs solving, but it has a feeling of focusing on the solution before debating the problem. As Richard said, the headline issue for outsiders like me is BGP hijacking, whether as a mean to hijack addresses and inject spam, or as a way to detour Wall Street's traffic through Belarus. It seems that the first step in router security would be to analyze these attacks, from BGP hijacking to the control plane attacks that you mention. Replacing TCP-MD5 by TCP-AO or DTLS may be part of the solution, but the problem is bigger than that. -- Christian Huitema From nobody Sun Apr 15 11:04:43 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4B6126CC4 for ; Sun, 15 Apr 2018 11:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4M1wOgqXHRbx for ; Sun, 15 Apr 2018 11:04:40 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682101201FA for ; Sun, 15 Apr 2018 11:04:40 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8C9BC21AE4; Sun, 15 Apr 2018 14:04:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sun, 15 Apr 2018 14:04:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Ea1aBh 2hlNcOd0prNrhUehEOctRJkDmhwmnYX3lyRSg=; b=V8d3DD3t1TW2Mt+dikqbLu DVFkF2TySFKLTUXWzOi9jOw09tCusyJNpCIdY/npjVVJPDZzUeUMlcK5yYc/Cat3 cjepKue3PQCg4GEkVQg7jqIy4F8u9sQC2/Z5QBA29tI9+ynHDTPiFw6L51EYWqIz /NYmwu2hqb+TvXuuadQLvH4Uce61J98PiBSADkXgeK1lw34M6Pa2pOxTJku9HOhs n79tWYFVFLp8X7JcCEAEcg9ALjLNDGAxiBQ02EhRz2UIhZ8Q171VasiX1SjlMOUh pvCxLq1g7VUVktNbLE3qucbAdUSeymmFbbnfTCH3xUwh3gWH0wU+U5NRo37o4u1Q == X-ME-Sender: Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net [162.229.180.77]) by mail.messagingengine.com (Postfix) with ESMTPA id 0E7AC10256; Sun, 15 Apr 2018 14:04:39 -0400 (EDT) From: "Russ White" To: "'Christian Huitema'" , "'Jeffrey Haas'" , "'Richard Barnes'" Cc: "'Stewart Bryant'" , "'Acee Lindem \(acee\)'" , "'BRUNGARD, DEBORAH A'" , References: In-Reply-To: Date: Sun, 15 Apr 2018 14:04:37 -0400 Message-ID: <026301d3d4e4$380d8b00$a828a100$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIXNZBmczwARyMumKcTrqeA3r6qigBoV+JkAj23bD0BpoR9waNY99Kg Content-Language: en-us Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 18:04:42 -0000 > As Richard said, the headline issue for outsiders like me is BGP = hijacking, > whether as a mean to hijack addresses and inject spam, or as a way to This is more about documenting how routing folks should build their = security considerations sections to reduce the friction between the = security area and the routing area. A much more prosaic situation, I = know... =F0=9F=98=8A If you'd like to chat about the BGP hijack problem, ping me. It's not = something I'm interested in trying to "solve" in the context of the IETF = any longer, for various reasons.=20 =F0=9F=98=8A Russ=20 From nobody Sun Apr 15 12:27:35 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B569512708C for ; Sun, 15 Apr 2018 12:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXiwLy73N8g7 for ; Sun, 15 Apr 2018 12:27:32 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2129B126CE8 for ; Sun, 15 Apr 2018 12:27:32 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 440511E401; Sun, 15 Apr 2018 15:28:23 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: <026301d3d4e4$380d8b00$a828a100$@riw.us> Date: Sun, 15 Apr 2018 15:27:30 -0400 Cc: Christian Huitema , Richard Barnes , Stewart Bryant , "Acee Lindem (acee)" , "BRUNGARD, DEBORAH A" , secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> References: <026301d3d4e4$380d8b00$a828a100$@riw.us> To: Russ White X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 19:27:34 -0000 > On Apr 15, 2018, at 2:04 PM, Russ White wrote: >=20 >=20 >> As Richard said, the headline issue for outsiders like me is BGP = hijacking, >> whether as a mean to hijack addresses and inject spam, or as a way to >=20 > This is more about documenting how routing folks should build their = security considerations sections to reduce the friction between the = security area and the routing area. A much more prosaic situation, I = know... =F0=9F=98=8A ^This. >=20 > If you'd like to chat about the BGP hijack problem, ping me. It's not = something I'm interested in trying to "solve" in the context of the IETF = any longer, for various reasons.=20 Right. Please save this bit of ocean boiling for elsewhere. Like over = beer. -- Jeff From nobody Mon Apr 16 05:13:22 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843231241FC for ; Mon, 16 Apr 2018 05:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo1oev3CSha1 for ; Mon, 16 Apr 2018 05:13:19 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4252B126E64 for ; Mon, 16 Apr 2018 05:13:19 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id e123-v6so14250244oih.13 for ; Mon, 16 Apr 2018 05:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LUdyyOq3AV9hQKPqM4MkK9JMEAG65x0BoSsVBE+ksKA=; b=19jTIrEf/iPUw4cESR5rgtxJHcJZG/OT/H6C/jjqvvJ7JmOOb8g86Up3Va1F/8u8bo Rv/bj5u8iJqEyfKDfkfbc9nbncb96HQqe4lzhU3c7ITE3cqUL6jrY8399PqTiZKnT5Hi X8fwnDhI5oG2Ch7alxp7KniNvegp6C41yC9f4FyCUsKwfeusQIpXv6GvuTazyhHRykFu Ormm01Hy6DXxxM1kgX1a17RQ/Rj0lKJMwt3y5cklHMSURT9ID9m7Pznu9uDnRSFoVCjq o+KFnu9bVqDHcjvdVH20vFIHY4GpICyw+np5BCGnaaQcdCOpbJ68ZGeteRA7DCN9ttZA dncQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LUdyyOq3AV9hQKPqM4MkK9JMEAG65x0BoSsVBE+ksKA=; b=eClE0Xj1znDfQtFQvzwif+LU/3BU3wD8wEUfc02CS8DVwVx6ucfDvDLeDqbKUejdHe 2w0uBOGxrsFpGLF53DkC4QCkB6+v+/IzmqWfZHXvchbJM4e2CH1SdimVeGtaL2KxMrNT TMNUKbYqALDtW4V2yCK06NVybCDDgY+V5iyE4AlvcpiJuxuljLDRHcQs9aPjHvyLEaO6 HG6qPfMjGadafHJcsxUzs7Jgy6KSFaPUcGrk6tkAFUPtUig9UNB7T4n6rYiq3pYpqTbM KtsR4iAn3t2hHMFaFGRKNyqWszNztdULpkYTny+p/NGVJSL5NuRKi6dZgHAdUzQ88Zm+ IJVg== X-Gm-Message-State: ALQs6tAWbPgy33CibpGCNSHgV0cFtSIdldK+2Vl5l4UeKgHR0FLv8FPk 5X2Qx2YTlsw3PGQmuBSQ0XpiVvDqe3y7kJT4zahu3w== X-Google-Smtp-Source: AIpwx4+UboDSy5Svs3ltv3fOJnBnMKb6k/LQ9xaBHYuHvtdEd2kDA7Xn3uKlrrmYAfL/Q+UDVQFwJwhCLwkQwQEhtNc= X-Received: by 2002:aca:df44:: with SMTP id w65-v6mr13704751oig.155.1523880798344; Mon, 16 Apr 2018 05:13:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Mon, 16 Apr 2018 05:13:17 -0700 (PDT) In-Reply-To: <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> References: <026301d3d4e4$380d8b00$a828a100$@riw.us> <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> From: Richard Barnes Date: Mon, 16 Apr 2018 08:13:17 -0400 Message-ID: To: Jeffrey Haas Cc: Russ White , Christian Huitema , Stewart Bryant , "Acee Lindem (acee)" , "BRUNGARD, DEBORAH A" , secdir Content-Type: multipart/alternative; boundary="000000000000aa6b850569f62504" Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 12:13:21 -0000 --000000000000aa6b850569f62504 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 15, 2018 at 3:27 PM, Jeffrey Haas wrote: > > > On Apr 15, 2018, at 2:04 PM, Russ White wrote: > > > > > >> As Richard said, the headline issue for outsiders like me is BGP > hijacking, > >> whether as a mean to hijack addresses and inject spam, or as a way to > > > > This is more about documenting how routing folks should build their > security considerations sections to reduce the friction between the > security area and the routing area. A much more prosaic situation, I > know... =F0=9F=98=8A > > ^This. > > > > > > If you'd like to chat about the BGP hijack problem, ping me. It's not > something I'm interested in trying to "solve" in the context of the IETF > any longer, for various reasons. > > Right. Please save this bit of ocean boiling for elsewhere. Like over > beer. > Part of the problem here is that the routing community seems to regard these issues as separate. Security analysis happens in the context of a threat model -- what is the valuable thing you're protecting, and what are you protecting it from? If you want to say you're talking about routing security, you need to either address the whole spectrum of threats (not just, say, local threats due to poorly protected transport), or have some plausible story for why certain threats should be out of scope. What Christian and I are saying is that BGP manipulation is an active, major threat to the Internet, so it seems odd to us to rule it out of scope. "Ocean boiling" is part of the IETF's job description. We made the ocean, and if it's the wrong temperature, it's our fault. And it's not impossible. HTTPS usage has gone from <30% to >70% in less than five years [1]. Even IPv6 is in the range of 20% now [2]. --Richard [1] https://letsencrypt.org/stats/ [2] https://www.google.com/intl/en/ipv6/statistics.html --000000000000aa6b850569f62504 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Apr 15, 2018 at 3:27 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

> On Apr 15, 2018, at 2:04 PM, Russ White <russ@riw.us> wrote:
>
>
>> As Richard said, the headline issue for outsiders like me is BGP h= ijacking,
>> whether as a mean to hijack addresses and inject spam, or as a way= to
>
> This is more about documenting how routing folks should build their se= curity considerations sections to reduce the friction between the security = area and the routing area. A much more prosaic situation, I know... =F0=9F= =98=8A

^This.


>
> If you'd like to chat about the BGP hijack problem, ping me. It= 9;s not something I'm interested in trying to "solve" in the = context of the IETF any longer, for various reasons.

Right.=C2=A0 Please save this bit of ocean boiling for elsewhere. Li= ke over beer.

Part of the problem here = is that the routing community seems to regard these issues as separate.=C2= =A0

Security analysis happens in the context = of a threat model -- what is the valuable thing you're protecting, and = what are you protecting it from?=C2=A0 If you want to say you're talkin= g about routing security, you need to either address the whole spectrum of = threats (not just, say, local threats due to poorly protected transport), o= r have some plausible story for why certain threats should be out of scope.= =C2=A0 What Christian and I are saying is that BGP manipulation is an activ= e, major threat to the Internet, so it seems odd to us to rule it out of sc= ope.

"Ocean boiling" is part of the IETF's job de= scription.=C2=A0 We made the ocean, and if it's the wrong temperature, = it's our fault.

And it's not impossible.=C2=A0 HTTPS usage has gone from = <30% to >70% in less than five years [1].=C2=A0 Even IPv6 is in the r= ange of 20% now [2].=C2=A0

<= div class=3D"gmail_extra">--Richard


[1] https://letsencrypt.org/stats/
[2] https://www.google.com/intl/en/ipv6/statistics.html=

--000000000000aa6b850569f62504-- From nobody Mon Apr 16 05:40:56 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39681241FC for ; Mon, 16 Apr 2018 05:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckVGvpfIpM-1 for ; Mon, 16 Apr 2018 05:40:52 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 05339127137 for ; Mon, 16 Apr 2018 05:40:50 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 369731E401; Mon, 16 Apr 2018 08:41:43 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_677D57AE-CF4C-4CA9-B5D3-A457646FFD4B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: Date: Mon, 16 Apr 2018 08:40:49 -0400 Cc: Russ White , Christian Huitema , Stewart Bryant , "Acee Lindem (acee)" , "BRUNGARD, DEBORAH A" , secdir Message-Id: <2AD240AE-DF39-4D76-8D6B-BB8AADC6C267@pfrc.org> References: <026301d3d4e4$380d8b00$a828a100$@riw.us> <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> To: Richard Barnes X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 12:40:55 -0000 --Apple-Mail=_677D57AE-CF4C-4CA9-B5D3-A457646FFD4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Richard, > On Apr 16, 2018, at 8:13 AM, Richard Barnes wrote: > On Sun, Apr 15, 2018 at 3:27 PM, Jeffrey Haas > wrote: > Right. Please save this bit of ocean boiling for elsewhere. Like over = beer. >=20 > Part of the problem here is that the routing community seems to regard = these issues as separate. =20 You're inferring a bit much, but I think we're both speaking = over-broadly. >=20 > Security analysis happens in the context of a threat model -- what is = the valuable thing you're protecting, and what are you protecting it = from? If you want to say you're talking about routing security, you = need to either address the whole spectrum of threats (not just, say, = local threats due to poorly protected transport), or have some plausible = story for why certain threats should be out of scope. What Christian = and I are saying is that BGP manipulation is an active, major threat to = the Internet, so it seems odd to us to rule it out of scope. In the specific case of BGP, a core and fundamental property of it is = that each router along the way is allowed to tinker with the contents of = a significant portion of the UPDATE message. The pieces of it that = generate concern are: - The fact that you can mis-originate reachability that does not = "belong" to you. RPKI ROAs were crafted to address this piece, along = with the rpki-rtr protocol to transmit information to a BGP speaker to = perform validation of permitted origination. - The fact that you can intentionally mis-represent the path an UPDATE = traverses either accidentally as part of normal prepending operations or = maliciously in an attempt to cause traffic to be misrouted. bgpsec was = crafted to address this issue in conjunction with the RPKI. - The fact that even with these mechanisms, it's possible to re-announce = routes in violation of expectations or contract in such a way that = traffic is not per-se hijacked but rather leaked in a way that violates = expectations, contract or even simple capacity. There's a body of work = going on in grow and idr under the umbrella of "route leaking" trying to = address this. - The fact that some of these mechanisms do not cover information = contained in UPDATE messages that may have control impact on routing; = e.g. communities and other loop detection information such as = cluster-lists, etc. This work was originally ruled out of scope in SIDR = for Internet use. We're not ignoring this. The above works are the right pieces covering = the appropriate bit of ecosystem. =20 RFC 4272 is likely due for a general refresher. BGP transport security is a known issue and theoretically "done" - use = TCP-AO. See my slides. See also the fact that IPSec can be utilized as = well, albeit with known bootstrapping headaches. If you want to discuss this stuff - fine. But it's not the specific bit = of the ocean I'm particularly interested in re-heating right now since a = large corpus of work has already gone into addressing this problem = space. What is an open issue is the one that originally brought Stewart to = saag: The MPLS protocols are in need of a transport security upgrade. = As part of that headache, we want to try to get boilerplate and process = in place so that the next time someone needs to either invent a new = protocol or upgrade an existing one, we stop making routing experts who = are security n00bs go through a dance they don't know the steps to. >=20 > "Ocean boiling" is part of the IETF's job description. We made the = ocean, and if it's the wrong temperature, it's our fault. >=20 > And it's not impossible. HTTPS usage has gone from <30% to >70% in = less than five years [1]. Even IPv6 is in the range of 20% now [2]. =20 Routers have their CPU power upgraded at significantly slower rates. In = general, cryptographic mechanisms eat CPU like a child eating candy = during a holiday. An impression often given by security folk is "just = use more/better crypto". =20 Those routers are doing better things with their limited CPU right now - = like running the Internet and supporting features that are revenue = impacting. Right now, better crypto is running well behind revenue = impacting features in terms of getting CPU time or forcing router CPU = upgrades. Vendors know how to implement and deploy the mechanisms that have been = crafted. But the crypto child needs to be put on a diet if you want = more of this stuff to be deployed. =20 Meanwhile, let's dig into the pieces we know need work and we need help = on. -- Jeff --Apple-Mail=_677D57AE-CF4C-4CA9-B5D3-A457646FFD4B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Richard,

On Apr 16, 2018, at 8:13 AM, = Richard Barnes <rlb@ipv.sx> wrote:
On Sun, Apr 15, 2018 at 3:27 PM, = Jeffrey Haas <jhaas@pfrc.org> wrote:
Right.  Please save this bit of = ocean boiling for elsewhere. Like over beer.

Part of the problem here is that the routing community seems = to regard these issues as separate. 

You're inferring a bit much, but I think we're both = speaking over-broadly.


Security analysis happens in the = context of a threat model -- what is the valuable thing you're = protecting, and what are you protecting it from?  If you want to = say you're talking about routing security, you need to either address = the whole spectrum of threats (not just, say, local threats due to = poorly protected transport), or have some plausible story for why = certain threats should be out of scope.  What Christian and I are = saying is that BGP manipulation is an active, major threat to the = Internet, so it seems odd to us to rule it out of scope.

In the specific case of BGP, a core and fundamental = property of it is that each router along the way is allowed to tinker = with the contents of a significant portion of the UPDATE message. =  The pieces of it that generate concern are:

- The fact that you can mis-originate reachability = that does not "belong" to you.  RPKI ROAs were crafted to address = this piece, along with the rpki-rtr protocol to transmit information to = a BGP speaker to perform validation of permitted = origination.
- The fact that you can intentionally = mis-represent the path an UPDATE traverses either accidentally as part = of normal prepending operations or maliciously in an attempt to cause = traffic to be misrouted. bgpsec was crafted to address this issue in = conjunction with the RPKI.
- The fact that even with these = mechanisms, it's possible to re-announce routes in violation of = expectations or contract in such a way that traffic is not per-se = hijacked but rather leaked in a way that violates expectations, contract = or even simple capacity. There's a body of work going on in grow and idr = under the umbrella of "route leaking" trying to address = this.
- The fact that some of these mechanisms do not cover = information contained in UPDATE messages that may have control impact on = routing; e.g. communities and other loop detection information such as = cluster-lists, etc.  This work was originally ruled out of scope in = SIDR for Internet use.

We're not = ignoring this.  The above works are the right pieces covering the = appropriate bit of ecosystem.  

RFC 4272 is likely due for a general = refresher.

BGP transport security is = a known issue and theoretically "done" - use TCP-AO.  See my = slides.  See also the fact that IPSec can be utilized as well, = albeit with known bootstrapping headaches.

If you want to discuss this stuff - fine. =  But it's not the specific bit of the ocean I'm particularly = interested in re-heating right now since a large corpus of work has = already gone into addressing this problem space.

What is an open issue is the one that originally = brought Stewart to saag: The MPLS protocols are in need of a transport = security upgrade.  As part of that headache, we want to try to get = boilerplate and process in place so that the next time someone needs to = either invent a new protocol or upgrade an existing one, we stop making = routing experts who are security n00bs go through a dance they don't = know the steps to.


"Ocean boiling" is part of the IETF's job = description.  We made the ocean, and if it's the wrong temperature, = it's our fault.

And it's not impossible.  HTTPS usage has = gone from <30% to >70% in less than five years [1].  Even = IPv6 is in the range of 20% now [2]. 

Routers have their CPU power upgraded at significantly = slower rates.  In general, cryptographic mechanisms eat CPU like a = child eating candy during a holiday.  An impression often given by = security folk is "just use more/better crypto".  

Those routers are doing better things with their = limited CPU right now - like running the Internet and supporting = features that are revenue impacting.  Right now, better crypto is = running well behind revenue impacting features in terms of getting CPU = time or forcing router CPU upgrades.

Vendors know how to implement and deploy the = mechanisms that have been crafted.  But the crypto child needs to = be put on a diet if you want more of this stuff to be deployed. =  

Meanwhile, let's dig into the = pieces we know need work and we need help on.

-- Jeff

= --Apple-Mail=_677D57AE-CF4C-4CA9-B5D3-A457646FFD4B-- From nobody Mon Apr 16 06:38:21 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C4412D880 for ; Mon, 16 Apr 2018 06:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ku3DoXLlSthY for ; Mon, 16 Apr 2018 06:38:17 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0206512D864 for ; Mon, 16 Apr 2018 06:38:16 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 451D3214CE; Mon, 16 Apr 2018 09:38:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 16 Apr 2018 09:38:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=5yvAi2 QTQfaIPAXkUH6dDKknhPxbV12gkypTAo2Pppk=; b=TvH0XG7A5S79BiYNh0ol9J a1C7gH7TNSh2kunBHTQq2Ty9yolUETEh226v/f8fDhA6/69LPMLtZE8waViQU61k /DQf/l+3qv3wIcwH1lYFepVA6my8OTqmA7ru4eSgmUCBMbjiIpwLD77aoV6C5YL9 DNOKbwS5Rmypb+Jo3icMgPRA9RpC5xZsZdRFsJ5hDEfBRHg8EocXuEAXZNbgvL6f xGQqzUB/+s25T+RAdd0ihEOhxgugOd3JgvxadT5uCWZh3TnUAm2FiU7/fDdizASm tuooOriuujJkoCIRw6K/CO9chV9gMNcX7njz5teSIiUtHUslK5p3HXw9b+CBGvQg == X-ME-Sender: Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net [162.229.180.77]) by mail.messagingengine.com (Postfix) with ESMTPA id C6CE5E46C2; Mon, 16 Apr 2018 09:38:15 -0400 (EDT) From: "Russ White" To: "'Jeffrey Haas'" , "'Richard Barnes'" Cc: "'Christian Huitema'" , "'Stewart Bryant'" , "'Acee Lindem \(acee\)'" , "'BRUNGARD, DEBORAH A'" , "'secdir'" References: <026301d3d4e4$380d8b00$a828a100$@riw.us> <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> <2AD240AE-DF39-4D76-8D6B-BB8AADC6C267@pfrc.org> In-Reply-To: <2AD240AE-DF39-4D76-8D6B-BB8AADC6C267@pfrc.org> Date: Mon, 16 Apr 2018 09:38:13 -0400 Message-ID: <024301d3d588$2b8ac6a0$82a053e0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIXNZBmczwARyMumKcTrqeA3r6qigBoV+JkAj23bD0BpoR9wQIJ7MVDAPbXNGkCu5yi3gFoqwE4oyEKrQA= Content-Language: en-us Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 13:38:19 -0000 > - The fact that you can intentionally mis-represent the path an UPDATE > traverses either accidentally as part of normal prepending operations = or > maliciously in an attempt to cause traffic to be misrouted. bgpsec was = crafted > to address this issue in conjunction with the RPKI. And this is where we get into trouble -- because, IMHO. BGPSEC, beyond = being undeployable, either fails to provide meaningful security and/or = makes the problem worse. This isn't just a crypto problem, this is a = structural problem with the solution itself. The IETF's focus on BGPSEC = as "the only right solution" has caused many in the community to stop = looking to the IETF for leadership in solving this problem. At least = some folks in the community are looking at other solutions to this = problem in a way that intentionally _avoids_ any sort of "deep" = interaction with the IETF because of the rut the IETF is in. Until the IETF starts listening to folks beyond BGPSEC supporters, and = rethinks what needs to be solved, the IETF will continue to play = essentially no role in moving any solution for this problem forward. = Hint: ensuring the "proper operation of BGP" is not a good starting = point.=20 > What is an open issue is the one that originally brought Stewart to > saag: The MPLS protocols are in need of a transport security upgrade. > As part of that headache, we want to try to get boilerplate and = process in > place so that the next time someone needs to either invent a new = protocol or > upgrade an existing one, we stop making routing experts who are = security > n00bs go through a dance they don't know the steps to. Correct -- this is the problem this design team is attempting to = address. It is not that routing folk don't think the BGP problem isn't a = problem, it is that the IETF is not a useful place for discussing this = problem. Perhaps it will be in the future, but right now there is no = hope of having a reasoned, reasonable, and productive discussion on this = topic. =F0=9F=98=8A Russ From nobody Mon Apr 16 06:54:45 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16121243F3 for ; Mon, 16 Apr 2018 06:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wde-Y4uytw-c for ; Mon, 16 Apr 2018 06:54:42 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E0612D88D for ; Mon, 16 Apr 2018 06:54:41 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id n65-v6so1350003oig.6 for ; Mon, 16 Apr 2018 06:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Eb9qCE2lzVjWfRF5lK30pmtLQeZGHrP4xWqmAE8Tf9Q=; b=IHomefpsU+uJ7U6hBM3rDrDhKk03Yt1OAGr1d0UzUfKfZWwvIzt8AIWaqOBMmX9eqS YeU+Clh+tA7k1yoB6sfSPiJMAgAzgsJwmjC7+M/pTndsmZcfZpMLHD0U8GtuXXyo18to PKMeCN1oIrtrwBSj6k0WNiy+bQ65WPymVJxnIjwJ8azfwSrmBDECXqqP92x0JYA/VVq3 moz+5qmV6651oEmAYM5HMCfaxYc8ezeFCVcAcSJEKf5WysVtYUFlT2c0z0T9v/cNyvLT siHPQUNhh111ufdm0GXAKF7lAMAwTGzCxH0lrzOdG0HBjZYe6NtpSuP7q22P8tAydI3n Ft3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Eb9qCE2lzVjWfRF5lK30pmtLQeZGHrP4xWqmAE8Tf9Q=; b=gzXmVi4T+hXA15NeeGsfe0hd/ZVKYPf1/fmPzP84gIuN1T36iBGldBJ5rhZlNzpjoS e1/LTbz0OTKA+y+PHEplHW0VUSyH5nN9hlkwkY0GwcZQ8CacZVXlBZWCKocJSfQkoiDz errLnjjw/EvQCvdqjM2xLjj/5FLztQ3OrDDBRX4KD79VYLtcN8GzMLAirsNCNFAySzBW cpt6X4nDTxvrzIwuaY81NgrhXOHcXmcndbfH1v6nGVMTcWFZkya9xfiEuA1ihn6Uk3p4 wM0eCDdz5CO5uYB0HtMlva+j+ikTr9Ybylt+JSfulK/Kas2zfNetyddlqeunfv9tGJeh efoQ== X-Gm-Message-State: ALQs6tAAVo3VGxqTRgnAa56zmrDORGjarP2vXS8WNOM2/GbOPLv1n61f 1tWuRoHKW1MO0sOwJ/QIRvGjN5L9rmMJA5haqUCdRQ== X-Google-Smtp-Source: AIpwx4+Vow06XsXBuG19t58Ma1tBZmpvLLAEjKLCxgzpLfll4ELGi3qEO2D6TtzKLFjq+YIfu4b7Qw0utZUmmupb+0s= X-Received: by 2002:aca:d08c:: with SMTP id j12-v6mr2773644oiy.276.1523886880955; Mon, 16 Apr 2018 06:54:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.90.67 with HTTP; Mon, 16 Apr 2018 06:54:40 -0700 (PDT) In-Reply-To: <024301d3d588$2b8ac6a0$82a053e0$@riw.us> References: <026301d3d4e4$380d8b00$a828a100$@riw.us> <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> <2AD240AE-DF39-4D76-8D6B-BB8AADC6C267@pfrc.org> <024301d3d588$2b8ac6a0$82a053e0$@riw.us> From: Richard Barnes Date: Mon, 16 Apr 2018 09:54:40 -0400 Message-ID: To: Russ White Cc: Jeffrey Haas , Christian Huitema , Stewart Bryant , "Acee Lindem (acee)" , "BRUNGARD, DEBORAH A" , secdir Content-Type: multipart/alternative; boundary="00000000000037b8060569f790b7" Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 13:54:44 -0000 --00000000000037b8060569f790b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2018 at 9:38 AM, Russ White wrote: > > > - The fact that you can intentionally mis-represent the path an UPDATE > > traverses either accidentally as part of normal prepending operations o= r > > maliciously in an attempt to cause traffic to be misrouted. bgpsec was > crafted > > to address this issue in conjunction with the RPKI. > > And this is where we get into trouble -- because, IMHO. BGPSEC, beyond > being undeployable, either fails to provide meaningful security and/or > makes the problem worse. This isn't just a crypto problem, this is a > structural problem with the solution itself. The IETF's focus on BGPSEC a= s > "the only right solution" has caused many in the community to stop lookin= g > to the IETF for leadership in solving this problem. At least some folks i= n > the community are looking at other solutions to this problem in a way tha= t > intentionally _avoids_ any sort of "deep" interaction with the IETF becau= se > of the rut the IETF is in. > > Until the IETF starts listening to folks beyond BGPSEC supporters, and > rethinks what needs to be solved, the IETF will continue to play > essentially no role in moving any solution for this problem forward. Hint= : > ensuring the "proper operation of BGP" is not a good starting point. > I'm fully willing to admit that there has been some intransigence on the security side of things. And I'm not trying to argue for BGPSEC in particular, but for solving the problem. However, the messages in this thread make me think there's not really a willingness in the routing community to engage seriously in the problem either. Security mechanisms exist to enforce invariants, so if you're not willing to concede that BGP should adhere to some invariants (which is how Jeffrey's bullet points read to me), then you're never going to be able to meaningfully secure the protocol, and we should publish an RFC that says "here's the security properties you can expect of BGP lolz #YOLO CAVEAT ROUTOR" -- like RFC 4272, but more honest. > > What is an open issue is the one that originally brought Stewart to > > saag: The MPLS protocols are in need of a transport security upgrade. > > As part of that headache, we want to try to get boilerplate and process > in > > place so that the next time someone needs to either invent a new > protocol or > > upgrade an existing one, we stop making routing experts who are securit= y > > n00bs go through a dance they don't know the steps to. > > Correct -- this is the problem this design team is attempting to address. > It is not that routing folk don't think the BGP problem isn't a problem, = it > is that the IETF is not a useful place for discussing this problem. Perha= ps > it will be in the future, but right now there is no hope of having a > reasoned, reasonable, and productive discussion on this topic. > > =F0=9F=98=8A > So maybe this group needs a more focused title :) Because as this thread demonstrates, when you say "Routing Area Security", people are going to think you're going to solve actual problems with the security of routing, not just better transport security -- which really has nothing to do with routing, it's just securing the routing protocol as an application. How about "Better Routing Application Transport Security (BRATS)"? ;) --Richard --00000000000037b8060569f790b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 16, 2018 at 9:38 AM, Russ White <russ@riw.us> wrot= e:

> - The fact that you can intentionally mis-represent the path an UPDATE=
> traverses either accidentally as part of normal prepending operations = or
> maliciously in an attempt to cause traffic to be misrouted. bgpsec was= crafted
> to address this issue in conjunction with the RPKI.

And this is where we get into trouble -- because, IMHO. BGPSEC, beyo= nd being undeployable, either fails to provide meaningful security and/or m= akes the problem worse. This isn't just a crypto problem, this is a str= uctural problem with the solution itself. The IETF's focus on BGPSEC as= "the only right solution" has caused many in the community to st= op looking to the IETF for leadership in solving this problem. At least som= e folks in the community are looking at other solutions to this problem in = a way that intentionally _avoids_ any sort of "deep" interaction = with the IETF because of the rut the IETF is in.

Until the IETF starts listening to folks beyond BGPSEC supporters, and reth= inks what needs to be solved, the IETF will continue to play essentially no= role in moving any solution for this problem forward. Hint: ensuring the &= quot;proper operation of BGP" is not a good starting point.

I'm fully willing to= admit that there has been some intransigence on the security side of thing= s.=C2=A0 And I'm not trying to argue for BGPSEC in particular, but for = solving the problem.

However, the messages in = this thread make me think there's not really a willingness in the routi= ng community to engage seriously in the problem either.=C2=A0 Security mech= anisms exist to enforce invariants, so if you're not willing to concede= that BGP should adhere to some invariants (which is how Jeffrey's bull= et points read to me), then you're never going to be able to meaningful= ly secure the protocol, and we should publish an RFC that says "here&#= 39;s the security properties you can expect of BGP lolz #YOLO CAVEAT ROUTOR= " -- like RFC 4272, but more honest.

=C2= =A0
> What is an open issue is the one that originally brought Stewart to > saag: The MPLS protocols are in need of a transport security upgrade.<= br> > As part of that headache, we want to try to get boilerplate and proces= s in
> place so that the next time someone needs to either invent a new proto= col or
> upgrade an existing one, we stop making routing experts who are securi= ty
> n00bs go through a dance they don't know the steps to.

Correct -- this is the problem this design team is attempting to add= ress. It is not that routing folk don't think the BGP problem isn't= a problem, it is that the IETF is not a useful place for discussing this p= roblem. Perhaps it will be in the future, but right now there is no hope of= having a reasoned, reasonable, and productive discussion on this topic.
=F0=9F=98=8A

So maybe this group needs = a more focused title :)=C2=A0 Because as this thread demonstrates, when you= say "Routing Area Security", people are going to think you'r= e going to solve actual problems with the security of routing, not just bet= ter transport security -- which really has nothing to do with routing, it&#= 39;s just securing the routing protocol as an application.
How about "Better Routing Application Transport Security = (BRATS)"?=C2=A0 ;)

--Richard
--00000000000037b8060569f790b7-- From nobody Mon Apr 16 07:28:49 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3761A12D96D for ; Mon, 16 Apr 2018 07:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UECBvC124kk6 for ; Mon, 16 Apr 2018 07:28:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1481200C5 for ; Mon, 16 Apr 2018 07:28:46 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id A85DA1E401; Mon, 16 Apr 2018 10:29:38 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_56DEB518-9E95-4595-AFDC-11C7ADD4E5EE" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: Date: Mon, 16 Apr 2018 10:28:44 -0400 Cc: Russ White , Christian Huitema , Stewart Bryant , "Acee Lindem (acee)" , "BRUNGARD, DEBORAH A" , secdir Message-Id: <0B9DB69A-472E-4FF5-9164-FCFB59C26D64@pfrc.org> References: <026301d3d4e4$380d8b00$a828a100$@riw.us> <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> <2AD240AE-DF39-4D76-8D6B-BB8AADC6C267@pfrc.org> <024301d3d588$2b8ac6a0$82a053e0$@riw.us> To: Richard Barnes X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 14:28:48 -0000 --Apple-Mail=_56DEB518-9E95-4595-AFDC-11C7ADD4E5EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 16, 2018, at 9:54 AM, Richard Barnes wrote: > On Mon, Apr 16, 2018 at 9:38 AM, Russ White > wrote: > Until the IETF starts listening to folks beyond BGPSEC supporters, and = rethinks what needs to be solved, the IETF will continue to play = essentially no role in moving any solution for this problem forward. = Hint: ensuring the "proper operation of BGP" is not a good starting = point.=20 >=20 > I'm fully willing to admit that there has been some intransigence on = the security side of things. And I'm not trying to argue for BGPSEC in = particular, but for solving the problem. >=20 > However, the messages in this thread make me think there's not really = a willingness in the routing community to engage seriously in the = problem either. What I believe you're seeing is at least two veterans of the bgp = security war saying they've done enough bleeding on that specific topic = for a little while.=20 > Security mechanisms exist to enforce invariants, so if you're not = willing to concede that BGP should adhere to some invariants (which is = how Jeffrey's bullet points read to me), then you're never going to be = able to meaningfully secure the protocol, and we should publish an RFC = that says "here's the security properties you can expect of BGP lolz = #YOLO CAVEAT ROUTOR" -- like RFC 4272, but more honest. More emphasized below. However, we didn't approach this as "let's = secure BGP". Matter of fact, BGP wasn't even what we were here to talk = about. Yet that's all this thread has devolved to. > So maybe this group needs a more focused title :) My opening message was "this group is mis-chartered". :-) > Because as this thread demonstrates, when you say "Routing Area = Security", people are going to think you're going to solve actual = problems with the security of routing, not just better transport = security -- which really has nothing to do with routing, it's just = securing the routing protocol as an application. Bingo. If you want more ocean boiling, let's do that later on. For now, we = have narrower work we'd like to focus on. We believe it'll have value = to the overall IETF community and should make part of the security = review of RFC targeted documents easier. > How about "Better Routing Application Transport Security (BRATS)"? ;) Only if we get our own line of dolls. -- Jeff --Apple-Mail=_56DEB518-9E95-4595-AFDC-11C7ADD4E5EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Apr 16, 2018, at 9:54 AM, Richard Barnes <rlb@ipv.sx> = wrote:
On Mon, Apr 16, = 2018 at 9:38 AM, Russ White <russ@riw.us> wrote:
Until the IETF starts listening to folks beyond = BGPSEC supporters, and rethinks what needs to be solved, the IETF will = continue to play essentially no role in moving any solution for this = problem forward. Hint: ensuring the "proper operation of BGP" is not a = good starting point.

I'm fully willing to admit that there has been some = intransigence on the security side of things.  And I'm not trying = to argue for BGPSEC in particular, but for solving the problem.

However, the messages in this thread make me think there's = not really a willingness in the routing community to engage seriously in = the problem either.

What I believe you're seeing is at least two veterans = of the bgp security war saying they've done enough bleeding on that = specific topic for a little while. 

  Security mechanisms exist = to enforce invariants, so if you're not willing to concede that BGP = should adhere to some invariants (which is how Jeffrey's bullet points = read to me), then you're never going to be able to meaningfully secure = the protocol, and we should publish an RFC that says "here's the = security properties you can expect of BGP lolz #YOLO CAVEAT ROUTOR" -- = like RFC 4272, but more honest.

More emphasized below.  However, we didn't = approach this as "let's secure BGP".  Matter of fact, BGP wasn't = even what we were here to talk about.  Yet that's all this thread = has devolved to.

So = maybe this group needs a more focused title = :)

My = opening message was "this group is mis-chartered". :-)

  Because as this thread = demonstrates, when you say "Routing Area Security", people are going to = think you're going to solve actual problems with the security of = routing, not just better transport security -- which really has nothing = to do with routing, it's just securing the routing protocol as an = application.

Bingo.

If you want = more ocean boiling, let's do that later on.  For now, we have = narrower work we'd like to focus on.  We believe it'll have value = to the overall IETF community and should make part of the security = review of RFC targeted documents easier.

How about "Better Routing = Application Transport Security (BRATS)"?  ;)

Only if we get our own line of dolls.

-- Jeff

= --Apple-Mail=_56DEB518-9E95-4595-AFDC-11C7ADD4E5EE-- From nobody Mon Apr 16 17:53:35 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB4D12E869; Mon, 16 Apr 2018 17:53:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema To: Cc: stir@ietf.org, draft-ietf-stir-rph.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152392641446.26140.16049118175653349746@ietfa.amsl.com> Date: Mon, 16 Apr 2018 17:53:34 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-stir-rph-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 00:53:34 -0000 Reviewer: Christian Huitema Review result: Has Nits Summary: ready with nits. The STIR specifications (RFC 8224, RFC 8225) define a mechanism in which the "Identity" in a SIP header points to an URI used to retrieve the JSON-encoded claims related to that identity. The claims can be verifed by cryptographic mechanisms, allowing in principle called parties to make informed decisions before accepting a call. The draft extends the syntax of the JSON tokens to make claims about the "resource priority" levels that can be used in the call. The goal appears to be better management of resource in SIP gateways, e.g., chosing which of many incoming calls would get access to a scarce resource. Or in any case that's what I understood after reading the draft. It would be helpful if the introduction explained the problem that the extension is solving, maybe with a reference to the problem statement in RFC 7340 or the threat model in RFC 7375. The third paragraph of the introduction could be rearranged. As written, it mentions an extension defined in RFC 7340, which had me puzzled for a time, as that RFC is a problem statement and a list of requirements. As far as I can tell, the extension uses the mechanisms for "Extending PASSport" defined in section 8 or RFC 8825. Why not say that, instead of a vague assertion that "The STIR architecture allows extensions". Or, define what you actually mean by the STIR Architecture, arguably the combination of RFC 8824 and RFC 8825. Looking at security issue, it appears that the proposal reuses for resource priority the mechanisms defined by RFC 8824 for generally verifying claims. That seems reasonable. My main concern is with the levels of indirection. The security mechanisms will verify that a claim is authentic by verifying that it is properly authorized by the specified authority. But at that point, the gateway will have to verify that the authority behind the claim is actually authorized to consume the resource as specified in the resource priority header. This is potentially more complex than verifying an identity claim. Section 7.2. of the security consideration explains that, but I am curious to see whether that will work in practice. Please update the references. [I-D.ietf-stir-rfc4474bis] has been replaced by RFC 8224. [I-D.ietf-stir-passport] has been replaced by RFC 8225. From nobody Wed Apr 18 07:00:38 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF11612D80E; Wed, 18 Apr 2018 07:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozOk1-EKu1lA; Wed, 18 Apr 2018 07:00:26 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20521241FC; Wed, 18 Apr 2018 07:00:24 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id d1-v6so5134764wrj.13; Wed, 18 Apr 2018 07:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eRALVOGDD7Nh/ypF8YBe4wT8tT+L3uk8I3O9MJnWrG8=; b=G2xek1jeGa0Lr4pSjiv7VE1i3GXblhgCQIS/OK13cW9A14720kpOo/TDfoKKt7IJ1c DrgOBwoHVROgqowQof/rXc+AKK21AHkC3XB52KPkxfcch9WAn4B7WieEq/8JzkPz4Ocr 0WWOVH02qjRbJGF44vIVWSkhZhtgFcigsCPkvibnBa8nH6t2VMBxOBwIeOo/QguZv4nP 2HI6YC6hfkr6nDMVL3cJLCBMpgZyexYXtCMpG9DsDm9iEB9Wa9OdF/+3Rw3GDXBfIGmm RUH45tEaso3Ahxp8uT/k2rjeJ7WWpRi6lUHcuGW2fAbsxsuGI4QJfQ41sNn4dMT/pmxd C1cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eRALVOGDD7Nh/ypF8YBe4wT8tT+L3uk8I3O9MJnWrG8=; b=iF4LCKAIhcQDKCxWXp/jQg3S4JEAu/jzPAPHS/PbbMDSHCKoVxyG03p2c0li15ntVy f2jKQqzrK34FZois1KZo0Rf2Y3dVlISa8W+iOJpyAOLGXWTGNPaOP8Qm1FT0j9+LLneF /1ch5FjLnh5l0zE6EASERC5GavBIlJzAvCnSIrfohDLX7tO4BF0k1BMc0b23w53XT9EN J0omuWDno2sZWkE7R/6RshSqvJh73qUo2KMOg8Gk8D13rdvaSxh7PIVkIaqXxIo3UiP6 E5vHXhuQHXtfn6/QvoJI1obaYOL0+C9rihNpDjy1mdKxL7Ffi7NjUFhJVP4+5IXiky62 c6eA== X-Gm-Message-State: ALQs6tDkU6Bno9qAE9xnQ3+KAYvvVnmJ0LeviYmlHMjaONyeXK1OOyPi rU0qfw/e/d2Yx0T7cKeSCxN4cxq5faGKeO15tpUX7Q== X-Google-Smtp-Source: AIpwx4+X38TPToVkuyoBpzLPY8rHzj+QxGacmjozAx6CKzT/nLYDvGJatFivqOLkLpnwRMo1dpSxD/TYcJf4KPX52K8= X-Received: by 10.28.208.202 with SMTP id h193mr1505527wmg.6.1524060023250; Wed, 18 Apr 2018 07:00:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.69.25 with HTTP; Wed, 18 Apr 2018 07:00:21 -0700 (PDT) In-Reply-To: <152392641446.26140.16049118175653349746@ietfa.amsl.com> References: <152392641446.26140.16049118175653349746@ietfa.amsl.com> From: Subir Das Date: Wed, 18 Apr 2018 10:00:21 -0400 Message-ID: To: Christian Huitema Cc: secdir@ietf.org, IETF STIR Mail List , draft-ietf-stir-rph.all@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1940fa4d680f056a1fe041" Archived-At: Subject: Re: [secdir] [stir] Secdir telechat review of draft-ietf-stir-rph-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 14:00:30 -0000 --94eb2c1940fa4d680f056a1fe041 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Christian, Thanks for your review and comments. Please see the answers inline. Regards, _Subir -----Original Message----- From: Christian Huitema Sent: Monday, April 16, 2018 8:54 PM To: secdir@ietf.org Cc: stir@ietf.org; draft-ietf-stir-rph.all@ietf.org; ietf@ietf.org Subject: Secdir telechat review of draft-ietf-stir-rph-03 Reviewer: Christian Huitema Review result: Has Nits Summary: ready with nits. The STIR specifications (RFC 8224, RFC 8225) define a mechanism in which the "Identity" in a SIP header points to an URI used to retrieve the JSON-encoded claims related to that identity. The claims can be verifed by cryptographic mechanisms, allowing in principle called parties to make informed decisions before accepting a call. The draft extends the syntax of the JSON tokens to make claims about the "resource priority" levels that can be used in the call. The goal appears to be better management of resource in SIP gateways, e.g., chosing which of many incoming calls would get access to a scarce resource. Or in any case that's what I understood after reading the draft. It would be helpful if the introduction explained the problem that the extension is solving, maybe with a reference to the problem statement in RFC 7340 or the threat model in RFC 7375. SD> The first two paragraphs of the Introduction will be updated as follows: =E2=80=9C PASSporT [RFC8225] is a token format based on JSON Web Token (JWT= ) [RFC7519] for conveying cryptographically signed information about the identities involved in personal communications; it is used with STIR [RFC8224] to convey a signed assertion of the identity of the participants in real-time communications established via a protocol like SIP [RFC3261]. This specification extends PASSporT to allow cryptographic-signing of the SIP =E2=80=99Resource-Priority=E2=80=99 header field [RFC4412], which is us= ed for communications resource prioritization. [RFC4412] defines the SIP =E2=80=99Resource-Priority=E2=80=99 header field = for communications resource priority. As specified in [RFC4412], the =E2=80=99Resource-Priority=E2=80=99 header field may be used by SIP user ag= ents [RFC3261], including Public Switched Telephone Network (PSTN) gateways and terminals, and by SIP proxy servers, to influence prioritization afforded to communication sessions, including PSTN Calls (e.g., to manage scarce network resources during network congestion scenarios). However, the SIP =E2=80=99Resource-Priority=E2=80=99 header field could be spoofed and abuse= d by unauthorized entities, the threat models and use cases of which are described in RFC 7375 and RFC 7340, respectively. Compromise of the SIP =E2=80=98Resource-Priority=E2=80=99 header field [RFC 4412] could lead to m= isuse of network resource (i.e., during congestion scenarios) resulting in impacts to the application services supported using the =E2=80=99Resource-Priority=E2=80= =99 header field." The third paragraph of the introduction could be rearranged. As written, it mentions an extension defined in RFC 7340, which had me puzzled for a time, as that RFC is a problem statement and a list of requirements. As far as I can tell, the extension uses the mechanisms for "Extending PASSport" defined in section 8 or RFC 8825. Why not say that, instead of a vague assertion that "The STIR architecture allows extensions". Or, define what you actually mean by the STIR Architecture, arguably the combination of RFC 8824 and RFC 8825. SD> Will update the paragraph as follows: "The RFC 8225 provides a mechanism by which an authority on the originating side of a call can provide a cryptographic assurance of the validity of the calling party telephone number in order to prevent impersonation attacks. RFC 8225 also allows extensions that can be utilized by authorities supporting real-time communication services using the =E2=80=99Resource-Pri= ority=E2=80=99 header field to cryptographically sign the SIP =E2=80=99Resource-Priority=E2=80=99 header f= ield and convey assertion of the authorization for =E2=80=99Resource-Priority=E2=80=99. For= example, the authority on the originating side verifying the authorization of a particular communication for =E2=80=99Resource-Priority= =E2=80=99 can use a PASSPorT claim to cryptographically sign the SIP =E2=80=99Resource Priori= ty=E2=80=99 header field and convey an assertion of the authorization for =E2=80=99Resource-Priority=E2=80=99. This will allow a receiving entity (in= cluding entities located in different network domains/boundaries) to verify the validity of assertions authorizing =E2=80=99Resource-Priority=E2=80=99. Cryptographical= ly signed SIP =E2=80=99Resource-Priority=E2=80=99 header fields will allow a receiving en= tity to verify and act on the information with confidence that the information has not been spoofed or compromised. " Looking at security issue, it appears that the proposal reuses for resource priority the mechanisms defined by RFC 8824 for generally verifying claims. That seems reasonable. My main concern is with the levels of indirection. The security mechanisms will verify that a claim is authentic by verifying that it is properly authorized by the specified authority. But at that point, the gateway will have to verify that the authority behind the claim is actually authorized to consume the resource as specified in the resource priority header. This is potentially more complex than verifying an identity claim. Section 7.2. of the security consideration explains that, but I am curious to see whether that will work in practice. SD> Yes, the security mechanism will only verify that a claim is authentic and is properly authorized by the specified authority. To allocate the gateway resource and for other service specific authorization, providers will have specific priority treatment policies. This is specified in other organizations (e.g., ATIS) who is currently the consumer of this STIR extension (specifically to support Emergency Telecommunication Service). In this draft, we do mention that this is outside the scope of this document. Please update the references. [I-D.ietf-stir-rfc4474bis] has been replaced by RFC 8224. [I-D.ietf-stir-passport] has been replaced by RFC 8225. SD> Will update. On Mon, Apr 16, 2018 at 8:53 PM, Christian Huitema wrote: > Reviewer: Christian Huitema > Review result: Has Nits > > Summary: ready with nits. > > The STIR specifications (RFC 8224, RFC 8225) define a mechanism in which > the "Identity" in a > SIP header points to an URI used to retrieve the JSON-encoded claims > related to that identity. The > claims can be verifed by cryptographic mechanisms, allowing in principle > called parties to make > informed decisions before accepting a call. The draft extends the syntax > of the JSON tokens to > make claims about the "resource priority" levels that can be used in the > call. The goal appears > to be better management of resource in SIP gateways, e.g., chosing which > of many incoming > calls would get access to a scarce resource. > > Or in any case that's what I understood after reading the draft. It would > be helpful if the > introduction explained the problem that the extension is solving, maybe > with a reference to > the problem statement in RFC 7340 or the threat model in RFC 7375. > > The third paragraph of the introduction could be rearranged. As written, > it mentions an extension defined in RFC 7340, which had me puzzled for a > time, as that RFC is a > problem statement and a list of requirements. As far as I can tell, the > extension > uses the mechanisms for "Extending PASSport" defined in section 8 or RFC > 8825. Why not > say that, instead of a vague assertion that "The STIR architecture allows > extensions". Or, > define what you actually mean by the STIR Architecture, arguably the > combination of > RFC 8824 and RFC 8825. > > Looking at security issue, it appears that the proposal reuses for > resource priority the > mechanisms defined by RFC 8824 for generally verifying claims. That seems > reasonable. My > main concern is with the levels of indirection. The security mechanisms > will verify that > a claim is authentic by verifying that it is properly authorized by the > specified > authority. But at that point, the gateway will have to verify that the > authority > behind the claim is actually authorized to consume the resource as > specified in > the resource priority header. This is potentially more complex than > verifying an > identity claim. Section 7.2. of the security consideration explains that, > but I am curious to see whether that will work in practice. > > Please update the references. [I-D.ietf-stir-rfc4474bis] has been replace= d > by RFC 8224. > [I-D.ietf-stir-passport] has been replaced by RFC 8225. > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --94eb2c1940fa4d680f056a1fe041 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello Christian,

Thanks for your review and= comments. Please see the answers inline.

=C2=A0

Regards,

_Subir

=C2=A0

= -----Original Message-----
From: Christian Huitema <huitema@huitema.net>
Sent: Monday, April 16, 2018 8:54 PM
To: secdir@ietf.org
Cc: stir@ietf.org; draft-ietf-stir-rph.all@ietf.org; ietf@ietf.org
Subject: Secdir telechat review of draft-ietf-stir-rph-03<= /p>

=C2=A0<= /span>

Reviewer: Christian Huitema

Review result: Has Nits

=C2=A0<= /span>

Summary: ready with nits.

=C2=A0<= /span>

The STIR specifications (RFC 8224, RFC 8225) define a mechanism in which the "Identity" in a SIP header points to an URI used to retrieve the JSON-encoded claims related to that identity. The claims can be verifed by cryptographic mechanisms, allowing in principle called parties to make info= rmed decisions before accepting a call. The draft extends the syntax of the JSON tokens to make claims about the "resource priority" levels that c= an be used in the call. The goal appears to be better management of resource i= n SIP gateways, e.g., chosing which of many incoming calls would get access t= o a scarce resource.

=C2=A0<= /span>

Or in any case that's what I understood after reading the draft. It would be helpful i= f the introduction explained the problem that the extension is solving, maybe wit= h a reference to the problem statement in RFC 7340 or the threat model in RFC 7= 375.

=C2=A0

SD> The first two paragraphs of the Introduction will be updated as follows:

=C2=A0

=E2=80=9C PASSporT [RFC8225] is a token format based on JSON Web Token (JWT) [RFC7519] for conveying cryptographically signed information ab= out the identities involved in personal communications; it is used with STIR [RFC82= 24] to convey a signed assertion of the identity of the participants in real-ti= me communications established via a protocol like SIP [RFC3261]. This specification extends PASSporT to allow cryptographic-signing of the SIP =E2=80=99Resource-Priority=E2=80=99 header field [RFC4412], which is used f= or communications resource prioritization.

=C2=A0

[RFC4412] defines the SIP =E2=80=99Resource-Priority=E2=80=99 heade= r field for communications=C2=A0 resource priority. As specified in [RFC4412], the =E2=80=99Resource-Priority=E2=80=99 header field may be used by SIP user ag= ents [RFC3261], including Public Switched Telephone Network (PSTN) gateways and terminals, = and by SIP proxy servers, to influence prioritization afforded to communication sessions, including PSTN Calls (e.g., to manage scarce network resources du= ring network congestion scenarios). However, the SIP =E2=80=99Resource-Priority= =E2=80=99 header field could be spoofed and abused by unauthorized entities, the threat mode= ls and use cases of which are described in RFC=C2=A0 7375 and RFC 7340, respectively. Compromise of the SIP =E2=80=98Resource-Priority=E2=80=99 header field [RFC 4412] could lead to m= isuse of network resource (i.e., during congestion scenarios) resulting in impacts to the application services supported using the=C2=A0 =E2=80=99Resource-Priority=E2=80=99 header field."=

=C2=A0<= /span>

The third paragraph of the introduction could be rearranged. As written, it mentions = an extension defined in RFC 7340, which had me puzzled for a time, as that RFC= is a problem statement and a list of requirements. As far as I can tell, the extension uses the mechanisms for "Extending PASSport" defined in section 8 or RFC 8825. Why not say that, instead of a vague assertion that "The STIR architecture allows extensions". Or, define what you actually mean by the STIR Architecture, arguably the combination of RFC 882= 4 and RFC 8825.

=C2=A0

SD> Will update the paragraph as follows:

=C2=A0

"The RFC 8225 provides a mechanism by which an authority on the originating side of a call can provide a cryptographic assurance of the validity of the calling party telephone number in order to prevent impers= onation attacks. RFC 8225 also=C2=A0 allows extensions that ca= n be utilized by authorities supporting real-time communication services using the =E2=80=99Resource-Priority=E2=80=99 header field to

cryptographically sign the SIP =E2=80=99Resource-Priority=E2=80= =99 header field and convey assertion of the authorization for =E2=80=99Resource-Prior= ity=E2=80=99. For example, the authority on the originating side verifying the

authorization of a particular communication for =E2=80=99Resource-Priority=E2=80=99 can use a PASSPorT claim to cryptograph= ically sign the SIP =E2=80=99Resource Priority=E2=80=99 header field and convey an assertion of= the authorization for =E2=80=99Resource-Priority=E2=80=99. This will allow a receiving entity= (including entities located in different network domains/boundaries) to verify the validity of assertions authorizing =E2=80=99Resource-Priority=E2=80=99. Cryptographically signed SIP = =E2=80=99Resource-Priority=E2=80=99 header fields will allow a receiving entity to verify and act on the information w= ith confidence that the information has not been spoofed or compromised. "=

=C2=A0

Looking at security issue, it appears that the proposal reuses for resource priority t= he mechanisms defined by RFC 8824 for generally verifying claims. That seems reasonable. My main concern is with the levels of indirection. The security mechanisms will verify that a claim is authentic by verifying that it is properly authorized by the specified authority. But at that point, the gate= way will have to verify that the authority behind the claim is actually authori= zed to consume the resource as specified in the resource priority header. This = is potentially more complex than verifying an identity claim. Section 7.2. of = the security consideration explains that, but I am curious to see whether that = will work in practice.

=C2=A0

SD> =C2=A0Yes, the security mechanism will only verify that a claim is authentic and is proper= ly authorized by the specified authority.=C2=A0 To allocate the gateway resource and for other service specific authorization, providers will have specific priority treatment policies. Th= is is specified in other organizations (e.g., ATIS) who is currently the consu= mer of this STIR extension (specifically to support Emergency Telecommunication Service). In this draft, we do mention that this is outside the scope of th= is document.

=C2=A0<= /span>

Please update the references. [I-D.ietf-stir-rfc4474bis] has been replaced by RFC 8224.

[I-D.ietf-stir-passp= ort] has been replaced by RFC 8225.

=C2=A0

SD> Will update.



On Mon,= Apr 16, 2018 at 8:53 PM, Christian Huitema <huitema@huitema.net&g= t; wrote:
Reviewer: Christian Huit= ema
Review result: Has Nits

Summary: ready with nits.

The STIR specifications (RFC 8224, RFC 8225) define a mechanism in which th= e "Identity" in a
SIP header points to an URI used to retrieve the JSON-encoded claims relate= d to that identity. The
claims can be verifed by cryptographic mechanisms, allowing in principle ca= lled parties to make
informed decisions before accepting a call. The draft extends the syntax of= the JSON tokens to
make claims about the "resource priority" levels that can be used= in the call. The goal appears
to be better management of resource in SIP gateways, e.g., chosing which of= many incoming
calls would get access to a scarce resource.

Or in any case that's what I understood after reading the draft. It wou= ld be helpful if the
introduction explained the problem that the extension is solving, maybe wit= h a reference to
the problem statement in RFC 7340 or the threat model in RFC 7375.

The third paragraph of the introduction could be rearranged. As written, it mentions an extension defined in RFC 7340, which had me puzzled for a ti= me, as that RFC is a
problem statement and a list of requirements. As far as I can tell, the ext= ension
uses the mechanisms for "Extending PASSport" defined in section 8= or RFC 8825. Why not
say that, instead of a vague assertion that "The STIR architecture all= ows extensions". Or,
define what you actually mean by the STIR Architecture, arguably the combin= ation of
RFC 8824 and RFC 8825.

Looking at security issue, it appears that the proposal reuses for resource= priority the
mechanisms defined by RFC 8824 for generally verifying claims. That seems r= easonable. My
main concern is with the levels of indirection. The security mechanisms wil= l verify that
a claim is authentic by verifying that it is properly authorized by the spe= cified
authority. But at that point, the gateway will have to verify that the auth= ority
behind the claim is actually authorized to consume the resource as specifie= d in
the resource priority header. This is potentially more complex than verifyi= ng an
identity claim. Section 7.2. of the security consideration explains that, but I am curious to see whether that will work in practice.

Please update the references. [I-D.ietf-stir-rfc4474bis] has been replaced = by RFC 8224.
[I-D.ietf-stir-passport] has been replaced by RFC 8225.

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

--94eb2c1940fa4d680f056a1fe041-- From nobody Wed Apr 18 10:48:24 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE5712778E for ; Wed, 18 Apr 2018 10:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r63CcDDXX0hE for ; Wed, 18 Apr 2018 10:48:21 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD2D12778D for ; Wed, 18 Apr 2018 10:48:21 -0700 (PDT) Received: from [10.32.60.122] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w3IHlb80011587 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 18 Apr 2018 10:47:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.122] From: "Paul Hoffman" To: secdir Date: Wed, 18 Apr 2018 10:48:19 -0700 X-Mailer: MailMate (1.11.1r5471) Message-ID: <7B59F727-7979-40C4-8C60-F501D25AA621@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: [secdir] SecDir review of draft-ietf-uta-mta-sts X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 17:48:23 -0000 This document is an ambitious attempt to add STS (strict transport security) to SMTP. It carefully deals with all the traps and pitfalls that were found in developing STS for HTTP, DANE, and so on. I believe that it has hit all the obvious security issues how a determined attacker might cause a downgrade; in so doing, it has become a very complex protocol. However, the authors make a good argument for each of the complexities, which is admirable. --Paul Hoffman From nobody Thu Apr 19 04:18:31 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C5512D868; Thu, 19 Apr 2018 01:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524127050; bh=cDYujGAw9coumD+2peFhC+9hMe0OSjgXx+tjzA/lAhE=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=rNytZp0e5KPmXa2RUYPx+YlvaLnG9LOtYMnnd7FmH0F8Iqw0mkDOnd42k3JdVZPN+ gOnWrgeW8e2B2bGJZqnRKCE4n48+qPtMeN4WYaw2tufkctAl0pUv8kTlHRtFO6LOkX MTL4JQogA6bGqV6XxDMDKoDQrngiED1aGnjCm/jQ= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Apr 19 01:37:30 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F5612D7ED; Thu, 19 Apr 2018 01:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524127050; bh=cDYujGAw9coumD+2peFhC+9hMe0OSjgXx+tjzA/lAhE=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=rNytZp0e5KPmXa2RUYPx+YlvaLnG9LOtYMnnd7FmH0F8Iqw0mkDOnd42k3JdVZPN+ gOnWrgeW8e2B2bGJZqnRKCE4n48+qPtMeN4WYaw2tufkctAl0pUv8kTlHRtFO6LOkX MTL4JQogA6bGqV6XxDMDKoDQrngiED1aGnjCm/jQ= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD8D126CC4 for ; Thu, 19 Apr 2018 01:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.059 X-Spam-Level: X-Spam-Status: No, score=-3.059 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL=0.141, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfQ3KkPCDtj8 for ; Thu, 19 Apr 2018 01:37:26 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6B8126CBF for ; Thu, 19 Apr 2018 01:37:26 -0700 (PDT) Received: from [112.102.118.76] (helo=XueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1f954C-0001H1-Jx for new-work@ietf.org; Thu, 19 Apr 2018 08:37:21 +0000 To: new-work@ietf.org From: Xueyuan Message-ID: Date: Thu, 19 Apr 2018 16:37:15 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 19 Apr 2018 04:18:30 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Timed Text Working Group (until 2018-05-17) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 08:37:32 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBUaW1lZCBU ZXh0IFdvcmtpbmcgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcvMjAxOC8wNC9wcm9wb3Nl ZC10dC1jaGFydGVyLTIwMTguaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0IHRoZSBjb21t dW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJhZnQgY2hhcnRl ciBpcyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3IHBlcmlvZC4K ClczQyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDIwMTgtMDUtMTcgb24gdGhlCnBy b3Bvc2VkIGNoYXJ0ZXIuIFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvCnB1YmxpYy1uZXctd29ya0B3 My5vcmcsIHdoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cDovL2xpc3RzLnczLm9y Zy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBjb21tZW50cyBz ZW50IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRlZSBSZXByZXNl bnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29tbWVudHMuIElm IHlvdSB3b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0ZQp5b3VyIGNv bW1lbnRzIHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUuIEZvcgpl eGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlhIHRoaXMgbGlz dCBhbmQKaGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZSByZWZlciB0 byBpdCBmcm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KCklmIHlvdSBzaG91 bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNl CmNvbnRhY3QgVGhpZXJyeSBNaWNoZWwsIFRpbWVkIFRleHQgV0cgVGVhbSBDb250YWN0IDx0bWlj aGVsQHczLm9yZz4uCgpUaGFuayB5b3UsCgpYdWV5dWFuIEppYSwgVzNDIE1hcmtldGluZyAmIENv bW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5vcmcvQ29uc29ydGl1bS9NZW1iZXIvTGlz dAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdv cmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Thu Apr 19 07:33:27 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A3612DA4B; Thu, 19 Apr 2018 07:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524148294; bh=tU252hT3N5m8Ada6Qaw5YaZVUPXYhptGx01QhADaSUc=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=y3vSVHHdYWkYis+0h3F/OHd8mip+Pzuo4kni1Xpci4YOLVl/zrceJefSsa5r5P4NP ut1i8WiY5pQ9l1WuXWDrtdZ+TtggosanWb6x/S/vpwKHVw4R4kl5oYX1ZXMgwX8WU5 3ETk61jBtZIT2dJBDJ5bSN5Anr85BBzG6MPa3Wlw= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Apr 19 07:31:34 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0839812DA17; Thu, 19 Apr 2018 07:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524148294; bh=tU252hT3N5m8Ada6Qaw5YaZVUPXYhptGx01QhADaSUc=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=y3vSVHHdYWkYis+0h3F/OHd8mip+Pzuo4kni1Xpci4YOLVl/zrceJefSsa5r5P4NP ut1i8WiY5pQ9l1WuXWDrtdZ+TtggosanWb6x/S/vpwKHVw4R4kl5oYX1ZXMgwX8WU5 3ETk61jBtZIT2dJBDJ5bSN5Anr85BBzG6MPa3Wlw= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD7212DA40 for ; Thu, 19 Apr 2018 07:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.059 X-Spam-Level: X-Spam-Status: No, score=-3.059 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL=0.141, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkKrMe16Io1J for ; Thu, 19 Apr 2018 07:31:28 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A1F12DA17 for ; Thu, 19 Apr 2018 07:31:25 -0700 (PDT) Received: from [112.102.118.76] (helo=XueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1f9Aaq-0006qG-9X for new-work@ietf.org; Thu, 19 Apr 2018 14:31:24 +0000 To: new-work@ietf.org From: Xueyuan Message-ID: Date: Thu, 19 Apr 2018 22:31:20 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 19 Apr 2018 07:33:26 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Distributed Tracing Working Group (until 2018-05-18) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 14:31:35 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgRGlzdHJp YnV0ZWQgVHJhY2luZyBXb3JraW5nIEdyb3VwOgogwqAgaHR0cHM6Ly93d3cudzMub3JnLzIwMTgv MDQvZGlzdHJpYnV0ZWQtdHJhY2luZy13Zy1jaGFydGVyLmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJp bmcgdGhhdCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0 aGlzIGRyYWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVl IHJldmlldyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDE4 LTA1LTE4IG9uIHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpw dWJsaWMtbmV3LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0 dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVy IHRoYW4gY29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpD b21taXR0ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNl IHRvCmNvbW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNv b3JkaW5hdGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJl c2VudGF0aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1l bnRzIHZpYSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVz ZW50YXRpdmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVu dHMuCgpJZiB5b3Ugc2hvdWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5m b3JtYXRpb24sIHBsZWFzZQpjb250YWN0IFdlbmR5IFNlbHR6ZXIsIFczQyBTdHJhdGVneSBMZWFk IDx3c2VsdHplckB3My5vcmc+LgoKVGhhbmsgeW91LAoKWHVleXVhbiBKaWEsIFczQyBNYXJrZXRp bmcgJiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMub3JnL0NvbnNvcnRpdW0vTWVt YmVyL0xpc3QKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Thu Apr 19 16:02:45 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E0912E889 for ; Thu, 19 Apr 2018 16:02:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <152417896392.10731.16962058106586512789.idtracker@ietfa.amsl.com> Date: Thu, 19 Apr 2018 16:02:43 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 23:02:44 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-04-19 Reviewer LC end Draft Daniel Franke 2018-03-30 draft-ietf-mmusic-rid-14 Steve Hanna 2018-03-30 draft-ietf-core-senml-14 Klaas Wierenga 2018-02-23 draft-ietf-nfsv4-layout-types-12 For telechat 2018-05-10 Reviewer LC end Draft John Bradley 2018-04-18 draft-ietf-acme-acme-11 Tobias Gondrom 2018-03-12 draft-ietf-tokbind-https-13 Russ Housley R2018-05-03 draft-ietf-secevent-token-09 Leif Johansson R2018-02-26 draft-ietf-homenet-babel-profile-06 Watson Ladd 2018-04-20 draft-hoffman-dns-in-json-14 Barry Leiba 2018-04-10 draft-ietf-bess-evpn-prefix-advertisement-10 Chris Lonvick 2018-04-19 draft-ietf-mtgvenue-meeting-policy-04 Hilarie Orman 2018-04-20 draft-ietf-teas-sr-rsvp-coexistence-rec-02 For telechat 2018-05-24 Reviewer LC end Draft Catherine Meadows 2018-04-30 draft-ietf-teas-actn-framework-13 Yoav Nir 2018-04-24 draft-ietf-idr-bgp-gr-notification-15 Radia Perlman 2018-04-20 draft-ietf-ccamp-microwave-framework-05 Tina Tsou 2018-02-26 draft-ietf-softwire-dslite-yang-15 Last calls: Reviewer LC end Draft Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Daniel Migault 2018-04-27 draft-ietf-lamps-rfc5751-bis-07 Matthew Miller 2018-04-27 draft-ietf-lamps-rfc5750-bis-05 Adam Montville 2018-04-27 draft-ietf-ippm-twamp-yang-08 Russ Mundy 2018-04-25 draft-ietf-ippm-2330-ipv6-04 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-12 Sandra Murphy 2018-04-24 draft-ietf-mmusic-sdp-simulcast-12 Magnus Nystrom 2018-04-23 draft-ietf-httpbis-replay-02 Taylor Yu 2018-04-24 draft-housley-suite-b-to-historic-04 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Ólafur Guðmundsson 2018-01-09 draft-ietf-opsawg-nat-yang-09 Dan Harkins 2018-05-31 draft-ietf-dtn-bpsec-06 Next in the reviewer rotation: Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Robert Sparks From nobody Thu Apr 19 17:28:36 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96BF126DED for ; Thu, 19 Apr 2018 17:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfx2S2jEpIMH for ; Thu, 19 Apr 2018 17:28:11 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9355C126CB6 for ; Thu, 19 Apr 2018 17:28:10 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id d79-v6so2706595lfd.0 for ; Thu, 19 Apr 2018 17:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wu2Fh/+jDVbROOvhmOYzm02aeD8nLXibG3SsZpjjR0g=; b=WGauVwaR64tBkHM2YkK5BafPv3eNr9TIwds2QyCRiH8qsOfhbHBe3y+fIp2CSUOUhJ wgcEkkdNZRkKYmbDI+861+mvEZ6Avf+aWwQX3PEz6wL7it+3gopm1M6ne0txU+kVBDBv jZGUJFffGr3h4fN/dkc41goqsrMdYXcFUpk98+h2IUdnhANp+IuPa0wQpKRek21CKMv6 KUofpAHn6fjvC0CWO7svB6qC30NMpFFrmei0T4qVUJxqH1JK2KwoB7AzfvoioXiYSYgz 4yMIs5lsyrKCMArjeE9c/ayLXlT82xjpKXY+u36sZNsrpz040QJElhujLVbCX6n6a6Sr wPsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=wu2Fh/+jDVbROOvhmOYzm02aeD8nLXibG3SsZpjjR0g=; b=KBdep+Kvslfypnf9S9zI6OkE/P81ojrB4b2jjT+wTn8EgwnjyAYNCIpmjRyquZMeGg O7KZasWGV84qmr7v6DHXL9ikous9XgmkC5JsLT8jxi1Ar7X0F25kcm7M4ODShypVGaf7 7cpaW3Vh+R39dUOIRSVSGB+rP7NG3KNjp5cWge9uoGWSHfUjjUL3UFC0mmeqnPyym9cC wt2ItcQ8f7rcU8iJM/T8Xd0tFOnPX9ChnxC61ymJv0fV2ZDHgang5b1/qvzkHG17SDca eAdJpX2ldrIKAqVkdPtAlMYaO0kXnAIptCrbg7YaCZVSWK5IGSCh0NT058pPYWkajTxd XOhw== X-Gm-Message-State: ALQs6tDU+0QPWYC/SBLz5PiYavCkf6aUubOcIFOAiLsMT6X1ubCNyVI8 foPkyN1xtSYg429urNU8AgCkzUY6r2P/AGzukxrL+g== X-Google-Smtp-Source: AIpwx4+vBPBSbxNkjhtVqgmb5siX8R9KDZqWpXL7b4fsBgkIcZYAJyWQNySKm7ybfnqgZ1aryKMdStyhNRSIFL5Ppeg= X-Received: by 10.46.85.196 with SMTP id g65mr5345832lje.10.1524184088423; Thu, 19 Apr 2018 17:28:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:cbd2:0:0:0:0:0 with HTTP; Thu, 19 Apr 2018 17:28:07 -0700 (PDT) In-Reply-To: References: From: Watson Ladd Date: Thu, 19 Apr 2018 17:28:07 -0700 Message-ID: To: secdir@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [secdir] Fwd: SECDIR review of draft-hoffman-dns-in-json X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 00:28:35 -0000 ---------- Forwarded message ---------- From: Watson Ladd Date: Thu, Mar 29, 2018 at 1:27 PM Subject: SECDIR review of draft-hoffman-dns-in-json To: "" , saag@ietf.org, draft-hoffman-dns-in-json.all@tools.ietf.org Dear all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is ready with issues. I have some very strong reservations about defining a data format without some strong round-tripping guarantees and with as much flexibility as this one. The JSON format for DNS packets is intended to permit representation of malformed packets, and has a high degree of flexibility, with an intent that applications define profiles of it for themselves. There are considerable security implications to doing this not addressed in the Security Implications section, in addition to obvious interoperability issues. For example, if we have a filter for JSON representations of DNS packets, this filter must share the same semantics for the output JSON as the consumer, even in the face of such bizzarities as HEX and regular fields with different contents, malformed length fields, etc. etc. I expect that this can and will cause serious issues. I would suggest we not represent invalid packets and ensure all valid packets have a unique representation. Failing that the security consideration should at minimum be amended to include a discussion of these issues. A schema that can be used to validate DNS packets represented in JSON could also help address these problems. Sincerely, Watson Ladd -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Apr 19 18:35:26 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C672127076; Thu, 19 Apr 2018 18:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTkZ-JgG-GZv; Thu, 19 Apr 2018 18:35:16 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763F0126C83; Thu, 19 Apr 2018 18:35:13 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id h8-v6so4244415otb.2; Thu, 19 Apr 2018 18:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=V7lOoYPC7fAedWKovhZfdMHyBLoUnYmWdEfyjsKSmzA=; b=m4ITligyNf3wgOivkGqXzfqEXbiNfbZZYmQTA5/z5eS/FUpb4+8en4upJxBVRNwHh1 UOiIbu8RYJq+DuJ0Mjd4F4z5MzuXfXIzXNpwx4l+ydQRvk2kt+MFNfSFK8ozxDSnq15M Ka19OJBdK+AVYMg59MBxt29MwkCTF7PO87XEFVv3+fg7O0jEpkgVw/ljgK39/3ygPzIj YNQyQa9rrx0qbStadBnIqbdtZ9VstURMPEeyi481IMfUhVI3Tzw475niZbqCryad/Mq+ f0ukMACo8hlUgPc4M3CYZmu5VWX4vxzW5rzwk0tj5Qs2/ncPFxoNqWFSiA9OFoxxezWc NhJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=V7lOoYPC7fAedWKovhZfdMHyBLoUnYmWdEfyjsKSmzA=; b=JFujE2/wkRIuQlXo0dbptUyteG/OhVPxeviJaC65yewC8pCsX5jD0/64cpAZB2UJc3 fazhQSCdYg/J5VZl+dqkB6FOTK1W9zOk0gcX4ri0QG9qHRg1XOe648obI8kpgw3sChJ5 giRoH4QHoPpCfgordjW5Z0MF+pTmntHBKV+IddGBo+hxG6ggiCTg6VKZobZMhUtZobXz esLi7cIsoswSmMXL7VUwj0CLO9XyJ29Nt4C468XdHAFSrNkAv/drLYMGSm3VzHfWaEcA DnxZ94C8ep8l5i+3zt3DbVAf0HAHhv8LrGpnQHVtxnz4/mKmZmxjcxybS8jooE4skTnS SpQA== X-Gm-Message-State: ALQs6tD6+sG1fWECxqRohka3Zs5DwBH0X9ptqWV5lUomBEloTSidqVq5 D1JUHRpNy1ahWVknwmPTl96SwA== X-Google-Smtp-Source: AIpwx49glIrTWZ0jbQMZLCUnxRai4T3/9EVQDuTxZD1TP9XPDsKlQHvB+dKgYgZH+mdmKv9ie9vvtQ== X-Received: by 2002:a9d:26a2:: with SMTP id l31-v6mr3209241otb.303.1524188112704; Thu, 19 Apr 2018 18:35:12 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:d4be:d073:fbc5:dc4d]) by smtp.googlemail.com with ESMTPSA id o69-v6sm3261783oik.14.2018.04.19.18.35.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 18:35:12 -0700 (PDT) To: draft-ietf-mtgvenue-meeting-policy.all@ietf.org, "secdir@ietf.org" , "iesg@ietf.org" From: Chris Lonvick Message-ID: <5AD943CE.9020605@gmail.com> Date: Thu, 19 Apr 2018 20:35:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040308000109080801010601" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-mtgvenue-meeting-policy-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 01:35:18 -0000 This is a multi-part message in MIME format. --------------040308000109080801010601 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. While there is no Security Considerations section, I don't think that any is needed for this document. I found the document to be well written and well composed. I found no nits in it. Best regards, Chris --------------040308000109080801010601 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready.

While there is no Security Considerations section, I don't think that any is needed for this document.

I found the document to be well written and well composed. I found no nits in it.

Best regards,
Chris

--------------040308000109080801010601-- From nobody Thu Apr 19 18:55:04 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884561270A7; Thu, 19 Apr 2018 18:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiIe_5c0ntRs; Thu, 19 Apr 2018 18:55:01 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F201270A0; Thu, 19 Apr 2018 18:55:00 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id f63-v6so6692094oic.4; Thu, 19 Apr 2018 18:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=CtEZVMVyZGIyGlKCdpXoXt5wXLYrjcvEJu3eoOYXO2I=; b=ZcSXbpirLBzIkbmkvFuX3n2jZu5JihO+LXV+JCwRBynE0I202mIQHZfp68rBVQRSbt ytdngSB2B/V3gFNFJ0u5+2fnNlcPtB41kI+1Olze6+Pa1zLaKFUkdjrSvqU9kOc2e2YA /tbbMWhoZNfG21GXiZFC23SurGgse17DSPwGoPsbPGKGLSlckhabsjV7Br/SyyUkPwt9 hsaIX5CiTWqp0WbhJZRnB/0UUQiIF8bz2W008CTYsvtk+ZUZ3+Oo8a4Txe/TbQv2vJjD 0r3ZMvajyij5Gzc9SYgN3BLRKZVYl6eCgLJRcl13wspOED7CHGI7rQmtUHg83AX0eRJ2 5knA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=CtEZVMVyZGIyGlKCdpXoXt5wXLYrjcvEJu3eoOYXO2I=; b=LH8/8Px8zaiYQWUc27HkeB4BildHtoqy24QhS08AIXLoB+ZIgJQ9W7J65WD8w3EZox iAvXzhdydNen+DN7l0kggFL5vmhOX3Dl0VPW+5epn+j6GjiYDeG/g9gAx3x99MoD2vGb d3lY4i6ogjz/THE/zoBjuE112mXh7Mb/IGoy5KPKcGfWIi/ko24i7TemX5+g7JlEmu4S IrDnhOoXxVXrIx8QxkTW0tI96y33M/n+n6KLnb9TpZxMNPYr3DgqxVWQx4w7txvqN8/K KKFYW3iCYqOmg4xxUw8yuoTEYIyvRkegkdQiejT0SY8kwaOUpVKOxPlzF84KE8o9nl4H SE5A== X-Gm-Message-State: ALQs6tD75ZRHUIy/80Ftv3rVDJ3nNwgwgNMxLlLsuUg/bMMaxhjwAOfp I37MO+dmIct5z+bKUFYfgf1w9A== X-Google-Smtp-Source: AIpwx49ybygQXtjiB2UHGd//kWryKHCwWTYv9+eLqe9pJSiInSqtcCZNkPkmFUjulz/Gjdaan32wtA== X-Received: by 2002:aca:560b:: with SMTP id k11-v6mr4803833oib.201.1524189299994; Thu, 19 Apr 2018 18:54:59 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:c497:774:9d63:5a82]) by smtp.googlemail.com with ESMTPSA id c49-v6sm3014611ote.79.2018.04.19.18.54.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 18:54:59 -0700 (PDT) To: draft-ietf-6lo-rfc6775-update.all@ietf.org, "secdir@ietf.org" , secdir-secretary@ietf.org, "iesg@ietf.org" From: Chris Lonvick Message-ID: <5AD94872.7080509@gmail.com> Date: Thu, 19 Apr 2018 20:54:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] SECDIR review of SECDIR re-review of draft-ietf-6lo-rfc6775-update-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 01:55:02 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY. The authors have nicely addressed the nits I brought to their attention in the -11 version. My apologies for the lateness of this. Best regards, Chris From nobody Fri Apr 20 11:04:01 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3701212D88B; Fri, 20 Apr 2018 11:03:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: Cc: draft-ietf-secevent-token.all@ietf.org, ietf@ietf.org, id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152424742315.3484.7625515486296411114@ietfa.amsl.com> Date: Fri, 20 Apr 2018 11:03:43 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-secevent-token-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 18:03:43 -0000 Reviewer: Russ Housley Review result: Has Issues I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-secevent-token-09 Reviewer: Russ Housley Review Date: 2018-04-20 IETF LC End Date: unknown IESG Telechat date: 2018-05-10 Summary: Has Issues Major Concerns I do not understand the first paragraph of Section 3. I made this comment on version -07, and some words were added, but I still do not understand this paragraph. I think you are trying to impose some rules on future specifications that use SET to define events. Let me ask a couple of questions that may help. I understand that a profiling specification MUST specify the syntax and semantics for a collection of security event tokens, including the claims and payloads that are expected. What MUST a profiling specification include? What MUST a profiling specification NOT include? From nobody Fri Apr 20 14:35:18 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FFC127023; Fri, 20 Apr 2018 14:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfyQ2IuxpHbm; Fri, 20 Apr 2018 14:35:14 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5B61243FE; Fri, 20 Apr 2018 14:35:14 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1f9dgW-0002n8-Ul; Fri, 20 Apr 2018 15:35:12 -0600 Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1f9dgW-0001tZ-4R; Fri, 20 Apr 2018 15:35:12 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w3KLYmVi016976; Fri, 20 Apr 2018 15:34:48 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id w3KLYlMY016971; Fri, 20 Apr 2018 15:34:47 -0600 Date: Fri, 20 Apr 2018 15:34:47 -0600 Message-Id: <201804202134.w3KLYlMY016971@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org Cc: draft-ietf-teas-sr-rsvp-coexistence-rec.all@tools.ietf.org X-XM-SPF: eid=1f9dgW-0001tZ-4R; ; ; mid=<201804202134.w3KLYlMY016971@rumpleteazer.rhmr.com>; ; ; hst=in02.mta.xmission.com; ; ; ip=72.250.219.84; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX18HCnAlTyyablYDE/Y8vUMN X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 483 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 2.9 (0.6%), b_tie_ro: 1.90 (0.4%), parse: 1.08 (0.2%), extract_message_metadata: 4.3 (0.9%), get_uri_detail_list: 1.61 (0.3%), tests_pri_-1000: 3.1 (0.6%), tests_pri_-950: 1.43 (0.3%), tests_pri_-900: 1.16 (0.2%), tests_pri_-400: 20 (4.1%), check_bayes: 19 (3.8%), b_tokenize: 6 (1.2%), b_tok_get_all: 6 (1.2%), b_comp_prob: 2.5 (0.5%), b_tok_touch_all: 2.5 (0.5%), b_finish: 0.64 (0.1%), tests_pri_0: 443 (91.6%), check_dkim_signature: 0.46 (0.1%), check_dkim_adsp: 219 (45.3%), tests_pri_500: 4.4 (0.9%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: Subject: [secdir] Security review of draft-ietf-teas-sr-rsvp-coexistence-rec-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 21:35:16 -0000 Security review of Recommendations for RSVP-TE and Segment Routing LSP co-existence draft-ietf-teas-sr-rsvp-coexistence-rec-02 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. When two independent protocols are used to manage bandwidth on one shared link, the problem of efficient use of the total bandwidth will depend on how much information the traffic engineering database has about the utilization and reservations handled by the two protocols. This situation occurs when RSVP-TE and Segment Routing LSP are used simultaneously. The draft rules out centralized controllers for RSVP-TE as an option. It also notes that the co-existence of two protocols might be a temporary situation arising during a transition from RSVP-TE to SR LSP. This seems to imply that the recommendations are a stopgap measure. Although there is a claim of "no new security considerations", I think that the proposed solution, of giving SR traffic demands the best preemption priority in the network, could be a problem in terms of covert channels and denial of service. If the adjustments in the TED result in any observable change in traffic patterns, then a malicious party might be able to infer usage on an SR channel or even disrupt the RSVP-TE channels by driving up demand on the SR channel. Moreover, it might be possible to send the traffic management algorithms into some kind of resonance crisis by increasing and diminishing demand rapidly. Although the proposed solution has a damping factor, I would be concerned about systems operating in parallel that might exhibit second order effects. Could the draft address the security and stability concerns in some reassuring way? Like, "don't let this happen"? In section 3.5, this sentence threw me for a loop: However, changing the maximum bandwidth for the TE link will prevent any compute engine for SR or RSVP to decipher the real static bandwidth of the TE link After rereading it several times, I think that "decipher" has no cryptographic significance and should be replaced by "determine" or "measure", and rewritten in the form "will prevent any compute engine ... from determining ...". Hilarie From nobody Fri Apr 20 19:36:33 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65276127076 for ; Fri, 20 Apr 2018 19:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiKDC9IcGcVv for ; Fri, 20 Apr 2018 19:36:30 -0700 (PDT) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB84126C83 for ; Fri, 20 Apr 2018 19:36:30 -0700 (PDT) Received: by mail-qt0-x242.google.com with SMTP id w12-v6so11923499qti.4 for ; Fri, 20 Apr 2018 19:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bi55N7ThaNjQSmVpEtPjUHfbUjaMgWF0oPcZv00i96s=; b=lO+MTXKi6SzcYIXk0YtZA4BzYHdG5d7qRuBE9EH7pc01wxSjePmTxWbmYn0mON60Su tIN5aB1Nye7GC/kSt1C1/niKiMrYpCgJ80OKsz0uLUONhxJlnk2M8IOP6tSTa4IOroar 3M7OWokG2l++mzKTvFl8RY05lG1NYo2vj7/Q8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bi55N7ThaNjQSmVpEtPjUHfbUjaMgWF0oPcZv00i96s=; b=TUghP/qQl1XDqpnLrx0SKg/tTuy72MAeMlKtwj3kpn8Fd46ZVz9vX13d416uH+cD9Z KtW4abldGb1KmIa1CqLy3+TL6Bj9f7oiJZrUa5JJ67ls6gvSh6nTWZBd2lmrZWDTYeIj bJ8apnk0/527ujeofBDwE5f0hDe2ixL5Fx6Q+wQQzS4bF+/AXR+ea83MXrb+rMkdmjCg hn7RiabwfxtRXtnW1cR3r84T9osJzH+Y/lPKnLUGEsGTMyLElcjgZcVZV4w6/pHfZDfM SWpjLYU/HfxpH55F8hoQlFGEdV3tKT1szY2Q8sgksPGsaskUMND7mf1IIeSi0OT+EhEy 9e3A== X-Gm-Message-State: ALQs6tCmM92I8mNGPWO++d68QhLd5ajTPCqGvCR5aavAcoaQKcvu4OGD Vm5ZICtDFYX0DlJcrMdbkHk3ayl6GVs= X-Google-Smtp-Source: AIpwx4+onPxlsOipSaq8peBOvw6UF9di4Y5kOzNiQTorEospIhfhXd94ESbXNlYke07AjbN3U9maiA== X-Received: by 2002:aed:3069:: with SMTP id 96-v6mr13749886qte.283.1524278189462; Fri, 20 Apr 2018 19:36:29 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id q42-v6sm7001009qtc.49.2018.04.20.19.36.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Apr 2018 19:36:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: <0B9DB69A-472E-4FF5-9164-FCFB59C26D64@pfrc.org> Date: Fri, 20 Apr 2018 22:36:27 -0400 Cc: Richard Barnes , secdir , Russ White , Stewart Bryant , "Acee Lindem (acee)" , "BRUNGARD, DEBORAH A" Content-Transfer-Encoding: quoted-printable Message-Id: References: <026301d3d4e4$380d8b00$a828a100$@riw.us> <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> <2AD240AE-DF39-4D76-8D6B-BB8AADC6C267@pfrc.org> <024301d3d588$2b8ac6a0$82a053e0$@riw.us> <0B9DB69A-472E-4FF5-9164-FCFB59C26D64@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 02:36:32 -0000 Having tried to help* the last time the routing and security got = together, I can=E2=80=99t help but suggest that with this: > On Apr 15, 2018, at 15:27, Jeffrey Haas wrote: >=20 >=20 >> On Apr 15, 2018, at 2:04 PM, Russ White wrote: >>=20 >>=20 >>> As Richard said, the headline issue for outsiders like me is BGP = hijacking, >>> whether as a mean to hijack addresses and inject spam, or as a way = to >>=20 >> This is more about documenting how routing folks should build their = security considerations sections to reduce the friction between the = security area and the routing area. A much more prosaic situation, I = know... =F0=9F=98=8A >=20 > ^This. and this: > On Apr 16, 2018, at 10:28, Jeffrey Haas wrote: >=20 >=20 >> How about "Better Routing Application Transport Security (BRATS)"? = ;) >=20 > Only if we get our own line of dolls. that maybe a better name is: PEDICURE PixiE Dust routIng seCURity considErations Because, it sounds like that=E2=80=99s where we=E2=80=99ll be looking ;) = A nice side effect of this effort is that routing drafts can start to = skip secdir reviews after this is done because whatever this group comes = up with is going to get copied everywhere; it=E2=80=99ll be like MIB = security considerations! I assume that=E2=80=99s really the short term = plan right? I=E2=80=99m trying to not be too much of downer here, but the last time = security helped there was a lot of: you don=E2=80=99t understand how = these protocols are used/deployed, key management is too onerous, and = whoa that=E2=80=99s too heavy weight/gold plated. Since the last time = around security still doesn=E2=80=99t come for free and pretty much = every security protocol still requires some type of key management =E2=80=A6= so what=E2=80=99s going to be different this time around? I.e., why = would one want to volunteer to help one of these to be formed small = teams? spt * for some value of help.= From nobody Sat Apr 21 08:29:42 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E079127698; Sat, 21 Apr 2018 08:29:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: spasm@ietf.org, draft-ietf-lamps-rfc5750-bis.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152432458128.20660.6956595430755199355@ietfa.amsl.com> Date: Sat, 21 Apr 2018 08:29:41 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lamps-rfc5750-bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 15:29:41 -0000 Reviewer: Matthew Miller Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-lamps-rfc5750-bis-05 Reviewer: Matthew A. Miller Review Date: 2018-04-21 IETF LC End Date: 2018-04-27 IESG Telechat date: N/A Summary: This document is ready, but there is one nit around PKCS #6 handling that might benefit from explanation. This document describes the certificate handling expectations for senders and receivers of S/MIME 4.0. It obsoletes RFC 5750, adding requirements to support internationalized email addresses, increase RSA minimum key sizes, and support ECDSA using P-256 and Ed25519; older algorithms such as DSA, MD5, and SHA-1 are relegated to historical. Major Issues: N/A Minor Issues: N/A Nits: Section 2.2.1. "Historical Note about CMS Certificates" is almost entired unchanged, but added a requirement that receivers MUST be able to process PCKS #6 extended certificates. This almost seems at odds with the rest of the paragraph that precedes this MUST, noting PKCS #6 has little use and PKIX is functionally equivalent. A short explanation of why this additional handling requirement would seem helpful. From nobody Sat Apr 21 09:33:51 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EAA129C53; Sat, 21 Apr 2018 09:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7y7TVY4HhcH; Sat, 21 Apr 2018 09:33:42 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706ED124F57; Sat, 21 Apr 2018 09:33:39 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 21 Apr 2018 09:31:08 -0700 From: Jim Schaad To: 'Matthew Miller' , CC: , , References: <152432458128.20660.6956595430755199355@ietfa.amsl.com> In-Reply-To: <152432458128.20660.6956595430755199355@ietfa.amsl.com> Date: Sat, 21 Apr 2018 09:33:29 -0700 Message-ID: <005e01d3d98e$7ca8ff70$75fafe50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIiXucpxcMduUMNivilcG+pvhU0KKNuXsjw Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lamps-rfc5750-bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 16:33:45 -0000 Matt, Perhaps you can suggest a better wording. To me it says what I think it = is supposed to say. What I was shooting for. If you receive an S/MIME message and that = message contains PKCS#6 certificate. You cannot fail processing the = message because of the presence of the PKCS#6 certificate, but you can = ignore the content of that certificate. Jim > -----Original Message----- > From: Matthew Miller > Sent: Saturday, April 21, 2018 8:30 AM > To: secdir@ietf.org > Cc: spasm@ietf.org; draft-ietf-lamps-rfc5750-bis.all@ietf.org; = ietf@ietf.org > Subject: Secdir last call review of draft-ietf-lamps-rfc5750-bis-05 >=20 > Reviewer: Matthew Miller > Review result: Has Nits >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. >=20 > Document: draft-ietf-lamps-rfc5750-bis-05 > Reviewer: Matthew A. Miller > Review Date: 2018-04-21 > IETF LC End Date: 2018-04-27 > IESG Telechat date: N/A >=20 > Summary: >=20 > This document is ready, but there is one nit around PKCS #6 handling = that > might benefit from explanation. >=20 > This document describes the certificate handling expectations for = senders > and receivers of S/MIME 4.0. It obsoletes RFC 5750, adding = requirements to > support internationalized email addresses, increase RSA minimum key = sizes, > and support ECDSA using P-256 and Ed25519; older algorithms such as = DSA, > MD5, and SHA-1 are relegated to historical. >=20 > Major Issues: N/A >=20 > Minor Issues: N/A >=20 > Nits: >=20 > Section 2.2.1. "Historical Note about CMS Certificates" is almost = entired > unchanged, but added a requirement that receivers MUST be able to = process > PCKS #6 extended certificates. This almost seems at odds with the = rest of > the paragraph that precedes this MUST, noting PKCS #6 has little use = and > PKIX is functionally equivalent. > A short explanation of why this additional handling requirement would = seem > helpful. From nobody Sun Apr 22 14:57:25 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7485E126C26 for ; Sun, 22 Apr 2018 14:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FQpDd7_iazo for ; Sun, 22 Apr 2018 14:57:22 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 988071200F1 for ; Sun, 22 Apr 2018 14:57:22 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 8DD371E401; Sun, 22 Apr 2018 17:58:25 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: Date: Sun, 22 Apr 2018 17:57:21 -0400 Cc: Richard Barnes , secdir , Russ White , Stewart Bryant , "Acee Lindem (acee)" , "BRUNGARD, DEBORAH A" Content-Transfer-Encoding: quoted-printable Message-Id: <97CBB44D-3236-405C-B62C-C3BEF8DB933D@pfrc.org> References: <026301d3d4e4$380d8b00$a828a100$@riw.us> <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> <2AD240AE-DF39-4D76-8D6B-BB8AADC6C267@pfrc.org> <024301d3d588$2b8ac6a0$82a053e0$@riw.us> <0B9DB69A-472E-4FF5-9164-FCFB59C26D64@pfrc.org> To: Sean Turner X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 21:57:24 -0000 > On Apr 20, 2018, at 10:36 PM, Sean Turner wrote: >=20 >> On Apr 16, 2018, at 10:28, Jeffrey Haas wrote: >>=20 >>=20 >>> How about "Better Routing Application Transport Security (BRATS)"? = ;) >>=20 >> Only if we get our own line of dolls. >=20 > that maybe a better name is: >=20 > PEDICURE PixiE Dust routIng seCURity considErations >=20 > Because, it sounds like that=E2=80=99s where we=E2=80=99ll be looking = ;) A nice side effect of this effort is that routing drafts can start = to skip secdir reviews after this is done because whatever this group = comes up with is going to get copied everywhere; it=E2=80=99ll be like = MIB security considerations! I assume that=E2=80=99s really the short = term plan right? >=20 > I=E2=80=99m trying to not be too much of downer here, but the last = time security helped there was a lot of: you don=E2=80=99t understand = how these protocols are used/deployed, key management is too onerous, = and whoa that=E2=80=99s too heavy weight/gold plated. Since the last = time around security still doesn=E2=80=99t come for free and pretty much = every security protocol still requires some type of key management =E2=80=A6= so what=E2=80=99s going to be different this time around? I.e., why = would one want to volunteer to help one of these to be formed small = teams? Let me complete being a downer here. Or at least further advance it. Yes, the goal is to end up with a lot of copy and paste. If you're not = tired of being on the security side of the discussion saying "this = document is missing transport security considerations" and having to go = through a tedious dance with those who don't understand them? Well... I = can't see that you're not. This response is exactly what I'd expect to = see. You'll also see I'm not pushing this as "all security considerations". = Transport - to start. Because that's something most routing folk will = grok and has a chance (see my slides) at being deployable - at least in = some circumstances.* Examples being use of TCP-AO so that things like key management can be = done. And pointers to good key management practices. And without = having to have this exact discussion with every single document author = every single time. Unless you really enjoy having this discussion = repeatedly, in which case we can all go back to doing things exactly as = they're done today. :-) As I point out in my slides, a significant part of this headache is an = ecosystem issue. I write mostly BGP related software as part of my day = job. I'm aware of better security practices. I don't control the = TCP/IP stack I get to use - and these things are not implemented in our = routing suite. Yelling at me to have better security at those layers is = a NOP; at best I pass them back up to product managers to get it done in = the people who manage those layers.** -- Jeff * See karp bootstrapping issues. We didn't make a ton of progress for = Reasons. Lots of good analyses and followups from that though. ** TLS can be used in places when appropriate, and that's effectively in = control of some devs working on control plane. However, the operational = considerations often means that it's not a wise choice. >=20 > spt >=20 > * for some value of help. From nobody Sun Apr 22 15:17:44 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65D2126D85 for ; Sun, 22 Apr 2018 15:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEbd65MJ_n9K for ; Sun, 22 Apr 2018 15:17:41 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860E91200FC for ; Sun, 22 Apr 2018 15:17:41 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx60.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fANIg-000Fxm-NL for secdir@ietf.org; Mon, 23 Apr 2018 00:17:39 +0200 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fANIb-00022S-Gq for secdir@ietf.org; Sun, 22 Apr 2018 18:17:34 -0400 Received: (qmail 29388 invoked from network); 22 Apr 2018 22:17:30 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.78]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 Apr 2018 22:17:30 -0000 To: Jeffrey Haas , Sean Turner Cc: "BRUNGARD, DEBORAH A" , secdir , Russ White , Stewart Bryant , "Acee Lindem (acee)" References: <026301d3d4e4$380d8b00$a828a100$@riw.us> <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> <2AD240AE-DF39-4D76-8D6B-BB8AADC6C267@pfrc.org> <024301d3d588$2b8ac6a0$82a053e0$@riw.us> <0B9DB69A-472E-4FF5-9164-FCFB59C26D64@pfrc.org> <97CBB44D-3236-405C-B62C-C3BEF8DB933D@pfrc.org> From: Christian Huitema Openpgp: preference=signencrypt Message-ID: <1c18b4e6-d7ba-1d63-ba53-9292995ad7b0@huitema.net> Date: Sun, 22 Apr 2018 15:17:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <97CBB44D-3236-405C-B62C-C3BEF8DB933D@pfrc.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.190 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.14) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5vh99GZ83ZBAilYCxXHA7zZ602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzniiMFxnOFMHTZqw+apvQzTV/3OdXD2Xdo8CfrY5CQS2/HfDCF3+BO7LhlaThPf4oyz NJVaeAWax4WOe4pTBX2DwIE7VKe+bqpcdCns72R16Duyz4UD14ePeUAPER8QDaXe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtP/UPTAAMnNuB6/0WWjH77oh6ijzwzq5HGxV3pRhOdYuobeA2G NaAif0QyGEAJd8kel+zffa+S3paXsykGResyE7dAzbZabvf4+eAvvSn0D5YzxzA4C4+ILjmdkQoL 6F7cCSavQBrPoagEXfZ210Cx8bwqyT5p50x81ZKcmzCu2U1l0pLLr6Q2GfeLeJGF+80D4WY7xWSn pVjQVprFFOt2hDWKtLT9WR57oxUvRixjadcobnduoQv5Sp6y3SmK1n5SMPepZn00xVXQbuUt1pns FwEiRQv+PVjjwa+Z5RFCOMTpZO2F7gR9fPNnztJleHauSrAWlToiTWgG7mSH912JHX9vOwe8e8rd vCGSYFH6igGU2yw6z85L3UyCdO+oQ3S7VPd90DA1c/ZLOZZo7XGPVfWv8HL1YL3Zn8TE/e4IMjT6 4dZYZAAUgQSn0n4YsmwR9pozWdbw56YFdP5Q2QyzPOggKW28pboyZCmKkHUYXanYpLuxjuBVBgpa uPkPLIoHdMvNN8GmDerZ4JeMOBsC9HtB4/4Pbrz2QtFuyl+Sh6eSsUPc54JCDDPrhwG8vzFYfqb5 R4VemuUI6bcEARsm0KnLtMabt6P+t78klMitoc+NZy58uobCIkCdwVDO83SGTnM2K/9iKCD9v589 nVS3hWSdEOMftBjsWb6BDQzjSsHUIomTnJwT4ky6b7E7Hukt2Ge4B8NG0VKlrY+34Zmj+F/tjlrZ UvGhhjiSam0tWhQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 22:17:44 -0000 On 4/22/2018 2:57 PM, Jeffrey Haas wrote: > As I point out in my slides, a significant part of this headache is an = ecosystem issue. I write mostly BGP related software as part of my day j= ob. I'm aware of better security practices. I don't control the TCP/IP = stack I get to use - and these things are not implemented in our routing = suite. Yelling at me to have better security at those layers is a NOP; a= t best I pass them back up to product managers to get it done in the peop= le who manage those layers.** That's actually part of the secure transport selection problem. TCP-MD5 and TCP-AO are not used a lot outside of BGP. They may be standardized, but they are not really "mainline". And as such, you may or may not find it available in your OS of choice. And as you write, as BGP developer you have little control over that. Mainline applications are content with TLS, but that won't solve the TCP-RST issue that you are concerned about. IPSEC will solve it, but at the cost of interesting management issues. I really wonder whether the practical solution might be to standardize on a transport like QUIC that runs over UDP. Of course, QUIC is not really mainline, at least not yet. But the code can be compiled with the application, independently of the OS. So as a BGP developer, you could just ship it with your code. You would in fact control the transport stack that you use. -- Christian Huitema From nobody Sun Apr 22 15:46:23 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D3E1200FC for ; Sun, 22 Apr 2018 15:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_RHS_DOB=1.514] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH68i_p2MIn3 for ; Sun, 22 Apr 2018 15:46:18 -0700 (PDT) Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D40126FDC for ; Sun, 22 Apr 2018 15:46:18 -0700 (PDT) Received: by mail-ot0-x241.google.com with SMTP id a14-v6so15215149otf.6 for ; Sun, 22 Apr 2018 15:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yg9BMSLuWRJUJVsWRl+0kyvS2swtFXzf9PyD/38eIqM=; b=bBi7P3zMLIl4hxM/VT7GvdEHtkl5cL8i5GSfccQvvZFE8oIgnqEIS98Xae4FJquFT+ rNnEQFh/xXTGuPzzYMQU6WSFCrrxwEH/TnFPiFfcm3cKz1FT+v4TQuyv7P09gbKtZqTf CkHFLo42qyf6+JJ29K0ocVVGyp4w/q0bklCd+3tkyPoAscsqAjesBo2qfCxKSsO6PiR6 HMNMYuqzCESvJh57UaLmeieDl5nJ593l1LYBDHMoKzN7EGe1qln0uewyN2E7TvIo6iZg MgJVT9PDzAHFiIkyeFrzmB42w6GdW2uObcunhPmendeaXeTJ6NWa3iHE58WA/4Yaq8ph Fjsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yg9BMSLuWRJUJVsWRl+0kyvS2swtFXzf9PyD/38eIqM=; b=P0wF+1e995XFNJgvkoLvzESsc64Q380pThJIbaGrlqulRt+A7JV56C1uiktYxTgxJ5 d9LncdtQeXq1ATZI3uFELJav8zAzRkjOMK5jt/jDXBQuAcyTn0Ty+7ZPd4Bok3Jq1UW7 gTdojt4wod7ZmYcIf7bznDGFU+MwSPjCZNSfw3inhA4W8gN2XSUvxRPXujAvhTfARwiB Nukish1JMZRWgwoFil2ktOAfN2RetxS3BEXdbZMhYw/4/6od1GSwIN8Nz4mjhBF8dWEk UJnS6iHKEUpOHIyPadc9FIkmw2RYMDs4gCmZYeyA7SGWY/ilnkSOvkmAP9wluSwwlWto ds+w== X-Gm-Message-State: ALQs6tD8eE7K0aSFd5TpokovMU5iZHqdRC3ttht14LzHAUTULUlw6Uyd Z01ZZDN4N2QnyMQ8YqphVZ821ULfCAsg5prhcCWPvw== X-Google-Smtp-Source: AIpwx4/CRFeKPB1tY2aCoZKUDzJb6qLA1anB8KPZIG753N/x2gh+/qXL7Lrg0dK2Td+7fM8c/BTtLrQxrdsqHpacXyo= X-Received: by 2002:a9d:27a6:: with SMTP id c35-v6mr11998220otb.271.1524437177784; Sun, 22 Apr 2018 15:46:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.93.90 with HTTP; Sun, 22 Apr 2018 15:46:17 -0700 (PDT) In-Reply-To: References: <026301d3d4e4$380d8b00$a828a100$@riw.us> <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> <2AD240AE-DF39-4D76-8D6B-BB8AADC6C267@pfrc.org> <024301d3d588$2b8ac6a0$82a053e0$@riw.us> <0B9DB69A-472E-4FF5-9164-FCFB59C26D64@pfrc.org> From: Richard Barnes Date: Sun, 22 Apr 2018 18:46:17 -0400 Message-ID: To: Sean Turner Cc: Jeffrey Haas , secdir , Russ White , Stewart Bryant , "Acee Lindem (acee)" , "BRUNGARD, DEBORAH A" Content-Type: multipart/alternative; boundary="00000000000076ee55056a77b0b2" Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 22:46:21 -0000 --00000000000076ee55056a77b0b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 20, 2018 at 10:36 PM, Sean Turner wrote: > Having tried to help* the last time the routing and security got together= , > I can=E2=80=99t help but suggest that with this: > > > On Apr 15, 2018, at 15:27, Jeffrey Haas wrote: > > > > > >> On Apr 15, 2018, at 2:04 PM, Russ White wrote: > >> > >> > >>> As Richard said, the headline issue for outsiders like me is BGP > hijacking, > >>> whether as a mean to hijack addresses and inject spam, or as a way to > >> > >> This is more about documenting how routing folks should build their > security considerations sections to reduce the friction between the > security area and the routing area. A much more prosaic situation, I > know... =F0=9F=98=8A > > > > ^This. > > and this: > > > On Apr 16, 2018, at 10:28, Jeffrey Haas wrote: > > > > > >> How about "Better Routing Application Transport Security (BRATS)"? ;) > > > > Only if we get our own line of dolls. > > that maybe a better name is: > > PEDICURE PixiE Dust routIng seCURity considErations > LIPSTIC - Limited Improvements to Secure Transports for the Internet Control plane We're not going to make this pig any less ugly, but we will apply some ... --Richard > > Because, it sounds like that=E2=80=99s where we=E2=80=99ll be looking ;) = A nice side > effect of this effort is that routing drafts can start to skip secdir > reviews after this is done because whatever this group comes up with is > going to get copied everywhere; it=E2=80=99ll be like MIB security consid= erations! > I assume that=E2=80=99s really the short term plan right? > > I=E2=80=99m trying to not be too much of downer here, but the last time s= ecurity > helped there was a lot of: you don=E2=80=99t understand how these protoco= ls are > used/deployed, key management is too onerous, and whoa that=E2=80=99s too= heavy > weight/gold plated. Since the last time around security still doesn=E2= =80=99t come > for free and pretty much every security protocol still requires some type > of key management =E2=80=A6 so what=E2=80=99s going to be different this = time around? > I.e., why would one want to volunteer to help one of these to be formed > small teams? > > spt > > * for some value of help. --00000000000076ee55056a77b0b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 20, 2018 at 10:36 PM, Sean Turner <sean@sn3rd.com> wrote:
Having tried to help* the last= time the routing and security got together, I can=E2=80=99t help but sugge= st that with this:

> On Apr 15, 2018, at 15:27, Jeffrey Haas <jhaas@pfrc.org> wrote:
>
>
>> On Apr 15, 2018, at 2:04 PM, Russ White <russ@riw.us> wrote:
>>
>>
>>> As Richard said, the headline issue for outsiders like me is B= GP hijacking,
>>> whether as a mean to hijack addresses and inject spam, or as a= way to
>>
>> This is more about documenting how routing folks should build thei= r security considerations sections to reduce the friction between the secur= ity area and the routing area. A much more prosaic situation, I know... =F0= =9F=98=8A
>
> ^This.

and this:

> On Apr 16, 2018, at 10:28, Jeffrey Haas <jhaas@pfrc.org> wrote:
>
>
>> How about "Better Routing Application Transport Security (BRA= TS)"?=C2=A0 ;)
>
> Only if we get our own line of dolls.

that maybe a better name is:

PEDICURE=C2=A0 =C2=A0 =C2=A0 =C2=A0 PixiE Dust routIng seCURity considErati= ons

LIPSTIC - Limited Improvements to S= ecure Transports for the Internet Control plane

We're not going to make this pig any less ugly, but we will apply som= e ...

--Richard

=C2=A0

Because, it sounds like that=E2=80=99s where we=E2=80=99ll be looking ;)=C2= =A0 A nice side effect of this effort is that routing drafts can start to s= kip secdir reviews after this is done because whatever this group comes up = with is going to get copied everywhere; it=E2=80=99ll be like MIB security = considerations!=C2=A0 I assume that=E2=80=99s really the short term plan ri= ght?

I=E2=80=99m trying to not be too much of downer here, but the last time sec= urity helped there was a lot of: you don=E2=80=99t understand how these pro= tocols are used/deployed, key management is too onerous, and whoa that=E2= =80=99s too heavy weight/gold plated.=C2=A0 Since the last time around secu= rity still doesn=E2=80=99t come for free and pretty much every security pro= tocol still requires some type of key management =E2=80=A6 so what=E2=80=99= s going to be different this time around?=C2=A0 I.e., why would one want to= volunteer to help one of these to be formed small teams?

spt

* for some value of help.

--00000000000076ee55056a77b0b2-- From nobody Sun Apr 22 15:51:52 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40F9126FDC for ; Sun, 22 Apr 2018 15:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5GT-2B03dGP for ; Sun, 22 Apr 2018 15:51:48 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FAA1200FC for ; Sun, 22 Apr 2018 15:51:47 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id x9-v6so12592123oig.7 for ; Sun, 22 Apr 2018 15:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gSZQdzu17KQj92kVAXUmuL0TaFAMjNF6xHNYVwXyaao=; b=bgQqMcV1LbtvUQZyg/3YnC4i3do5bDQ2/oerRfYPB/GjNY8DCrfnz1qonR49flFGWC 0CN4G6n6assMt3mJgXD6/5m8iWXG6HXBXcUl8ovBAkNeJidWwuHAJbELXloR/wxmGsvz d6iySk8MHEWq1W07xIqfYAaqot7z82JJXbKYzgjgrvZIU4CwDFciHWMbj7gN9cI5dVWD bL5vdrKN8qw4lsviefyQvu77rXr50M8Y7q23pY3gCbPanVyQz5u+93t5Kch4SxUxro6H o2lWiFxg+BkPJyhyuVXk+WUi5LCGwE+W51qNLR0j59x9550WmZVe0psBK0/0OK5fQdnS SZMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gSZQdzu17KQj92kVAXUmuL0TaFAMjNF6xHNYVwXyaao=; b=oey9FOsRtVv2dNa0nayrO3FH5zHbs44s3j1+9e6QCPVeCcr+0Hfy0Kj8nHVKiWheRH IQj5wQXz8obE/ObQ9UlFBK0x/kZW1CeJjKnShxOT8HuDvxe1nLNWjO0NX0vnmRaRcCqG vthYlYmZDDZlMNQwqQWfTrBzjUJdeqEvCm5oj2uNm+6S6WjSv2AMVXpnUENqZxveyERd yL9NC5rMcvIhoPxPazwC3gJJNt/btnl6Bu/+MOHxHAKMks/lrjRcLQkn9UlPnSi/+JJu TIia5QwypusWZfhuThUrrMhW9CrPvhTWDM4bXbJma9JbMLw2lf8wFxXlwfehdyWf2gWg YGGg== X-Gm-Message-State: ALQs6tD7k/pLrmfst8/yKOio0lTyPPfPsP9nYO8/USgZhWZgLRZq9J2N mZj4Cge3vzXvTzrlwfRsowW7IKm91F7FGolAFNnWWg== X-Google-Smtp-Source: AIpwx49t807orkxQleGHmkfLxtsLrLhU9TyHoFueHAMyIkdOZf5JnwbvU8WTm98UuBZj39oMoNOdS1+wkZrbFQzxC9Y= X-Received: by 2002:a54:400e:: with SMTP id x14-v6mr5954047oie.77.1524437507174; Sun, 22 Apr 2018 15:51:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.93.90 with HTTP; Sun, 22 Apr 2018 15:51:46 -0700 (PDT) In-Reply-To: <1c18b4e6-d7ba-1d63-ba53-9292995ad7b0@huitema.net> References: <026301d3d4e4$380d8b00$a828a100$@riw.us> <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> <2AD240AE-DF39-4D76-8D6B-BB8AADC6C267@pfrc.org> <024301d3d588$2b8ac6a0$82a053e0$@riw.us> <0B9DB69A-472E-4FF5-9164-FCFB59C26D64@pfrc.org> <97CBB44D-3236-405C-B62C-C3BEF8DB933D@pfrc.org> <1c18b4e6-d7ba-1d63-ba53-9292995ad7b0@huitema.net> From: Richard Barnes Date: Sun, 22 Apr 2018 18:51:46 -0400 Message-ID: To: Christian Huitema Cc: Jeffrey Haas , Sean Turner , Russ White , Stewart Bryant , "Acee Lindem (acee)" , "BRUNGARD, DEBORAH A" , secdir Content-Type: multipart/alternative; boundary="000000000000190bde056a77c4ff" Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 22:51:51 -0000 --000000000000190bde056a77c4ff Content-Type: text/plain; charset="UTF-8" On Sun, Apr 22, 2018 at 6:17 PM, Christian Huitema wrote: > On 4/22/2018 2:57 PM, Jeffrey Haas wrote: > > > As I point out in my slides, a significant part of this headache is an > ecosystem issue. I write mostly BGP related software as part of my day > job. I'm aware of better security practices. I don't control the TCP/IP > stack I get to use - and these things are not implemented in our routing > suite. Yelling at me to have better security at those layers is a NOP; at > best I pass them back up to product managers to get it done in the people > who manage those layers.** > > That's actually part of the secure transport selection problem. TCP-MD5 > and TCP-AO are not used a lot outside of BGP. They may be standardized, > but they are not really "mainline". And as such, you may or may not find > it available in your OS of choice. And as you write, as BGP developer > you have little control over that. Mainline applications are content > with TLS, but that won't solve the TCP-RST issue that you are concerned > about. IPSEC will solve it, but at the cost of interesting management > issues. I really wonder whether the practical solution might be to > standardize on a transport like QUIC that runs over UDP. Of course, QUIC > is not really mainline, at least not yet. But the code can be compiled > with the application, independently of the OS. So as a BGP developer, > you could just ship it with your code. You would in fact control the > transport stack that you use. > This seems like a really useful analysis approach. The bias in this work should be toward transport protocols that other apps use -- since in the context we're talking about here, routing is just another application. So we should start with the default, mainline protocols (TLS, IPsec), and look at where they don't fit. In otherwords: I would prefer to see this group not have as a goal "Universal deployment of TCP-[MD5|AO]", but rather "Removal of custom hacks from the ecosystem and replacement by a more mainline protocol". Let's bring routing protocols into the applications fold to the greatest degree possible. --Richard > > -- Christian Huitema > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --000000000000190bde056a77c4ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Apr 22, 2018 at 6:17 PM, Christian Huitema &l= t;huitema@huitema.= net> wrote:
On 4/22/2018 2:57 PM, Jeffrey Haas wrote:

> As I point out in my slides, a significant part of this headache is an= ecosystem issue.=C2=A0 I write mostly BGP related software as part of my d= ay job.=C2=A0 I'm aware of better security practices.=C2=A0 I don't= control the TCP/IP stack I get to use - and these things are not implement= ed in our routing suite.=C2=A0 Yelling at me to have better security at tho= se layers is a NOP; at best I pass them back up to product managers to get = it done in the people who manage those layers.**

That's actually part of the secure transport selection problem. = TCP-MD5
and TCP-AO are not used a lot outside of BGP. They may be standardized,
but they are not really "mainline". And as such, you may or may n= ot find
it available in your OS of choice. And as you write, as BGP developer
you have little control over that. Mainline applications are content
with TLS, but that won't solve the TCP-RST issue that you are concerned=
about. IPSEC will solve it, but at the cost of interesting management
issues. I really wonder whether the practical solution might be to
standardize on a transport like QUIC that runs over UDP. Of course, QUIC is not really mainline, at least not yet. But the code can be compiled
with the application, independently of the OS. So as a BGP developer,
you could just ship it with your code. You would in fact control the
transport stack that you use.

This seem= s like a really useful analysis approach.=C2=A0 The bias in this work shoul= d be toward transport protocols that other apps use -- since in the context= we're talking about here, routing is just another application.=C2=A0 S= o we should start with the default, mainline protocols (TLS, IPsec), and lo= ok at where they don't fit.

In otherwords:= I would prefer to see this group not have as a goal "Universal deploy= ment of TCP-[MD5|AO]", but rather "Removal of custom hacks from t= he ecosystem and replacement by a more mainline protocol".=C2=A0=C2=A0= Let's bring routing protocols into the applications fold to the greate= st degree possible.

--Richard

=C2=A0

-- Christian Huitema

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/= wiki/SecDirReview

--000000000000190bde056a77c4ff-- From nobody Sun Apr 22 15:54:58 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE2D127010 for ; Sun, 22 Apr 2018 15:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAqVrMhNTjsk for ; Sun, 22 Apr 2018 15:54:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3362E1200FC for ; Sun, 22 Apr 2018 15:54:54 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 2DC561E401; Sun, 22 Apr 2018 18:55:57 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E7A49EC9-E6F5-4BCF-B3EE-3294789C30DC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: Date: Sun, 22 Apr 2018 18:54:52 -0400 Cc: Christian Huitema , Sean Turner , Russ White , Stewart Bryant , "Acee Lindem (acee)" , "BRUNGARD, DEBORAH A" , secdir Message-Id: References: <026301d3d4e4$380d8b00$a828a100$@riw.us> <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> <2AD240AE-DF39-4D76-8D6B-BB8AADC6C267@pfrc.org> <024301d3d588$2b8ac6a0$82a053e0$@riw.us> <0B9DB69A-472E-4FF5-9164-FCFB59C26D64@pfrc.org> <97CBB44D-3236-405C-B62C-C3BEF8DB933D@pfrc.org> <1c18b4e6-d7ba-1d63-ba53-9292995ad7b0@huitema.net> To: Richard Barnes X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] New Routing Area Security Design Team X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 22:54:56 -0000 --Apple-Mail=_E7A49EC9-E6F5-4BCF-B3EE-3294789C30DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 22, 2018, at 6:51 PM, Richard Barnes wrote: >=20 >=20 >=20 > On Sun, Apr 22, 2018 at 6:17 PM, Christian Huitema = > wrote: > On 4/22/2018 2:57 PM, Jeffrey Haas wrote: >=20 > > As I point out in my slides, a significant part of this headache is = an ecosystem issue. I write mostly BGP related software as part of my = day job. I'm aware of better security practices. I don't control the = TCP/IP stack I get to use - and these things are not implemented in our = routing suite. Yelling at me to have better security at those layers is = a NOP; at best I pass them back up to product managers to get it done in = the people who manage those layers.** >=20 > That's actually part of the secure transport selection problem. = TCP-MD5 > and TCP-AO are not used a lot outside of BGP. They may be = standardized, > but they are not really "mainline". And as such, you may or may not = find > it available in your OS of choice. And as you write, as BGP developer > you have little control over that. Mainline applications are content > with TLS, but that won't solve the TCP-RST issue that you are = concerned > about. IPSEC will solve it, but at the cost of interesting management > issues. I really wonder whether the practical solution might be to > standardize on a transport like QUIC that runs over UDP. Of course, = QUIC > is not really mainline, at least not yet. But the code can be compiled > with the application, independently of the OS. So as a BGP developer, > you could just ship it with your code. You would in fact control the > transport stack that you use. >=20 > This seems like a really useful analysis approach. The bias in this = work should be toward transport protocols that other apps use -- since = in the context we're talking about here, routing is just another = application. So we should start with the default, mainline protocols = (TLS, IPsec), and look at where they don't fit. >=20 > In otherwords: I would prefer to see this group not have as a goal = "Universal deployment of TCP-[MD5|AO]", but rather "Removal of custom = hacks from the ecosystem and replacement by a more mainline protocol". = Let's bring routing protocols into the applications fold to the greatest = degree possible. I'm quite supportive of this. See my slides. :-) As I mentioned earlier in the thread, a goal is to simply clarify the = common scenarios and boilerplate them. If we can address this through = profiles on existing solutions - so much the better. As part of the = discussion, however, operational considerations need to be considered = very strongly. -- Jeff --Apple-Mail=_E7A49EC9-E6F5-4BCF-B3EE-3294789C30DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Apr 22, 2018, at 6:51 PM, Richard Barnes <rlb@ipv.sx> wrote:



On Sun, Apr 22, 2018 at 6:17 PM, Christian Huitema = <huitema@huitema.net> = wrote:
On = 4/22/2018 2:57 PM, Jeffrey Haas wrote:

> As I point out in my slides, a significant part of this headache is = an ecosystem issue.  I write mostly BGP related software as part of = my day job.  I'm aware of better security practices.  I don't = control the TCP/IP stack I get to use - and these things are not = implemented in our routing suite.  Yelling at me to have better = security at those layers is a NOP; at best I pass them back up to = product managers to get it done in the people who manage those = layers.**

That's actually part of the secure transport selection problem. = TCP-MD5
and TCP-AO are not used a lot outside of BGP. They may be = standardized,
but they are not really "mainline". And as such, you may or may not = find
it available in your OS of choice. And as you write, as BGP developer
you have little control over that. Mainline applications are content
with TLS, but that won't solve the TCP-RST issue that you are = concerned
about. IPSEC will solve it, but at the cost of interesting management
issues. I really wonder whether the practical solution might be to
standardize on a transport like QUIC that runs over UDP. Of course, = QUIC
is not really mainline, at least not yet. But the code can be = compiled
with the application, independently of the OS. So as a BGP developer,
you could just ship it with your code. You would in fact control the
transport stack that you use.

This seems like a really = useful analysis approach.  The bias in this work should be toward = transport protocols that other apps use -- since in the context we're = talking about here, routing is just another application.  So we = should start with the default, mainline protocols (TLS, IPsec), and look = at where they don't fit.

In otherwords: I would prefer to see = this group not have as a goal "Universal deployment of TCP-[MD5|AO]", = but rather "Removal of custom hacks from the ecosystem and replacement = by a more mainline protocol".   Let's bring routing protocols = into the applications fold to the greatest degree possible.

I'm quite supportive of this.  See my slides. = :-)

As I mentioned earlier in the = thread, a goal is to simply clarify the common scenarios and boilerplate = them.  If we can address this through profiles on existing = solutions - so much the better.  As part of the discussion, = however, operational considerations need to be considered very = strongly.

-- Jeff

= --Apple-Mail=_E7A49EC9-E6F5-4BCF-B3EE-3294789C30DC-- From nobody Mon Apr 23 20:51:51 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35124126FDC; Mon, 23 Apr 2018 20:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtJrTtfw9bDU; Mon, 23 Apr 2018 20:51:41 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95028124B0A; Mon, 23 Apr 2018 20:51:38 -0700 (PDT) X-AuditID: 1209190c-cedff70000000ad2-93-5adea9c9c00f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id B2.94.02770.9C9AEDA5; Mon, 23 Apr 2018 23:51:37 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w3O3paWN024064; Mon, 23 Apr 2018 23:51:36 -0400 Received: from localhost (nyc-02.triskelion.com [162.243.175.178]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w3O3pY5W016858; Mon, 23 Apr 2018 23:51:35 -0400 From: Taylor Yu To: iesg@ietf.org, secdir@ietf.org, draft-housley-suite-b-to-historic.all@ietf.org Date: Tue, 24 Apr 2018 03:51:34 +0000 Message-ID: Lines: 40 MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUixCmqrXty5b0og4XX5C0WHBeymPFnIrPF h4UPWRyYPZYs+ckUwBjFZZOSmpNZllqkb5fAlXHjzFW2gi6eigdtt5gaGG9ydjFycEgImEj8 6LPrYuTiEBJYzCTR2PCHEcLZyCjx9nwnM4TzjVHiwYtj7CAdbAJyEpdvBXcxcnKICERLLLn9 hgXEFhawkzi35iY7iM0ioCqx4tY6NpByXgEbidn9EiBhHgFOiYcflzGC2LwCghInZz4Ba2UW kJA4+OIF8wRGnllIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdTLzSzRS00p3cQI DhVJnh2MZ954HWIU4GBU4uH98ftulBBrYllxZe4hRkkOJiVRXuP+e1FCfEn5KZUZicUZ8UWl OanFhxglOJiVRHj3ygHleFMSK6tSi/JhUtIcLErivIv2740SEkhPLEnNTk0tSC2CycpwcChJ 8H5dAdQoWJSanlqRlplTgpBm4uAEGc4DNFxqJcjw4oLE3OLMdIj8KUZdjmOXp/UwC7Hk5eel SonzBoEMEgApyijNg5sDivFFn9dvesUoDvSWMO8qkCoeYHqAm/QKaAkT0JIOyTsgS0oSEVJS DYzXGBY/XHVeotU8ST/3UOfenZlbj17N8Jz65fSq5ZalDAGy13nb/93VfurGK/l6+/onL1TV wpeXTJmQyGBQsYSNYXrzmfoNMWIa9bOag9vzV+7Xd77ren+t7C/B8u4Z1mFlD909w2U1/JZ0 bjI3/rD80sO5sfO2XjVVWMsWt6M47EFmwabcuHQlluKMREMt5qLiRAA710NfzAIAAA== Archived-At: Subject: [secdir] secdir review of draft-housley-suite-b-to-historic-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 03:51:44 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with Nits. It's not clear to me whether there are any replacement specs for the crypto suites being declared Historic. Are the remaining crypto suites for these protocols of comparable strength and security properties? More concretely, Section 5 says: "5. Impact of Reclassifying the Suite-B-related RFCs to Historic No interoperability or security concerns are raised by reclassifing the Suite-B-related RFCs to Historic Status." It would be helpful to have some explanation. For example, is it true that none of the RFCs being moved to Historic Status is the sole specification of an algorithm or an identifier for an algorithm that we expect people to continue using? Also there's a typo: "reclassifing" should be "reclassifying". Similarly, in Section 7: "7. Security Considerations The CNSA Suite includes algorithms using the larger key sizes that are included in Suite B. There are no interoperability or security concerns raised by reclassifying the Suite-B-related RFCs to Historic Status." Will there be forthcoming specs for using CNSA Suite algorithms with these protocols? Best regards, -Taylor From nobody Tue Apr 24 05:13:16 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEE0127775; Tue, 24 Apr 2018 05:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524571512; bh=fTIDI5VArQIwvIyK0kcLNceXfsX/pvcmH4n6KJ0na+Q=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=pozGwX3HNdJ33alu9FK1ISGS1bgd2UBkY4dXxjfmKb6fuTVqJj8yte5q1ejKN52Md FafpfHs4xPQw7RUuYjrYPwPn0c03PV1LS1BEEnmnGXSOiJYNUqu7zR7ZHSiOrX787J E+BxDU0oBvLz11gnIGBU5OpFm9kD+zbFBl/x7wXY= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Apr 24 05:05:12 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F06126C83; Tue, 24 Apr 2018 05:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524571512; bh=fTIDI5VArQIwvIyK0kcLNceXfsX/pvcmH4n6KJ0na+Q=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=pozGwX3HNdJ33alu9FK1ISGS1bgd2UBkY4dXxjfmKb6fuTVqJj8yte5q1ejKN52Md FafpfHs4xPQw7RUuYjrYPwPn0c03PV1LS1BEEnmnGXSOiJYNUqu7zR7ZHSiOrX787J E+BxDU0oBvLz11gnIGBU5OpFm9kD+zbFBl/x7wXY= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C355B126C83 for ; Tue, 24 Apr 2018 05:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhR8v9djMwQB for ; Tue, 24 Apr 2018 05:05:08 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B87126BFD for ; Tue, 24 Apr 2018 05:05:08 -0700 (PDT) Received: from [113.4.219.97] (helo=[192.168.124.189]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1fAwgy-00028f-M7 for new-work@ietf.org; Tue, 24 Apr 2018 12:05:05 +0000 To: new-work@ietf.org From: Xueyuan Message-ID: <2cdf3f84-17bc-ca3a-8dee-28548c7dcdba@w3.org> Date: Tue, 24 Apr 2018 20:05:00 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 24 Apr 2018 05:13:14 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web Real-Time Communications Working Group (until 2018-05-25) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 12:05:14 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgV2ViIFJl YWwtVGltZSBDb21tdW5pY2F0aW9ucyBXb3JraW5nIApHcm91cDoKIMKgIGh0dHBzOi8vd3d3Lncz Lm9yZy8yMDE4LzA0L3dlYnJ0Yy1jaGFydGVyLmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhh dCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRy YWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJldmll dyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDE4LTA1LTI1 IG9uIHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpwdWJsaWMt bmV3LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHA6Ly9s aXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4g Y29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0 ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNv bW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5h dGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0 aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZp YSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRp dmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpJ ZiB5b3Ugc2hvdWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRp b24sIHBsZWFzZQpjb250YWN0IERvbWluaXF1ZSBIYXphZWwtTWFzc2lldXggPGRvbUB3My5vcmc+ IGFuZApWaXZpZW4gTGFjb3VyYmEgPHZpdmllbkB3My5vcmc+LCBXZWJSVEMgV0cgVGVhbSBDb250 YWN0cy4KClRoYW5rIHlvdSwKClh1ZXl1YW4gSmlhLCBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNh dGlvbnMKClsxXSBodHRwOi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0CgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXctd29yayBtYWls aW5nIGxpc3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXctd29yawo= From nobody Tue Apr 24 07:32:12 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDBE12DB71; Tue, 24 Apr 2018 07:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524580235; bh=yXvFWrxabgpeTEnIHuPwqJOWEJCvJb7iQxY+BeA27Tc=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=T1e91VDVzDSssZ74cU1BHZteltxuup1a+sO7awdl0MYsjS8cu+xJC97RVL7V8D48i nDNUx+QDgmQrT+4CvBnwEL+cK/jrqg8imNhcwPEcJe676s0NNsrty41lcwN4YjmJeh Bmc9AE1hGvpyUwjN6Z5E+KMByVlhYG7Up6aJkkx4= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Apr 24 07:30:33 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE89512E88D; Tue, 24 Apr 2018 07:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524580232; bh=yXvFWrxabgpeTEnIHuPwqJOWEJCvJb7iQxY+BeA27Tc=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=izXaUcLpavGf6w/z01SOISen9ymzfNKNnCcAUkwTlc09pMmjpU7j4cVi0SlN3s02/ +EHnUNIj2dSCtCVjVxeQRZIyTQ7q16r7hA4AWYODs9j2j3X9ix69Uv2rzjMfQ6mLpX iShOkeiwnY9WpuX8EBnU2p6VFyyFnvBE1tKovMAA= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C927128954 for ; Tue, 24 Apr 2018 07:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_UEfTIcH-Io for ; Tue, 24 Apr 2018 07:29:48 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3F5124205 for ; Tue, 24 Apr 2018 07:29:48 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id f6-v6so15770391ita.2 for ; Tue, 24 Apr 2018 07:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=2DRrtSde9Iq6y7v+KF4kt6+l0qIAG63ZVVN0v9QV6MU=; b=WfqT1y5KdP1qED7SFn4WxOpi/tbzTDoBZtyhEXd3NmLtTuaNqtboiW9Up42Rwc8iNT cX/I+g90HRDMoYFkQwek2DZ/OSVRSOhdzBZhKK0PRCd8XNAkOfVKeO+Ce0JEywNfhZJ2 V8qXicAiIu/MTXdqvV3kFZdCfLMbvlQCaME/3bwbS5NzFcLZrrQgLoSx5RgYJSq/5CN3 eYTodemIoZGS5SX4+r80WD/1W1BaQRiwUq06MGig4Ru0kYLgrwmWu35DYjBqg9O5GWvN nG/srGFldGe6nIXb+BSkOqnLz8V+TsKiKIq4hxNfwD7VYE69IUwdoZT6JgQMMQYoQAFC r7WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=2DRrtSde9Iq6y7v+KF4kt6+l0qIAG63ZVVN0v9QV6MU=; b=qFex4XFj2TA1nZSoW97h3hU65DDxWf0CKmCkf1rmvKsVnNOGn+4ZGmt51TSzSKMvCU FU5+b6qUpqyWRijOiAMlFQzciW4Wc2Qgy1qDuG6IBv3stvgHrnceei+SE8wIjPfLYRqH n5/xGDdDRThDR5vwovDIyR139pabR7u5UX1UXSUWp4vQn/73zFqmuGZv92ZQPV+DJD13 LuHQ/jEJ2vM0CdcK7QX9NgAnwIXxeSAT/7XUdIy3R/qHncWin4TNwTjjhTNp+RtTkdS0 sIXDlrl377UtMkLYY8oDGOlAAxFKTYXhgjGWmewe1yencUQRs3F7XfU5cdL6QIKrZTZv A5Hw== X-Gm-Message-State: ALQs6tDZ4XrxiDYz52zAep83YkXSVnucyexrIuP1MsGir5SQEQa8tQQn avTV347iK1FPMqdrmx/9pnfLyihnV3McBRHpKPM1jQ== X-Google-Smtp-Source: AIpwx49rWDrs2uR8qfhlgz3TsAdi0VPScMri8JX0kAT5e4XxRoNIEpq6t8iAti+NGbkvq+HxnaMgV/+6f8GFfpYOwyE= X-Received: by 2002:a24:ed06:: with SMTP id r6-v6mr17680252ith.87.1524580187452; Tue, 24 Apr 2018 07:29:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.186.131 with HTTP; Tue, 24 Apr 2018 07:29:46 -0700 (PDT) In-Reply-To: References: From: Dorothy Stanley Date: Tue, 24 Apr 2018 07:29:46 -0700 Message-ID: To: new-work@ietf.org Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Precedence: list Content-Type: multipart/mixed; boundary="===============3010102306201151159==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 24 Apr 2018 07:32:09 -0700 Subject: [secdir] [new-work] Fwd: [802.1 - 12663] Call for Comments on Nendica Draft Report ("The Lossless Network for Data Centers") X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 14:30:42 -0000 --===============3010102306201151159== Content-Type: multipart/alternative; boundary="000000000000814677056a98fc4e" --000000000000814677056a98fc4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, The IEEE Industry Connections Activity related to IEEE 802 evolution, IEE= E 802 Network Enhancements for the Next Decade, is requesting comments on its =E2=80=9CLossless Network for Data Centers=E2= =80=9C report. This report may lead to the formation of new projects within IEEE 802. Comments and review are welcome, please see the details below. Thank you, Dorothy Stanley ---------------------- Dorothy Stanley IEEE 802.11 WG Chair, dstanley@ieee.org Hewlett Packard Enterprise dorothy.stanley@hpe.com dstanley1389@gmail.com +1 630-363-1389 <630-363-1389> ---------- Forwarded message ---------- From: Roger Marks Date: Mon, Apr 16, 2018 at 8:05 PM Subject: [802.1 - 12663] Call for Comments on Nendica Draft Report ("The Lossless Network for Data Centers") To: STDS-802-1-L@listserv.ieee.org Ballot due May 7: P802.1AS/D7.0 Due May 11: P802.1CS/D1.4 For particulars see https://1.ieee802.org/active-ballots/ 802.1 list help: https://1.ieee802.org/email-lists/ ----- Dear 802.1 Participants, See below for the 30-day Call for Comments on the Nendica Draft Report "The Lossless Network for Data Centers". This is the first Nendica Draft Report of the IEEE 802 =E2=80=9CNetwork Enhancements for the Next Decade=E2=80=9D = Industry Connections Activity, under 802.1. I encourage you to participate, and to circulate this announcement as widely as you wish, so that we can get input from a wide swath of interested experts. I also encourage you to consider other topics that might be worthy to propose as Nendica Work Items. I expect comments to be addressed at Nendica meetings on 23-24 May at the 802.1/802.3 Interim Session in Pittsburgh. Nendica also plans to meet on 7 May at the 802 Wireless Interim in Warsaw. Cheers, Roger Marks *Call for Comments on Nendica Draft Report ("The Lossless Network for Data Centers")* - Nendica (the IEEE 802 =E2=80=9CNe= twork Enhancements for the Next Decade=E2=80=9D Industry Connections Activity)= , within its Lossless Data Center Networks Work Item , has developed a Nendica Draft Report on "The Lossless Network for Data Centers". Nendica is conducting a Call for Comments seeking the views of all interested parties on this draft. - Nendica specifically solicits comments on the Nendica Draft report 802.1-18-0007-04-ICne ("The Lossless Network for Data Centers"). - The Call for Comments period is 2018-04-13 through 2018-05-13 (Anywhere on Earth). - Participation is open to all and is encouraged. Nendica will address every comment but does not guarantee to accept every comment nor to provide an explicit response. Feel free to notify the Nendica Chair of your contact information if you would like to have further discussions of your comment or of the topic in general; without such information, Nendica may be unable to reach you. - Submit comments using the comment submittal form . - Your comment may reference external documents by URL. Preferably, upload external documents as contributions using the Nendica document repository . - To contribute a new document, log in using an IEEE password . - You may also require external authorization. If you have difficulties, contact the Nendica Chair . - If you wish to submit a set of comments in batch form, do the following: - download and complete the batch comment spreadsheet - upload the completed spreadsheet file to the Nendica document repository - submit a comment using the comment submittal form and referring to the upload comment spreadsheet by document number or URL - For technical issues, you may contact the Work Item Editor , Paul Congdon. - You can review submitted comments . - Thank you for your participation and feedback. =3D=3D=3D Unsubscribe link: mailto:STDS-802-1-L-SIGNOFF-REQUEST@LISTSERV.IEEE.ORG IEEE. Fostering technological innovation and excellence for the benefit of humanity. --000000000000814677056a98fc4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,


The IEEE Industry Connections Acti= vity=C2=A0 related to IEEE 802 evolution,=C2=A0 IEEE 802 Network Enhancements for the Next Decade,
is requesting comments on its =E2=80=9CLossless Network for Data Cen= ters=E2=80=9C report.

This report may lead to = the formation of new projects within IEEE 802.

Comments and review are welcome, please see the details below.<= /p>


Thank = you,=C2=A0

Dorothy Stanley

=

----------------------
Dorothy Stanley
IEEE 802.11 WG Chair, dstanley@ieee.orgHewlett Packard Enterprise
dorothy.stanley@hpe.com
dstanley138= 9@gmail.com
+1 630-363-1389

=

---------- Forwarded message ----------
F= rom: Roger Marks <r.b.marks@ieee.org>
Date: Mon, Apr 16, 2018 at 8:05 PM
Subject: [802.1 - 126= 63] Call for Comments on Nendica Draft Report ("The Lossless Network f= or Data Centers")
To: STDS-802-1-L@listserv.ieee.org


Ballot= due May 7: P802.1AS/D7.0
=C2=A0 Due May 11: P802.1CS/D1.4
For particulars see
=C2=A0 https://1.ieee802.org/active-ballots/
802.1 list help: https://1.ieee802.org/email-lists/
-----

Dear 802.1 Participants,

See below for the 30-day Call for Comments on the Nendica Draft Report &quo= t;The
Lossless Network for Data Centers". This is the first Nendica Draft Re= port
of the IEEE 802 =E2=80=9CNetwork Enhancements for the Next Decade=E2=80=9D = Industry
Connections Activity, under 802.1.

I encourage you to participate, and to circulate this announcement as
widely as you wish, so that we can get input from a wide swath of
interested experts.

I also encourage you to consider other topics that might be worthy to
propose as Nendica Work Items.

I expect comments to be addressed at Nendica meetings on 23-24 May at the 802.1/802.3 Interim Session in Pittsburgh. Nendica also plans to meet on 7<= br> May at the 802 Wireless Interim in Warsaw.

Cheers,

Roger Marks


*Call for Comments on Nendica Draft Report ("The Lossless Network for = Data
Centers")*

=C2=A0 =C2=A0- Nendica <https://1.ieee802.org/802-nendica/= > (the IEEE 802 =E2=80=9CNetwork
=C2=A0 =C2=A0Enhancements for the Next Decade=E2=80=9D Industry Connections= Activity), within
=C2=A0 =C2=A0its Lossless Data Center Networks Work Item
=C2=A0 =C2=A0<https://1.ieee802.org/802-nend= ica/nendica-lldcn/>, has developed a
=C2=A0 =C2=A0Nendica Draft Report on "The Lossless Network for Data Ce= nters". Nendica is
=C2=A0 =C2=A0conducting a Call for Comments seeking the views of all intere= sted parties
=C2=A0 =C2=A0on this draft.
=C2=A0 =C2=A0- Nendica specifically solicits comments on the Nendica Draft = report
=C2=A0 =C2=A0802.1-18-0007-04-ICne
=C2=A0 =C2=A0<https://mentor.ieee.org/8= 02.1/dcn/18/1-18-0007-04-ICne.pdf> ("The
=C2=A0 =C2=A0Lossless Network for Data Centers").
=C2=A0 =C2=A0- The Call for Comments period is 2018-04-13 through
=C2=A0 =C2=A02018-05-13 (Anywhere on Earth).
=C2=A0 =C2=A0- Participation is open to all and is encouraged. Nendica will= address
=C2=A0 =C2=A0every comment but does not guarantee to accept every comment n= or to provide
=C2=A0 =C2=A0an explicit response. Feel free to notify the Nendica Chair =C2=A0 =C2=A0<roge= r@ethair.net> of your contact information if you would like to have<= br> =C2=A0 =C2=A0further discussions of your comment or of the topic in general= ; without
=C2=A0 =C2=A0such information, Nendica may be unable to reach you.
=C2=A0 =C2=A0- Submit comments using the comment submittal form
=C2=A0 =C2=A0<https://forms.office.com= /Pages/ResponsePage.aspx?id=3DrxP5CJot_Uq-JmG5No1M0LV6oY5k9-RPr7c= 6vZe3D-pUMFUxUlZWT09EVTNQUEJDTEFSWFZJNzhOQS4u>
=C2=A0 =C2=A0.
=C2=A0 =C2=A0- Your comment may reference external documents by URL. Prefer= ably,
=C2=A0 =C2=A0upload external documents as contributions using the Nendica d= ocument
=C2=A0 =C2=A0repository <https://mentor.ie= ee.org/802.1/documents?is_group=3DICne>.
=C2=A0 =C2=A0 =C2=A0 - To contribute a new document, log in using an IEEE p= assword
=C2=A0 =C2=A0 =C2=A0 <https://mentor.ieee.= org/802.1/documents?is_group=3DICne>.
=C2=A0 =C2=A0 =C2=A0 - You may also require external authorization. If you = have
=C2=A0 =C2=A0 =C2=A0 difficulties, contact the Nendica Chair <roger@ethair.net>.
=C2=A0 =C2=A0- If you wish to submit a set of comments in batch form, do th= e
=C2=A0 =C2=A0following:
=C2=A0 =C2=A0 =C2=A0 - download and complete the batch comment spreadsheet<= br> =C2=A0 =C2=A0 =C2=A0 <https://u= nsja-my.sharepoint.com/:x:/g/personal/officeuser4564_unsja_onmicr= osoft_com/EdPWJMttjMlEl364aoWge_cBG50m6lhGWdzTKWOeii8z9g?e=3DHd2a= rg>
=C2=A0 =C2=A0 =C2=A0 - upload the completed spreadsheet file to the Nendica= document
=C2=A0 =C2=A0 =C2=A0 repository <https://m= entor.ieee.org/802.1/documents?is_group=3DICne>
=C2=A0 =C2=A0 =C2=A0 - submit a comment using the comment submittal form =C2=A0 =C2=A0 =C2=A0 <https://forms.of= fice.com/Pages/ResponsePage.aspx?id=3DrxP5CJot_Uq-JmG5No1M0LV6oY5= k9-RPr7c6vZe3D-pUMFUxUlZWT09EVTNQUEJDTEFSWFZJNzhOQS4u>
and
=C2=A0 =C2=A0 =C2=A0 referring to the upload comment spreadsheet by documen= t number or URL
=C2=A0 =C2=A0- For technical issues, you may contact the Work Item Editor =C2=A0 =C2=A0<paul.congdon@tallac.com>, Paul Congdon.
=C2=A0 =C2=A0- You can review submitted comments
=C2=A0 =C2=A0<https://forms.office.com/Pages/DesignPage.aspx?auth_pvr=3D= OrgId&auth_upn=3DOfficeUser4564@unsja.onmicrosoft.com&ori= gin=3Dshell#Analysis=3Dtrue&FormId=3DrxP5CJot_Uq-JmG5No1M0LV6= oY5k9-RPr7c6vZe3D-pUMFUxUlZWT09EVTNQUEJDTEFSWFZJNzhOQS4u><= br> =C2=A0 =C2=A0.
=C2=A0 =C2=A0- Thank you for your participation and feedback.

=3D=3D=3D
Unsubscribe link: mailto:STDS-802-1-L-SIGNOFF-REQUEST@LISTSER= V.IEEE.ORG
IEEE. Fostering technological innovation and excellence for the benefit of = humanity.

--000000000000814677056a98fc4e-- --===============3010102306201151159== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============3010102306201151159==-- From nobody Tue Apr 24 08:08:25 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4562D129C6B; Tue, 24 Apr 2018 08:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOwh676TPgpP; Tue, 24 Apr 2018 08:08:21 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D0A1200C5; Tue, 24 Apr 2018 08:08:21 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40VmtB006Hz3HG; Tue, 24 Apr 2018 17:08:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1524582498; bh=vbzrDpFdypeCRsAIwiUymcyDmC0sLe/qXww42AcaBdY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=AWITaF3okTmzsAldnY3irtkFNKXAkOhtLVZ/oR8lJe7E+CKadtdH5D7GyoavZ3v2T 0pazFLoAYwtBwiMxd97dJXb1Uzh4DBrNBiwuJbVeYhY5UyVqKu+/r/NMvB4N5nKIhB vwRq6gCR53hWk3OoOc8iNtkUxNkVGlv3C9n1Wm0s= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qs4dAK52bFNh; Tue, 24 Apr 2018 17:08:16 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 24 Apr 2018 17:08:15 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 33C17A7E07; Tue, 24 Apr 2018 11:08:14 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 33C17A7E07 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 280824000B42; Tue, 24 Apr 2018 11:08:14 -0400 (EDT) Date: Tue, 24 Apr 2018 11:08:14 -0400 (EDT) From: Paul Wouters To: Taylor Yu cc: iesg@ietf.org, secdir@ietf.org, draft-housley-suite-b-to-historic.all@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [secdir] secdir review of draft-housley-suite-b-to-historic-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 15:08:24 -0000 On Tue, 24 Apr 2018, Taylor Yu wrote: > "7. Security Considerations > > The CNSA Suite includes algorithms using the larger key sizes that > are included in Suite B. There are no interoperability or security > concerns raised by reclassifying the Suite-B-related RFCs to Historic > Status." This text is interesting as I see two statements by the US government on the CNSA Suite. The first one is at: https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm Which claims the CNSA Suite is not published yet, but there is a transition set of algorithms to use. The second one is at: https://www.iad.gov/iad/library/ia-guidance/ia-solutions-for-classified/algorithm-guidance/cnsa-suite-and-quantum-computing-faq.cfm Which lists the same algorithms, but no longer calls these a transition list but the actual CNSA Suite. Regardless, since I think the IETF should not be advertising a single governments crypto standards, I think this document would be better of not mentioning CNSA in Section 7 at all. We shouldn't have stamped Suite B in the IETF either, but we were young and naive at the time. So let's not stamp CNSA as a "successor" in any kind of way. The only thing this document should do is move Suite B to Historic. I would suggest something like this for Section 7: The algorithms and key sizes from Suite B, where these algorithms and key sizes were published by the IETF, have been obsoleted or updated by new and more secure algorithms and key sizes. Please see the respective IANA registries and RFC updates for the specific algorithm usage within their specific protocols. I'm fine with mentioning CNSA in Section 2. Paul From nobody Tue Apr 24 08:48:30 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7290B12E8D1 for ; Tue, 24 Apr 2018 08:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vD2Is-qUqZlg for ; Tue, 24 Apr 2018 08:48:26 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F0A12E89A for ; Tue, 24 Apr 2018 08:48:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7D1DA300455 for ; Tue, 24 Apr 2018 11:48:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Rvwrnhwp60fl for ; Tue, 24 Apr 2018 11:48:23 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E6575300435; Tue, 24 Apr 2018 11:48:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Tue, 24 Apr 2018 11:48:28 -0400 Cc: IESG , IETF SecDir , draft-housley-suite-b-to-historic.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <25AEF8D8-8B9A-431B-9903-92C9DD0C8FD2@vigilsec.com> References: To: Taylor Yu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] secdir review of draft-housley-suite-b-to-historic-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 15:48:28 -0000 > On Apr 23, 2018, at 11:51 PM, Taylor Yu wrote: >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > The summary of the review is Ready with Nits. >=20 > It's not clear to me whether there are any replacement specs for the > crypto suites being declared Historic. Are the remaining crypto = suites > for these protocols of comparable strength and security properties? >=20 > More concretely, Section 5 says: >=20 > "5. Impact of Reclassifying the Suite-B-related RFCs to Historic >=20 > No interoperability or security concerns are raised by reclassifing > the Suite-B-related RFCs to Historic Status." >=20 > It would be helpful to have some explanation. For example, is it true > that none of the RFCs being moved to Historic Status is the sole > specification of an algorithm or an identifier for an algorithm that = we > expect people to continue using? Yes, it is true that the conventions for using these algorithms are = specified in other documents. The Suite B profile documents make = reference to those other documents. Section 4.5 points to the one document that makes reference to one of = the Suite B profile document as a citation for a ciphersuite. Both of = these ciphersuites are defined in RFC 5289, which would have been a = better reference. > Also there's a typo: "reclassifing" should be "reclassifying". Indeed. > Similarly, in Section 7: >=20 > "7. Security Considerations >=20 > The CNSA Suite includes algorithms using the larger key sizes that > are included in Suite B. There are no interoperability or security > concerns raised by reclassifying the Suite-B-related RFCs to = Historic > Status." >=20 > Will there be forthcoming specs for using CNSA Suite algorithms with > these protocols? There will be documents, but unlike the Suite B profiles, the IESG will = not be asked to approve them as Informational RFCs. Russ From nobody Tue Apr 24 08:51:52 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B4912E8CE for ; Tue, 24 Apr 2018 08:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pS3e-_u0Zi7v for ; Tue, 24 Apr 2018 08:51:49 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF0C12D779 for ; Tue, 24 Apr 2018 08:51:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 75588300A0E for ; Tue, 24 Apr 2018 11:51:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CZb4pxqvGLtO for ; Tue, 24 Apr 2018 11:51:45 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 90BE6300435; Tue, 24 Apr 2018 11:51:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Tue, 24 Apr 2018 11:51:46 -0400 Cc: IESG , IETF SecDir , draft-housley-suite-b-to-historic.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2C83CCC3-063E-416D-BB68-70E15C726C96@vigilsec.com> References: To: Paul Wouters , Taylor Yu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] secdir review of draft-housley-suite-b-to-historic-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 15:51:51 -0000 > On Apr 24, 2018, at 11:08 AM, Paul Wouters wrote: >=20 > On Tue, 24 Apr 2018, Taylor Yu wrote: >=20 >> "7. Security Considerations >>=20 >> The CNSA Suite includes algorithms using the larger key sizes that >> are included in Suite B. There are no interoperability or security >> concerns raised by reclassifying the Suite-B-related RFCs to = Historic >> Status." >=20 > This text is interesting as I see two statements by the US government > on the CNSA Suite. >=20 > The first one is at: >=20 > https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm >=20 > Which claims the CNSA Suite is not published yet, but there is a > transition set of algorithms to use. >=20 > The second one is at: >=20 > = https://www.iad.gov/iad/library/ia-guidance/ia-solutions-for-classified/al= gorithm-guidance/cnsa-suite-and-quantum-computing-faq.cfm >=20 > Which lists the same algorithms, but no longer calls these a = transition > list but the actual CNSA Suite. >=20 > Regardless, since I think the IETF should not be advertising a single > governments crypto standards, I think this document would be better of > not mentioning CNSA in Section 7 at all. We shouldn't have stamped = Suite B > in the IETF either, but we were young and naive at the time. So let's > not stamp CNSA as a "successor" in any kind of way. The only thing = this > document should do is move Suite B to Historic. >=20 > I would suggest something like this for Section 7: >=20 > The algorithms and key sizes from Suite B, where these = algorithms > and key sizes were published by the IETF, have been obsoleted or > updated by new and more secure algorithms and key sizes. Please > see the respective IANA registries and RFC updates for the > specific algorithm usage within their specific protocols. I think that last sentence of the existing Security Considerations = should remain: ... There are no interoperability or security concerns raised by reclassifying the Suite-B-related RFCs to Historic Status. In fact, I think it should be said first. > I'm fine with mentioning CNSA in Section 2. Good. I think it is useful information. Russ From nobody Tue Apr 24 09:02:35 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD88312E8CE; Tue, 24 Apr 2018 09:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bQgMF8siXsi; Tue, 24 Apr 2018 09:02:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ACBE129C6E; Tue, 24 Apr 2018 09:02:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40Vp4j55Rmz4Kc; Tue, 24 Apr 2018 18:02:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1524585749; bh=cPBvYRILHkh5MjbM6GgkEIa8JGNa4Vgmu3l5eAq9dGw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kdPQNZWuPTMKzkIcvNM9gyxucaKKcHe+jUKZbFEag0TgfLc/3HkTKqK4ykHduRxfV ODpDWPWx0stRGDNIpmxyp1Z4z68e33R0pLF9VutTSU3xrq7BWuUOoY2CcfquVArYhM IaOure61tSg2NEfcYAr8uD/W1Rqk7wXVSjc7ZJ/0= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id X2Qwt6362pjF; Tue, 24 Apr 2018 18:02:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 24 Apr 2018 18:02:26 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B4E8AA7E07; Tue, 24 Apr 2018 12:02:25 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B4E8AA7E07 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A7BD440B820B; Tue, 24 Apr 2018 12:02:25 -0400 (EDT) Date: Tue, 24 Apr 2018 12:02:25 -0400 (EDT) From: Paul Wouters To: Russ Housley cc: Taylor Yu , IESG , IETF SecDir , draft-housley-suite-b-to-historic.all@ietf.org In-Reply-To: <2C83CCC3-063E-416D-BB68-70E15C726C96@vigilsec.com> Message-ID: References: <2C83CCC3-063E-416D-BB68-70E15C726C96@vigilsec.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [secdir] secdir review of draft-housley-suite-b-to-historic-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 16:02:34 -0000 On Tue, 24 Apr 2018, Russ Housley wrote: >> I would suggest something like this for Section 7: >> >> The algorithms and key sizes from Suite B, where these algorithms >> and key sizes were published by the IETF, have been obsoleted or >> updated by new and more secure algorithms and key sizes. Please >> see the respective IANA registries and RFC updates for the >> specific algorithm usage within their specific protocols. > > I think that last sentence of the existing Security Considerations should remain: > > ... There are no interoperability or security > concerns raised by reclassifying the Suite-B-related RFCs to Historic > Status. > > In fact, I think it should be said first. Indeed, I agree with that. I only object to the first sentence mentioning CNSA. Just removing it without replacement text would work too for me. Paul From nobody Tue Apr 24 14:49:21 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE2A124BAC; Tue, 24 Apr 2018 14:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNN7TKyhl80H; Tue, 24 Apr 2018 14:49:12 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B5912D946; Tue, 24 Apr 2018 14:49:12 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3OLVY3h173025; Tue, 24 Apr 2018 21:49:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=aKPjNXpmvJaFZXUqGnWsV3MHe/8MjOo315rapM+0Uds=; b=pdx9mXpwaNm4+AWB7DPnYVLqhC//GIJoIOMUuqg+C0mFEN1matxReHMn+aw5xNOThtFX 0E60pfCSiExC44jlCMlt3MysC2uBAWuJesb3HAeRu/XbRYPml5W8mr8v6GEeQFKZq+IO GaNoXxeaLN8+4SukshMTzPg/+ESA9jmym7ZQSP53xVA5Ru3ck4hsQnt5cdVoWZ1KCQ4n +HpWVgk6o471qat2BAJ5F0WpkTzSpbQtdvNun/3qYmL8ifJDrHIq561ioK3oxYhqUa9Y cOVkujg6q1RQ0PhuOTYCG1N1XZ+JDEk7AALd4uxPiS0l6+RXvm3U2tdbnZHUyTALf63x OA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2hfwy9m4j9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 24 Apr 2018 21:49:10 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w3OLn93Q023475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 24 Apr 2018 21:49:10 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w3OLn8qp000887; Tue, 24 Apr 2018 21:49:09 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Apr 2018 14:49:08 -0700 From: Phil Hunt Message-Id: <2F2D2F99-8116-40EE-8245-D7C5F8793BC0@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F723C054-9F23-4EB7-8162-A734D2E06AFE" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 24 Apr 2018 14:49:47 -0700 In-Reply-To: <152424742315.3484.7625515486296411114@ietfa.amsl.com> Cc: secdir@ietf.org, draft-ietf-secevent-token.all@ietf.org, ietf@ietf.org, ID Events Mailing List , Mike Jones To: Russ Housley References: <152424742315.3484.7625515486296411114@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8873 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=3 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804240204 Archived-At: Subject: Re: [secdir] [Id-event] Secdir last call review of draft-ietf-secevent-token-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 21:49:19 -0000 --Apple-Mail=_F723C054-9F23-4EB7-8162-A734D2E06AFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Russ, Here are proposed changes to address your questions about Section 3. = You=E2=80=99re right that this section is placing requirements on = profiling specifications. The changes made are intended to make this = more explicit. Please let us know if the updated text works for you, = and if so, we=E2=80=99ll publish an updated draft using it. Please see the wdiff text for section 3 below (also attached). Thanks, Phil & Mike =E2=80=94wdiff for sec 3-- 3. Requirements for SET Profiles Profiling specifications of this specification define actual SETs to be used in particular use cases. These profiling specifications define the syntax and semantics of SETs conforming to that SET profile and rules for validating those SETs. Profiling specifications SHOULD define syntax, semantics, subject identification, and validation. Syntax The syntax defined by profiling specifications includes what claims of the SETs defined, = including: Top-Level Claims Claims and event payload values placed at the JWT Claims Set. = Examples are used claims defined by SETs utilizing the profile. JWT specification = (see [RFC7519]), the SET specification, and by the profiling specification. Event Payload The JSON data structure contents and format, containing event- specific information, if any (see Section 1.2). Semantics Defining the semantics of the SET contents for SETs utilizing the profile is equally important. Possibly most important is defining the procedures used to validate the SET issuer and to obtain the keys controlled by the issuer that were used for cryptographic operations used in the JWT representing the SET. For instance, some profiles may define an algorithm for retrieving the SET issuer's keys that uses the "iss" claim value as its input. Likewise, if the profile allows (or requires) that the JWT be unsecured, the means by which the integrity of the JWT is ensured MUST be specified. Subject Identification Profiling specifications MUST define how the event subject is identified in the SET, as well as how to differentiate between the event subject's issuer and the SET issuer, if applicable. It is NOT RECOMMENDED for profiling specifications to use the "sub" claim in cases in which the subject is not globally unique and has a different issuer from the SET itself. Validation Profiling specifications MUST clearly specify the steps that a recipient of a SET utilizing that profile MUST perform to validate that the SET is both syntactically and semantically valid. Among the syntax and semantics of SETs that a profiling specification may define is whether the value of the "events" claim may contain multiple members, and what processing instructions are employed in the single- and multiple-valued cases for SETs conforming to that profile. Many valid choices are possible. For instance, some profiles might allow multiple event identifiers to be present and specify that any that are not understood by recipients be ignored, thus enabling extensibility. Other profiles might allow multiple event identifiers to be present but require that all be understood if the SET is to be accepted. Some profiles might require that only a single value be present. All such choices are within the scope of profiling specifications to define. Profiling specifications MUST clearly specify the steps that a recipient of a SET utilizing that profile MUST perform to validate that the SET is both syntactically and semantically valid. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Apr 20, 2018, at 11:03 AM, Russ Housley = wrote: >=20 > Reviewer: Russ Housley > Review result: Has Issues >=20 > I reviewed this document as part of the Security Directorate's ongoing > effort to review all IETF documents being processed by the IESG. = These > comments were written primarily for the benefit of the Security Area > Directors. Document authors, document editors, and WG chairs should > treat these comments just like any other IETF Last Call comments. >=20 > Document: draft-ietf-secevent-token-09 > Reviewer: Russ Housley > Review Date: 2018-04-20 > IETF LC End Date: unknown > IESG Telechat date: 2018-05-10 >=20 > Summary: Has Issues >=20 > Major Concerns >=20 > I do not understand the first paragraph of Section 3. I made this > comment on version -07, and some words were added, but I still do > not understand this paragraph. I think you are trying to impose some > rules on future specifications that use SET to define events. Let me > ask a couple of questions that may help. I understand that a > profiling specification MUST specify the syntax and semantics for a > collection of security event tokens, including the claims and payloads > that are expected. What MUST a profiling specification include? What > MUST a profiling specification NOT include? >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DhJFx-Z2ih18uUNC= XosAjvygHqn2_K2mtNzqIej3Ah-c&s=3D28OWe42S0bg8Y2eo3VVzACeSYnzgiyyeXLl7tTu9i= 1Y&e=3D --Apple-Mail=_F723C054-9F23-4EB7-8162-A734D2E06AFE Content-Type: multipart/mixed; boundary="Apple-Mail=_3C582A7B-6FD1-403B-A1B5-7FC78EFFAC36" --Apple-Mail=_3C582A7B-6FD1-403B-A1B5-7FC78EFFAC36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Russ,

Here are proposed changes to address your questions about = Section 3.  You=E2=80=99re right that this section is placing = requirements on profiling specifications.  The changes made are = intended to make this more explicit.  Please let us know if the = updated text works for you, and if so, we=E2=80=99ll publish an updated = draft using it.

Please see the wdiff text = for section 3 below (also attached).

Thanks,

Phil & = Mike

=E2=80=94wdiff for sec = 3--
3.  Requirements for SET Profiles

   Profiling specifications of this specification define actual SETs to
   be used in particular use cases.  These profiling specifications
   define the syntax and semantics of SETs conforming to that SET
   profile and rules for validating those SETs.  Profiling
   specifications SHOULD define syntax, semantics, subject
   identification, and validation.

   Syntax
      The syntax defined=
 by
   profiling specifications includes what claims of the SETs defined, =
including:

      Top-Level Claims
         Claims and event payload values placed at the JWT Claims Set. =
Examples are used
         claims =
defined by SETs utilizing the profile. JWT specification (see [RFC7519]), the
         SET specification, and by the profiling specification.

      Event Payload
         The JSON data structure contents and format, containing event-
         specific information, if any (see Section 1.2).

   Semantics
      Defining the semantics of the SET contents for SETs utilizing the
      profile is equally important.  Possibly most important is defining
      the procedures used to validate the SET issuer and to obtain the
      keys controlled by the issuer that were used for cryptographic
      operations used in the JWT representing the SET.  For instance,
      some profiles may define an algorithm for retrieving the SET
      issuer's keys that uses the "iss" claim value as its input.
      Likewise, if the profile allows (or requires) that the JWT be
      unsecured, the means by which the integrity of the JWT is ensured
      MUST be specified.

   Subject =
Identification
      Profiling specifications MUST define how the event subject is
      identified in the SET, as well as how to differentiate between the
      event subject's issuer and the SET issuer, if applicable.  It is
      NOT RECOMMENDED for profiling specifications to use the "sub"
      claim in cases in which the subject is not globally unique and has
      a different issuer from the SET itself.

   Validation
      Profiling specifications MUST clearly specify the steps that a
      recipient of a SET utilizing that profile MUST perform to validate
      that the SET is both syntactically and semantically =
valid.

      Among the syntax and semantics of SETs that a profiling
      specification may define is whether the value of the "events"
      claim may contain multiple members, and what processing
      instructions are employed in the single- and multiple-valued cases
      for SETs conforming to that profile.  Many valid choices are
      possible.  For instance, some profiles might allow multiple event
      identifiers to be present and specify that any that are not
      understood by recipients be ignored, thus enabling extensibility.
      Other profiles might allow multiple event identifiers to be
      present but require that all be understood if the SET is to be
      accepted.  Some profiles might require that only a single value be
      present.  All such choices are within the scope of profiling
      specifications to define.

   Profiling =
specifications MUST clearly specify the steps that a
   recipient of a SET utilizing that profile MUST perform to validate
   that the SET is both syntactically and semantically =
valid.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com
= --Apple-Mail=_3C582A7B-6FD1-403B-A1B5-7FC78EFFAC36 Content-Disposition: attachment; filename*0="wdiff draft-ietf-secevent-token-09.txt draft-ietf-secevent-token"; filename*1=.txt.html Content-Type: text/html; x-unix-mode=0644; name="wdiff draft-ietf-secevent-token-09.txt draft-ietf-secevent-token.txt.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-secevent-token-09.txt draft-ietf-secevent-token.txt 

Security Events Working Group                               P. Hunt, Ed.
Internet-Draft                                                    Oracle
Intended status: Standards Track                                M. Jones
Expires: October 19, 26, 2018                                      Microsoft
                                                              W. Denniss
                                                                  Google
                                                               M. Ansari
                                                                   Cisco
                                                          April 17, 24, 2018

                       Security Event Token (SET)
                      draft-ietf-secevent-token-09

Abstract

   This specification defines the Security Event Token (SET) data
   structure.  A SET describes statements of fact from the perspective
   of an issuer about a subject.  These statements of fact represent an
   event that occurred directly to or about a security subject, for
   example, a statement about the issuance or revocation of a token on
   behalf of a subject.  This specification is intended to enable
   representing security- and identity-related events.  A SET is a JSON
   Web Token (JWT), which can be optionally signed and/or encrypted.
   SETs can be distributed via protocols such as HTTP.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 19, 26, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction and Overview . . . . . . . . . . . . . . . . . .   3
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   4
     1.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  The Security Event Token (SET)  . . . . . . . . . . . . . . .   5
     2.1.  Illustrative Examples . . . . . . . . . . . . . . . . . .   6
       2.1.1.  SCIM Example  . . . . . . . . . . . . . . . . . . . .   6
       2.1.2.  Logout Example  . . . . . . . . . . . . . . . . . . .   8
       2.1.3.  Consent Example . . . . . . . . . . . . . . . . . . .   8
       2.1.4.  RISC Example  . . . . . . . . . . . . . . . . . . . .   9
     2.2.  Core SET Claims . . . . . . . . . . . . . . . . . . . . .  10
     2.3.  Explicit Typing of SETs . . . . . . . . . . . . . . . . .  12
     2.4.  Security Event Token Construction . . . . . . . . . . . .  13
   3.  Requirements for SET Profiles . . . . . . . . . . . . . . . .  14
   4.  Preventing Confusion between SETs and other JWTs  . . . . . .  15  16
     4.1.  Distinguishing SETs from ID Tokens  . . . . . . . . . . .  16
     4.2.  Distinguishing SETs from Access Tokens  . . . . . . . . .  16
     4.3.  Distinguishing SETs from other kinds of JWTs  . . . . . .  17
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  17  18
     5.1.  Confidentiality and Integrity . . . . . . . . . . . . . .  18
     5.2.  Delivery  . . . . . . . . . . . . . . . . . . . . . . . .  18
     5.3.  Sequencing  . . . . . . . . . . . . . . . . . . . . . . .  18
     5.4.  Timing Issues . . . . . . . . . . . . . . . . . . . . . .  19
     5.5.  Preventing Confusion  . . . . . . . . . . . . . . . . . .  19
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  19
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     7.1.  JSON Web Token Claims Registration  . . . . . . . . . . .  20
       7.1.1.  Registry Contents . . . . . . . . . . . . . . . . . .  20
     7.2.  Media Type Registration . . . . . . . . . . . . . . . . .  20  21
       7.2.1.  Registry Contents . . . . . . . . . . . . . . . . . .  20  21
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  22
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  24
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

1.  Introduction and Overview

   This specification defines an extensible Security Event Token (SET)
   data structure, which can be exchanged using protocols such as HTTP.
   The specification builds on the JSON Web Token (JWT) format [RFC7519]
   in order to provide a self-contained token that can be optionally
   signed using JSON Web Signature (JWS) [RFC7515] and/or encrypted
   using JSON Web Encryption (JWE) [RFC7516].

   This specification profiles the use of JWT for the purpose of issuing
   Security Event Tokens (SETs).  This specification defines a base
   format used by profiling specifications to define actual events and
   their meanings.  This specification uses non-normative example events
   to demonstrate how events can be constructed.

   This specification is scoped to security- and identity-related
   events.  While Security Event Tokens may be used for other purposes,
   the specification only considers security and privacy concerns
   relevant to identity and personal information.

   Security events are not commands issued between parties.  A SET
   describes statements of fact from the perspective of an issuer about
   a subject (e.g., a web resource, token, IP address, the issuer
   itself).  These statements of fact represent a logical event that
   occurred directly to or about a security subject, for example, a
   statement about the issuance or revocation of a token on behalf of a
   subject.  A security subject may be permanent (e.g., a user account)
   or temporary (e.g., an HTTP session) in nature.  A state change could
   describe a direct change of entity state, an implicit change of
   state, or other higher-level security statements such as:

   o  The creation, modification, removal of a resource.

   o  The resetting or suspension of an account.

   o  The revocation of a security token prior to its expiry.

   o  The logout of a user session.  Or,

   o  An indication that a user has been given control of an email
      identifier that was previously controlled by another user.

   While subject state changes are often triggered by a user agent or
   security subsystem, the issuance and transmission of an event may
   occur asynchronously and in a back channel to the action that caused
   the change that generated the security event.  Subsequently, a SET
   recipient, having received a SET, validates and interprets the
   received SET and takes its own independent actions, if any.  For
   example, having been informed of a personal identifier being
   associated with a different security subject (e.g., an email address
   is being used by someone else), the SET recipient may choose to
   ensure that the new user is not granted access to resources
   associated with the previous user.  Or, the SET recipient may not
   have any relationship with the subject, and no action is taken.

   While SET recipients will often take actions upon receiving SETs,
   security events cannot be assumed to be commands or requests.  The
   intent of this specification is to define a syntax for statements of
   fact that SET recipients may interpret for their own purposes.

1.1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   For purposes of readability, examples are not URL encoded.
   Implementers MUST percent encode URLs as described in Section 2.1 of
   [RFC3986].

   Throughout this document, all figures MAY contain spaces and extra
   line-wrapping for readability and space limitations.  Similarly, some
   URIs contained within examples have been shortened for space and
   readability reasons.

1.2.  Definitions

   The following definitions are used with SETs:

   Security Event Token (SET)
      A SET is a JWT [RFC7519] conforming to this specification.

   SET Issuer
      A service provider that creates SETs to be sent to other service
      providers known as SET recipients.

   SET Recipient
      A SET recipient is an entity that receives SETs through some
      distribution method.  A SET recipient is the same entity referred
      as a "recipient" in [RFC7519] or "receiver" in related
      specifications.

   Subject
      A SET describes an event or state change that has occurred to a
      subject.  A subject might, for instance, be a principal (e.g.,
      Section 4.1.2 of [RFC7519]), a web resource, an entity such as an
      IP address, or the issuer of the SET.

   Event Identifier
      A member name for an element of the JSON object that is the value
      of the "events" claim in a SET.  This member name MUST be a URI.

   Event Payload
      A member value for an element of the JSON object that is the value
      of the "events" claim in a SET.  This member value MUST be a JSON
      object.

   Profiling Specification
      A specification that profiles the SET data structure to define one
      or more specific event types and their associated claims and
      processing rules.

2.  The Security Event Token (SET)

   A SET is a JWT [RFC7519] data structure that represents one or more
   related aspects of a security event that occurred to a subject.  The
   JWT Claims Set in a SET has the following structure:

   o  The top-level claims in the JWT Claims Set are called the SET
      "envelope".  Some of these claims are present in every SET; others
      will be specific to particular SET profiles or profile families.
      Claims in the envelope SHOULD be registered in the "JSON Web Token
      Claims" registry [IANA.JWT.Claims] or be Public Claims or Private
      Claims, as defined in [RFC7519].

   o  Envelope claims that are profiled and defined in this
      specification are used to validate the SET and provide information
      about the event data included in the SET.  The claim "events"
      contains the event identifiers and event-specific data expressed
      about the security subject.  The envelope MAY include event-
      specific or profile-specific data.  The "events" claim value MUST
      be a JSON object that contains at least one member.

   o  Each member of the "events" JSON object is a name/value pair.  The
      JSON member name is a URI string value, which is the event
      identifier, and the corresponding value is a JSON object known as
      the event "payload".  The payload JSON object contains claims that
      pertain to that event identifier and need not be registered as JWT
      claims.  These claims are defined by the profiling specification
      that defines the event.  An event with no payload claims SHALL be
      represented as the empty JSON object ("{}").

   o  When multiple event identifiers are contained in a SET, they
      represent multiple aspects of the same state transition that
      occurred to the security subject.  They are not intended to be
      used to aggregate distinct events about the same subject.  Beyond
      this, the interpretation of SETs containing multiple event
      identifiers is out of scope for this specification; profiling
      specifications MAY define their own rules regarding their use of
      SETs containing multiple event identifiers, as described in
      Section 3.  Possible uses of multiple values include, but are not
      limited to:

      *  Values to provide classification information (e.g., threat type
         or level).

      *  Additions to existing event representations.

      *  Values used to link potential series of events.

      *  Specific-purpose event URIs used between particular SET issuers
         and SET recipients.

2.1.  Illustrative Examples

   This section illustrates several possible uses of SETs through non-
   normative examples.

2.1.1.  SCIM Example

   The following example shows the JWT Claims Set for a hypothetical
   SCIM [RFC7644] password reset SET.  Such a SET might be used by a
   receiver as a trigger to reset active user-agent sessions related to
   the identified user.

   {
     "iss": "https://scim.example.com",
     "iat": 1458496025,
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "aud": [
       "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
       "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
     ],
     "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
     "events": {
       "urn:ietf:params:scim:event:passwordReset":
         { "id": "44f6142df96bd6ab61e7521d9"},
       "https://example.com/scim/event/passwordResetExt":
         { "resetAttempts": 5}
     }
   }

                Figure 1: Example SCIM Password Reset Event

   The JWT Claims Set usage consists of:

   o  The "events" claim specifying the hypothetical SCIM URN
      ("urn:ietf:params:scim:event:passwordReset") for a password reset,
      and a second value, "https://example.com/scim/event/
      passwordResetExt", that is used to provide additional event
      information such as the current count of resets.

   o  The "iss" claim, denoting the SET issuer.

   o  The "sub" claim, specifying the SCIM resource URI that was
      affected.

   o  The "aud" claim, specifying the intended audiences for the event.
      (The syntax of the "aud" claim is defined in Section 4.1.3 of
      [RFC7519].)

   The SET contains two event payloads:

   o  The "id" claim represents SCIM's unique identifier for a subject.

   o  The second payload identified by "https://example.com/scim/event/
      passwordResetExt") and the payload claim "resetAttempts" conveys
      the current count of reset attempts.  In this example, while the
      count is a simple factual statement for the issuer, the meaning of
      the value (a count) is up to the receiver.  As an example, such a
      value might be used by the receiver to infer increasing risk.

   In this example, the SCIM event indicates that a password has been
   updated and the current password reset count is 5.  Notice that the
   value for "resetAttempts" is in the event payload of an event used to
   convey this information.

2.1.2.  Logout Example

   Here is another example JWT Claims Set for a security event token,
   this one for a Logout Token:

   {
      "iss": "https://server.example.com",
      "sub": "248289761001",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq",
      "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout": {}
      }
   }

            Figure 2: Example OpenID Back-Channel Logout Event

   Note that the above SET has an empty JSON object and uses the JWT
   claims "sub" and "sid" to identify the subject that was logged out.
   At the time of this writing, this example corresponds to the logout
   token defined in the OpenID Connect Back-Channel Logout 1.0
   [OpenID.BackChannel] specification.

2.1.3.  Consent Example
   In the following example JWT Claims Set, a fictional medical service
   collects consent for medical actions and notifies other parties.  The
   individual for whom consent is identified was originally
   authenticated via OpenID Connect.  In this case, the issuer of the
   security event is an application rather than the OpenID provider:

   {
     "iss": "https://my.med.example.org",
     "iat": 1458496025,
     "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
     "aud": [
       "https://rp.example.com"
     ],
     "events": {
       "https://openid.net/heart/specs/consent.html": {
         "iss": "https://connect.example.com",
         "sub": "248289761001",
         "consentUri": [
           "https://terms.med.example.org/labdisclosure.html#Agree"
         ]
       }
     }
   }

                      Figure 3: Example Consent Event

   In the above example, the attribute "iss" contained within the
   payload for the event "https://openid.net/heart/specs/consent.html"
   refers to the issuer of the security subject ("sub") rather than the
   SET issuer "https://my.med.example.org".  They are distinct from the
   top-level value of "iss", which always refers to the issuer of the
   event -- a medical consent service that is a relying party to the
   OpenID Provider.

2.1.4.  RISC Example
   The following example JWT Claims Set is for an account disabled
   event.  This example was taken from a working draft of the RISC
   events specification, where RISC is the OpenID RISC (Risk and
   Incident Sharing and Coordination) working group [RISC].  The example
   is subject to change.

   {
     "iss": "https://idp.example.com/",
     "jti": "756E69717565206964656E746966696572",
     "iat": 1508184845,
     "aud": "636C69656E745F6964",
     "events": {
       "http://schemas.openid.net/secevent/risc/event-type/\
       account-disabled": {
         "subject": {
           "subject_type": "iss-sub",
           "iss": "https://idp.example.com/",
           "sub": "7375626A656374"
         },
         "reason": "hijacking",
         "cause-time": 1508012752
       }
     }
   }

                       Figure 4: Example RISC Event

   Notice that parameters to the event are included in the event
   payload, in this case, the "reason" and "cause-time" values.  The
   subject of the event is identified using the "subject" payload value,
   which itself is a JSON object.

2.2.  Core SET Claims

   The following claims from [RFC7519] are profiled for use in SETs:

   "iss" (Issuer) Claim
      As defined by Section 4.1.1 of [RFC7519], this claim contains a
      string identifying the service provider publishing the SET (the
      issuer).  In some cases, the SET issuer is not the issuer of the
      security subject.  Therefore, implementers cannot assume that the
      issuers are the same unless the profiling specification specifies
      that they are for SETs conforming to that profile.  This claim is
      REQUIRED.

   "iat" (Issued At) Claim
      As defined by Section 4.1.6 of [RFC7519], this claim contains a
      value representing when the SET was issued.  This claim is
      REQUIRED.

   "jti" (JWT ID) Claim
      As defined by Section 4.1.7 of [RFC7519], this claim contains a
      unique identifier for the SET.  The identifier MUST be unique
      within a particular event feed and MAY be used by clients to track
      whether a particular SET has already been received.  This claim is
      REQUIRED.

   "aud" (Audience) Claim
      As defined by Section 4.1.3 of [RFC7519], this claim contains one
      or more audience identifiers for the SET.  This claim is
      RECOMMENDED.

   "sub" (Subject) Claim
      As defined by Section 4.1.2 of [RFC7519], this claim contains a
      StringOrURI value representing the principal that is the subject
      of the SET.  This is usually the entity whose "state" was changed.
      For example:

      *  an IP Address was added to a black list;

      *  a URI representing a user resource that was modified; or,

      *  a token identifier (e.g. "jti") for a revoked token.

      If used, the profiling specification SHOULD define the content and
      format semantics for the value.  This claim is OPTIONAL, as the
      principal for any given profile may already be identified without
      the inclusion of a subject claim.  Note that some SET profiles MAY
      choose to convey event subject information in the event payload
      (either using the "sub" member name or another name), particularly
      if the subject information is relative to issuer information that
      is also conveyed in the event payload, which may be the case for
      some identity SET profiles.

   "exp" (Expiration Time) Claim
      As defined by Section 4.1.4 of [RFC7519], this claim is the time
      after which the JWT MUST NOT be accepted for processing.  In the
      context of a SET however, this notion does not typically apply,
      since a SET represents something that has already occurred and is
      historical in nature.  Therefore, its use is NOT RECOMMENDED.
      (Also, see Section 4.1 for additional reasons not to use the "exp"
      claim in some SET use cases.)

   The following new claims are defined by this specification:

   "events" (Security Events) Claim
      This claim contains a set of event statements that each provide
      information describing a single logical event that has occurred
      about a security subject (e.g., a state change to the subject).
      Multiple event identifiers with the same value MUST NOT be used.
      The "events" claim MUST NOT be used to express multiple
      independent logical events.

      The value of the "events" claim is a JSON object whose members are
      name/value pairs whose names are URIs identifying the event
      statements being expressed.  Event identifiers SHOULD be stable
      values (e.g., a permanent URL for an event specification).  For
      each name present, the corresponding value MUST be a JSON object.
      The JSON object MAY be an empty object ("{}"), or it MAY be a JSON
      object containing data described by the profiling specification.

   "txn" (Transaction Identifier) Claim
      An OPTIONAL string value that represents a unique transaction
      identifier.  In cases in which multiple related JWTs are issued,
      the transaction identifier claim can be used to correlate these
      related JWTs.  Note that this claim can be used in JWTs that are
      SETs and also in JWTs using non-SET profiles.

   "toe" (Time of Event) Claim
      A value that represents the date and time at which the event
      occurred.  This value is a NumericDate (see Section 2 of
      [RFC7519]).  By omitting this claim, the issuer indicates that
      they are not sharing an event time with the recipient.  (Note that
      in some use cases, the represented time might be approximate;
      statements about the accuracy of this field MAY be made by
      profiling specifications.)  This claim is OPTIONAL.

2.3.  Explicit Typing of SETs

   This specification registers the "application/secevent+jwt" media
   type, which can be used to indicate that the content is a SET.  SETs
   MAY include this media type in the "typ" header parameter of the JWT
   representing the SET to explicitly declare that the JWT is a SET.
   This MUST be included if the SET could be used in an application
   context in which it could be confused with other kinds of JWTs.

   Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is
   RECOMMENDED that the "application/" prefix be omitted.  Therefore,
   the "typ" value used SHOULD be "secevent+jwt".

2.4.  Security Event Token Construction

   This section describes how to construct a SET.

   The following is an example JWT Claims Set for a hypothetical SCIM
   SET (which has been formatted for readability):

   {
     "iss": "https://scim.example.com",
     "iat": 1458496404,
     "jti": "4d3559ec67504aaba65d40b0363faad8",
     "aud": [
      "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
      "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
     ],

     "events": {
       "urn:ietf:params:scim:event:create": {
         "ref":
           "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
         "attributes": ["id", "name", "userName", "password", "emails"]
       }
     }
   }

                      Figure 5: Example Event Claims

   The JSON Claims Set is encoded per [RFC7519].

   In this example, the SCIM SET claims are encoded in an unsecured JWT.
   The JOSE Header for this example is:

   {"typ":"secevent+jwt","alg":"none"}

   Base64url encoding of the octets of the UTF-8 representation of the
   JOSE Header yields:

   eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJub25lIn0
   The above example JWT Claims Set is encoded as follows:

   eyJqdGkiOiI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsImlhdCI6MTQ1
   ODQ5NjQwNCwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwiYXVkIjpbImh0
   dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3
   NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4
   NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50
   OmNyZWF0ZSI6eyJyZWYiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRm
   NjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsImF0dHJpYnV0ZXMiOlsiaWQiLCJuYW1lIiwi
   dXNlck5hbWUiLCJwYXNzd29yZCIsImVtYWlscyJdfX19

   The encoded JWS signature is the empty string.  Concatenating the
   parts yields this complete SET:

   eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJub25lIn0.
   eyJqdGkiOiI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsImlhdCI6MTQ1
   ODQ5NjQwNCwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwiYXVkIjpbImh0
   dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3
   NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4
   NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50
   OmNyZWF0ZSI6eyJyZWYiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRm
   NjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsImF0dHJpYnV0ZXMiOlsiaWQiLCJuYW1lIiwi
   dXNlck5hbWUiLCJwYXNzd29yZCIsImVtYWlscyJdfX19.

             Figure 6: Example Unsecured Security Event Token

   For the purpose of having a simpler example in Figure 6, an unsecured
   token is shown.  When SETs are not signed or encrypted, other
   mechanisms such as TLS MUST be employed to provide integrity
   protection, confidentiality, and issuer authenticity, as needed by
   the application.

   When validation (i.e., auditing), or additional transmission security
   is required, JWS signing and/or JWE encryption MAY be used.  To
   create and or validate a signed and/or encrypted SET, follow the
   instructions in Section 7 of [RFC7519].

3.  Requirements for SET Profiles

   Profiling specifications of this specification define actual SETs to
   be used in particular use cases.  These profiling specifications
   define the syntax and semantics of SETs conforming to that SET
   profile and rules for validating those SETs.  Profiling
   specifications SHOULD define syntax, semantics, subject
   identification, and validation.

   Syntax
      The syntax defined by
   profiling specifications includes what claims of the SETs defined, including:

      Top-Level Claims
         Claims and event payload values placed at the JWT Claims Set. Examples are used
         claims defined by SETs utilizing the profile. JWT specification (see [RFC7519]), the
         SET specification, and by the profiling specification.

      Event Payload
         The JSON data structure contents and format, containing event-
         specific information, if any (see Section 1.2).

   Semantics
      Defining the semantics of the SET contents for SETs utilizing the
      profile is equally important.  Possibly most important is defining
      the procedures used to validate the SET issuer and to obtain the
      keys controlled by the issuer that were used for cryptographic
      operations used in the JWT representing the SET.  For instance,
      some profiles may define an algorithm for retrieving the SET
      issuer's keys that uses the "iss" claim value as its input.
      Likewise, if the profile allows (or requires) that the JWT be
      unsecured, the means by which the integrity of the JWT is ensured
      MUST be specified.

   Subject Identification
      Profiling specifications MUST define how the event subject is
      identified in the SET, as well as how to differentiate between the
      event subject's issuer and the SET issuer, if applicable.  It is
      NOT RECOMMENDED for profiling specifications to use the "sub"
      claim in cases in which the subject is not globally unique and has
      a different issuer from the SET itself.

   Validation
      Profiling specifications MUST clearly specify the steps that a
      recipient of a SET utilizing that profile MUST perform to validate
      that the SET is both syntactically and semantically valid.

      Among the syntax and semantics of SETs that a profiling
      specification may define is whether the value of the "events"
      claim may contain multiple members, and what processing
      instructions are employed in the single- and multiple-valued cases
      for SETs conforming to that profile.  Many valid choices are
      possible.  For instance, some profiles might allow multiple event
      identifiers to be present and specify that any that are not
      understood by recipients be ignored, thus enabling extensibility.
      Other profiles might allow multiple event identifiers to be
      present but require that all be understood if the SET is to be
      accepted.  Some profiles might require that only a single value be
      present.  All such choices are within the scope of profiling
      specifications to define.

   Profiling specifications MUST clearly specify the steps that a
   recipient of a SET utilizing that profile MUST perform to validate
   that the SET is both syntactically and semantically valid.

4.  Preventing Confusion between SETs and other JWTs

   Because [RFC7519] states that "all claims that are not understood by
   implementations MUST be ignored", there is a consideration that a SET
   might be confused with another kind of JWT from the same issuer.
   Unless this confusion is prevented, this might enable an attacker who
   possesses a SET to use it in a context in which another kind of JWT
   is expected, or vice-versa.  This section presents concrete
   techniques for preventing confusion between SETs and several other
   specific kinds of JWTs, as well as generic techniques for preventing
   possible confusion between SETs and other kinds of JWTs.

4.1.  Distinguishing SETs from ID Tokens

   A SET might be confused with ID Token [OpenID.Core] if a SET is
   mistakenly or maliciously used in a context requiring an ID Token.
   If a SET could otherwise be interpreted as a valid ID Token (because
   it includes the required claims for an ID Token and valid issuer and
   audience claim values for an ID Token) then that SET profile MUST
   require that the "exp" claim not be present in the SET.  Because
   "exp" is a required claim in ID Tokens, valid ID Token
   implementations will reject such a SET if presented as if it were an
   ID Token.

   Excluding "exp" from SETs that could otherwise be confused with ID
   Tokens is actually defense in depth.  In any OpenID Connect contexts
   in which an attacker could attempt to substitute a SET for an ID
   Token, the SET would actually already be rejected as an ID Token
   because it would not contain the correct "nonce" claim value for the
   ID Token to be accepted in contexts for which substitution is
   possible.

   Note that the use of explicit typing, as described in Section 2.3,
   will not achieve disambiguation between ID Tokens and SETs, as the ID
   Token validation rules do not use the "typ" header parameter value.

4.2.  Distinguishing SETs from Access Tokens

   OAuth 2.0 [RFC6749] defines access tokens as being opaque.
   Nonetheless, some implementations implement access tokens as JWTs.
   Because the structure of these JWTs is implementation-specific,
   ensuring that a SET cannot be confused with such an access token is
   therefore likewise, in general, implementation specific.
   Nonetheless, it is recommended that SET profiles employ the following
   strategies to prevent possible substitutions of SETs for access
   tokens in contexts in which that might be possible:

   o  Prohibit use of the "exp" claim, as is done to prevent ID Token
      confusion.

   o  Where possible, use a separate "aud" claim value to distinguish
      between the SET recipient and the protected resource that is the
      audience of an access token.

   o  Modify access token validation systems to check for the presence
      of the "events" claim as a means to detect security event tokens.
      This is particularly useful if the same endpoint may receive both
      types of tokens.

   o  Employ explicit typing, as described in Section 2.3, and modify
      access token validation systems to use the "typ" header parameter
      value.

4.3.  Distinguishing SETs from other kinds of JWTs

   JWTs are now being used in application areas beyond the identity
   applications in which they first appeared.  For instance, the Session
   Initiation Protocol (SIP) Via Header Field [RFC8055] and Personal
   Assertion Token (PASSporT) [RFC8225] specifications both define JWT
   profiles that use mostly or completely different sets of claims than
   are used by ID Tokens.  If it would otherwise be possible for an
   attacker to substitute a SET for one of these (or other) kinds of
   JWTs, then the SET profile must be defined in such a way that any
   substituted SET will result in its rejection when validated as the
   intended kind of JWT.

   The most direct way to prevent confusion is to employ explicit
   typing, as described in Section 2.3, and modify applicable token
   validation systems to use the "typ" header parameter value.  This
   approach can be employed for new systems but may not be applicable to
   existing systems.

   Another way to ensure that a SET is not confused with another kind of
   JWT is to have the JWT validation logic reject JWTs containing an
   "events" claim unless the JWT is intended to be a SET.  This approach
   can be employed for new systems but may not be applicable to existing
   systems.

   For many use cases, the simplest way to prevent substitution is
   requiring that the SET not include claims that are required for the
   kind of JWT that might be the target of an attack.  For example, for
   [RFC8055], the "sip_callid" claim could be omitted and for [RFC8225],
   the "orig" claim could be omitted.

   In many contexts, simple measures such as these will accomplish the
   task, should confusion otherwise even be possible.  Note that this
   topic is being explored in a more general fashion in JSON Web Token
   Best Current Practices [I-D.ietf-oauth-jwt-bcp].  The proposed best
   practices in that draft may also be applicable for particular SET
   profiles and use cases.

5.  Security Considerations

5.1.  Confidentiality and Integrity

   SETs may contain sensitive information.  Therefore, methods for
   distribution of events SHOULD require the use of a transport-layer
   security mechanism when distributing events.  Parties MUST support
   TLS 1.2 [RFC5246] or a higher version and MAY support additional
   transport-layer mechanisms meeting its security requirements.  When
   using TLS, the client MUST perform a TLS server certificate check,
   per [RFC6125].  Implementation security considerations for TLS can be
   found in "Recommendations for Secure Use of TLS and DTLS" [RFC7525].

   Security events distributed through third parties or that carry
   personally identifiable information SHOULD be encrypted using JWE
   [RFC7516] or secured for confidentiality by other means.

   Unless integrity of the JWT is ensured by other means, it MUST be
   signed using JWS [RFC7515] so that the SET can be authenticated and
   validated by the SET recipient.

5.2.  Delivery

   This specification does not define a delivery mechanism for SETs.  In
   addition to confidentiality and integrity (discussed above),
   implementers and profiling specifications MUST consider the
   consequences of delivery mechanisms that are not secure and/or not
   assured.  For example, while a SET may be end-to-end secured using
   JWE encrypted SETs, without (mutual) TLS, there is no assurance that
   the correct endpoint received the SET and that it could be
   successfully processed.

5.3.  Sequencing

   This specification defines no means of ordering multiple SETs in a
   sequence.  Depending on the type and nature of the events represented
   by SETs, order may or may not matter.  For example, in provisioning,
   event order is critical -- an object cannot be modified before it is
   created.  In other SET types, such as a token revocation, the order
   of SETs for revoked tokens does not matter.  If, however, the event
   conveys a logged in or logged out status for a user subject, then
   order becomes important.

   Profiling specifications and implementers SHOULD take caution when
   using timestamps such as "iat" to define order.  Distributed systems
   will have some amount of clock skew.  Thus, time by itself will not
   guarantee order.

   Specifications profiling SET SHOULD define a mechanism for detecting
   order or sequence of events when the order matters.  For example, the
   "txn" claim could contain an ordered value (e.g., a counter) that the
   issuer includes, although just as for timestamps, ensuring such
   ordering can be difficult in distributed systems.

5.4.  Timing Issues

   When SETs are delivered asynchronously and/or out-of-band with
   respect to the original action that incurred the security event, it
   is important to consider that a SET might be delivered to a SET
   recipient in advance of or behind the process that caused the event.
   For example, a user having been required to log out and then log back
   in again, may cause a token revoked SET to be issued, typically
   causing the receiver to reset all active sessions at the receiver
   that are related to that user.  If revocation SET arrives at the same
   time as the user agent re-logs in, timing could cause problems by
   erroneously treating the new user session as logged out.  Profiling
   specifications SHOULD be careful to consider both SET expression and
   timing issues.  For example, it might be more appropriate to revoke a
   specific session or identity token rather than a general logout
   statement about a "user".  Alternatively, profiling specifications
   could use timestamps that allow new sessions to be started
   immediately after a stated logout event time.

5.5.  Preventing Confusion

   Also, see Section 4 above for both additional security considerations
   and normative text on preventing SETs from being confused with other
   kinds of JWTs.

6.  Privacy Considerations

   If a SET needs to be retained for audit purposes, the signature can
   be used to provide verification of its authenticity.

   SET issuers SHOULD attempt to specialize SETs so that their content
   is targeted to the specific business and protocol needs of the
   intended SET recipients.

   When sharing personally identifiable information or information that
   is otherwise considered confidential to affected users, SET issuers
   and recipients should have the appropriate legal agreements and user
   consent and/or terms of service in place.

   The propagation of subject identifiers can be perceived as personally
   identifiable information.  Where possible, SET issuers and recipients
   SHOULD devise approaches that prevent propagation -- for example, the
   passing of a salted hash value that requires the SET recipient to
   know the subject.

   In some cases, it may be possible for a SET recipient to correlate
   different events and thereby gain information about a subject that
   the SET issuer did not intend to share.  For example, a SET recipient
   might be able to use "iat" values or highly precise "toe" values to
   determine that two otherwise un-relatable events actually relate to
   the same real-world event.  The union of information from both events
   could allow a SET recipient to de-anonymize data or recognize that
   unrelated identifiers relate to the same individual.  SET issuers
   SHOULD take steps to minimize the chance of event correlation, when
   such correlation would constitute a privacy violation.  For instance,
   they could use approximate values for the "toe" claim or arbitrarily
   delay SET issuance, where such delay can be tolerated.

7.  IANA Considerations

7.1.  JSON Web Token Claims Registration

   This specification registers the "events", "toe", and "txn" claims in
   the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims]
   established by [RFC7519].

7.1.1.  Registry Contents

   o  Claim Name: "events"
   o  Claim Description: Security Events
   o  Change Controller: IESG
   o  Specification Document(s): Section 2.2 of [[ this specification ]]

   o  Claim Name: "toe"
   o  Claim Description: Time of Event
   o  Change Controller: IESG
   o  Specification Document(s): Section 2.2 of [[ this specification ]]

   o  Claim Name: "txn"
   o  Claim Description: Transaction Identifier
   o  Change Controller: IESG
   o  Specification Document(s): Section 2.2 of [[ this specification ]]

7.2.  Media Type Registration

7.2.1.  Registry Contents

   This section registers the "application/secevent+jwt" media type
   [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the
   manner described in [RFC6838], which can be used to indicate that the
   content is a SET.

   o  Type name: application
   o  Subtype name: secevent+jwt
   o  Required parameters: n/a
   o  Optional parameters: n/a
   o  Encoding considerations: 8bit; A SET is a JWT; JWT values are
      encoded as a series of base64url-encoded values (some of which may
      be the empty string) separated by period ('.') characters.
   o  Security considerations: See the Security Considerations section
      of [[ this specification ]]
   o  Interoperability considerations: n/a
   o  Published specification: Section 2.3 of [[ this specification ]]
   o  Applications that use this media type: TBD
   o  Fragment identifier considerations: n/a
   o  Additional information:

         Magic number(s): n/a
         File extension(s): n/a
         Macintosh file type code(s): n/a

   o  Person & email address to contact for further information:
      Michael B. Jones, mbj@microsoft.com
   o  Intended usage: COMMON
   o  Restrictions on usage: none
   o  Author: Michael B. Jones, mbj@microsoft.com
   o  Change controller: IESG
   o  Provisional registration?  No

8.  References

8.1.  Normative References

   [IANA.JWT.Claims]
              IANA, "JSON Web Token Claims",
              <http://www.iana.org/assignments/jwt>.

   [IANA.MediaTypes]
              IANA, "Media Types",
              <http://www.iana.org/assignments/media-types>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <https://www.rfc-editor.org/info/rfc6125>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <https://www.rfc-editor.org/info/rfc7525>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [I-D.ietf-oauth-jwt-bcp]
              Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
              Current Practices", draft-ietf-oauth-jwt-bcp-01 (work in
              progress), March 2018.

   [OpenID.BackChannel]
              Jones, M. and J. Bradley, "OpenID Connect Back-Channel
              Logout 1.0", January 2017, <http://openid.net/specs/
              openid-connect-backchannel-1_0.html>.

   [OpenID.Core]
              Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0", November 2014,
              <http://openid.net/specs/openid-connect-core-1_0.html>.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,
              <https://www.rfc-editor.org/info/rfc2046>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/info/rfc6838>.

   [RFC7009]  Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
              2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
              August 2013, <https://www.rfc-editor.org/info/rfc7009>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <https://www.rfc-editor.org/info/rfc7516>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/info/rfc7517>.

   [RFC7644]  Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
              and C. Mortimore, "System for Cross-domain Identity
              Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
              September 2015, <https://www.rfc-editor.org/info/rfc7644>.

   [RFC8055]  Holmberg, C. and Y. Jiang, "Session Initiation Protocol
              (SIP) Via Header Field Parameter to Indicate Received
              Realm", RFC 8055, DOI 10.17487/RFC8055, January 2017,
              <https://www.rfc-editor.org/info/rfc8055>.

   [RFC8225]  Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
              Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
              <https://www.rfc-editor.org/info/rfc8225>.

   [RISC]     OpenID Foundation, "OpenID Risk and Incident Sharing and
              Coordination (RISC) Working Group",
              <http://openid.net/wg/risc/>.

Appendix A.  Acknowledgments

   The editors would like to thank the members of the IETF SCIM working
   group, which began discussions of provisioning events starting with
   draft-hunt-scim-notify-00 in 2015.  The editors would like to thank
   the participants in the IETF id-event mailing list, the Security
   Events working group, and related working groups for their
   contributions to this specification.  The specification incorporates
   suggestions made by many people, including Annabelle Backman, John
   Bradley, Dick Hardt, Russ Housley, Benjamin Kaduk, Mark Lizar, Andrew
   Nash, Justin Richer, Nat Sakimura, Marius Scurtescu, and Yaron
   Sheffer.

Appendix B.  Change Log

   [[ to be removed by the RFC Editor before publication as an RFC ]]

   From the original draft-hunt-idevent-token:

   Draft 01 - PH - Renamed eventUris to events

   Draft 00 - PH - First Draft

   Draft 01 - PH - Fixed some alignment issues with JWT.  Remove event
   type attribute.

   Draft 02 - PH - Renamed to Security Events, removed questions,
   clarified examples and intro text, and added security and privacy
   section.

   Draft 03 - PH

      General edit corrections from Sarah Squire

      Changed "event" term to "SET"

      Corrected author organization for William Denniss to Google

      Changed definition of SET to be 2 parts, an envelope and 1 or more
      payloads.

      Clarified that the intent is to express a single event with
      optional extensions only.

   - mbj - Registered "events" claim, and proof-reading corrections.

   Draft 04 - PH -

   o  Re-added the "sub" claim with clarifications that any SET type may
      use it.

   o  Added additional clarification on the use of envelope vs. payload
      attributes

   o  Added security consideration for event timing.

   o  Switched use of "attribute" to "claim" for consistency.

   o  Revised examples to put "sub" claim back in the top level.

   o  Added clarification that SETs typically do not use "exp".

   o  Added security consideration for distinguishing Access Tokens and
      SETs.

   Draft 05 - PH - Fixed find/replace error that resulted in claim being
   spelled claimc

   Draft 06 - PH -

   o  Corrected typos

   o  New txn claim

   o  New security considerations Sequencing and Timing Issues

   Draft 07 -

   o  PH - Moved payload objects to be values of event URI attributes,
      per discussion.

   o  mbj - Applied terminology consistency and grammar cleanups.

   Draft 08 - PH -

   o  Added clarification to status of examples

   o  Changed from primary vs. extension to state that multiple events
      may be expressed, some of which may or may not be considered
      extensions of others (which is for the subscriber or profiling
      specifications to determine).

   o  Other editorial changes suggested by Yaron
   From draft-ietf-secevent-token:

   Draft 00 - PH - First WG Draft based on draft-hunt-idevent-token

   Draft 01 - PH - Changes as follows:

   o  Changed terminology away from pub-sub to transmitter/receiver
      based on WG feedback

   o  Cleaned up/removed some text about extensions (now only used as
      example)

   o  Clarify purpose of spec vs. future profiling specs that define
      actual events

   Draft 02 - Changes are as follows:

   o  mbj - Added the Requirements for SET Profiles section.

   o  mbj - Expanded the Security Considerations section to describe how
      to prevent confusion of SETs with ID Tokens, access tokens, and
      other kinds of JWTs.

   o  mbj - Registered the "application/secevent+jwt" media type and
      defined how to use it for explicit typing of SETs.

   o  mbj - Clarified the misleading statement that used to say that a
      SET conveys a single security event.

   o  mbj - Added a note explicitly acknowledging that some SET profiles
      may choose to convey event subject information in the event
      payload.

   o  PH - Corrected encoded claim example on page 10.

   o  mbj - Applied grammar corrections.

   Draft 03 - Changes are as follows:

   o  pjh - Corrected old "subscriber" to "Event Receiver".  Added
      clarification in definition that Event Receiver is the same as JWT
      recipient.

   o  pjh - Added definition for "toe" (and IANA registration).

   o  pjh - Removed "nbf" claim.

   o  pjh - Figure 3, moved "sub" to the events payload next to "iss".

   o  pjh - Clarified the use of "nonce" in contexts where substitution
      is possible.

   o  mbj - Addressed WGLC comments by Nat Sakimura.

   o  mbj - Addressed WGLC comments by Annabelle Backman.

   o  mbj - Addressed WGLC comments by Marius Scurtescu.

   Draft 04 - mbj - Changes were as follows:

   o  Clarified that all "events" values must represent aspects of the
      same state change that occurred to the subject -- not an
      aggregation of unrelated events about the subject.

   o  Removed ambiguities about the roles of multiple "events" values
      and the responsibilities of profiling specifications for defining
      how and when they are used.

   o  Corrected places where the term JWT was used when what was
      actually being discussed was the JWT Claims Set.

   o  Addressed terminology inconsistencies.  In particular,
      standardized on using the term "issuer" to align with JWT
      terminology and the "iss" claim.  Previously the term
      "transmitter" was sometimes used and "issuer" was sometimes used.
      Likewise, standardized on using the term "recipient" instead of
      "receiver" for the same reasons.

   o  Added a RISC event example, courtesy of Marius Scurtescu.

   o  Applied wording clarifications suggested by Annabelle Backman and
      Yaron Sheffer.

   o  Applied numerous grammar, syntax, and formatting corrections.

   Draft 05 - mbj - Changes were as follows:

   o  Simplified the definitions of the "iat" and "toe" claims in ways
      suggested by Annabelle Backman.

   o  Added privacy considerations text suggested by Annabelle Backman.

   o  Updated the RISC event example, courtesy of Marius Scurtescu.

   o  Reordered the claim definitions to place the required claims
      first.

   o  Changed to using the RFC 8174 boilerplate instead of the RFC 2119
      boilerplate.

   Draft 06 - mbj - Changes were as follows:

   o  Changed "when the event was issued" to "when the SET was issued"
      in the "iat" description, as suggested by Annabelle Backman.

   o  Applied editorial improvements that improve the consistency of the
      specification that were suggested by Annabelle Backman, Marius
      Scurtescu, and Yaron Sheffer.

   Draft 07 - PH - Text refinement to Section 3 proposed by Annabelle
   Backman post WGLC

   Draft 08 - mbj - Changes were as follows:

   o  Incorporated wording improvements resulting from Russ Housley's
      SecDir comments.

   o  Acknowledged individuals who made significant contributions.

   Draft 09 - pjh/mbj - Changes addressing AD review comments by
   Benjamin Kaduk

Authors' Addresses

   Phil Hunt (editor)
   Oracle Corporation

   Email: phil.hunt@yahoo.com

   Michael B. Jones
   Microsoft

   Email: mbj@microsoft.com
   URI:   http://self-issued.info/

   William Denniss
   Google

   Email: wdenniss@google.com
   Morteza Ansari
   Cisco

   Email: morteza.ansari@cisco.com
--Apple-Mail=_3C582A7B-6FD1-403B-A1B5-7FC78EFFAC36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 20, 2018, at 11:03 AM, Russ Housley <housley@vigilsec.com> wrote:

Reviewer: Russ Housley
Review result: Has = Issues

I reviewed this document as part of = the Security Directorate's ongoing
effort to review all = IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the = Security Area
Directors.  Document authors, document = editors, and WG chairs should
treat these comments just = like any other IETF Last Call comments.

Document: draft-ietf-secevent-token-09
Reviewer: = Russ Housley
Review Date: 2018-04-20
IETF LC = End Date: unknown
IESG Telechat date: 2018-05-10

Summary: Has Issues

Major Concerns

I do not = understand the first paragraph of Section 3.  I made this
comment on version -07, and some words were added, but I = still do
not understand this paragraph.  I think you = are trying to impose some
rules on future specifications = that use SET to define events.  Let me
ask a couple = of questions that may help.  I understand that a
profiling specification MUST specify the syntax and semantics = for a
collection of security event tokens, including the = claims and payloads
that are expected.  What MUST a = profiling specification include?  What
MUST a = profiling specification NOT include?


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4K= ZNA&m=3DhJFx-Z2ih18uUNCXosAjvygHqn2_K2mtNzqIej3Ah-c&s=3D28OWe42S0b= g8Y2eo3VVzACeSYnzgiyyeXLl7tTu9i1Y&e=3D

= --Apple-Mail=_3C582A7B-6FD1-403B-A1B5-7FC78EFFAC36-- --Apple-Mail=_F723C054-9F23-4EB7-8162-A734D2E06AFE-- From nobody Wed Apr 25 13:56:19 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 718B612D80E; Wed, 25 Apr 2018 13:56:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Montville To: Cc: ippm@ietf.org, ietf@ietf.org, draft-ietf-ippm-twamp-yang.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152468976242.23320.3891636367160271859@ietfa.amsl.com> Date: Wed, 25 Apr 2018 13:56:02 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ippm-twamp-yang-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 20:56:02 -0000 Reviewer: Adam Montville Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is: Ready; the Security Considerations cover in-transit protections well enough, and recommends controlling access to writable nodes. One suggestion I have is that the security considerations could do a better job drawing a straight line between "a number of nodes...which are writeable" and the "Examples of notes that are particularly vulnerable..." The example is simply, "...several timeout values put in the protocol to protect against sessions that are not active but are consuming resources." This would suggest that controlling access to writable timeout values would mitigate denial of service, which could be beneficial to state explicitly. Are all of the other writable nodes of the same character, or would some lead to, for example, privilege escalation? In other words, while doing so is probably not strictly necessary for the success of the draft, making the security issues as clear as possible for at least each category of writable node seems like a good idea to help those who may not otherwise be aware. From nobody Wed Apr 25 17:07:10 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814A212D962; Wed, 25 Apr 2018 17:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3ATjHpc4lN4; Wed, 25 Apr 2018 17:07:07 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1095E12D95E; Wed, 25 Apr 2018 17:07:04 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 932E928B0031; Wed, 25 Apr 2018 20:07:02 -0400 (EDT) Received: from [127.0.0.1] (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 5759D1F804E; Wed, 25 Apr 2018 20:07:02 -0400 (EDT) From: Russ Mundy Content-Type: text/plain; charset=us-ascii X-Mao-Original-Outgoing-Id: 546394021.267576-3785a9c40befb61fe9680f943570161c Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: Date: Wed, 25 Apr 2018 20:07:02 -0400 To: draft-ietf-ippm-2330-ipv6.all@ietf.org, iesg@ietf.org, secdir@ietf.org X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [secdir] SecDir Review of draft-ietf-ippm-2330-ipv6-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 00:07:08 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments.=20 The summary of the review is Ready. Russ Mundy From nobody Thu Apr 26 06:42:17 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B360B12422F; Thu, 26 Apr 2018 06:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDVbRSSPho1p; Thu, 26 Apr 2018 06:42:08 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EC91201F8; Thu, 26 Apr 2018 06:42:08 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3QDekx1027665; Thu, 26 Apr 2018 06:42:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=+8V5Rsp00TGVMae2xVb4FfORqn7Qj9FmDeDI9lrJSY0=; b=UddoJfM+2gaxEbhInroghB+JHqc3d74lrkubF+uwfljyEb84UL3oBGTiXTylj7swg4YM V3+DW/+qNIkfSJKjsR9yip9JGDGkMVhBGlQ3/JKcAprwnmrqxOQuT9EouDUI5f0HB3tD RfeX5jpsQYGCyvYnEUv4goPWfUYZy60K6Fy6pOKvHw4szQukdADtwJV7TNklUNpZzQb+ vfpmSitKXRxLQl+lux6sQ+E3iEPmL+BYnxqaz3lE/5ve8EDRDLH0U9X2p/vKhpenISGt TtlhLPguAnCb+/6hLSd3x1UmbGlBAsqEYtXHr8/3XI0sgLAFpXwDZEwye6xiF9P3IxCA Lw== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0087.outbound.protection.outlook.com [207.46.163.87]) by mx0a-00273201.pphosted.com with ESMTP id 2hkchhgahk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 26 Apr 2018 06:42:08 -0700 Received: from BN7PR05MB3923.namprd05.prod.outlook.com (52.132.216.10) by BN7PR05MB4579.namprd05.prod.outlook.com (52.135.249.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.715.13; Thu, 26 Apr 2018 13:42:05 +0000 Received: from BN7PR05MB3923.namprd05.prod.outlook.com ([fe80::6580:763:8d31:8cf]) by BN7PR05MB3923.namprd05.prod.outlook.com ([fe80::6580:763:8d31:8cf%13]) with mapi id 15.20.0715.014; Thu, 26 Apr 2018 13:42:05 +0000 From: Harish Sitaraman To: Hilarie Orman , "iesg@ietf.org" , "secdir@ietf.org" CC: "draft-ietf-teas-sr-rsvp-coexistence-rec.all@tools.ietf.org" Thread-Topic: Security review of draft-ietf-teas-sr-rsvp-coexistence-rec-02 Thread-Index: AQHT2O+MQ8Ax6vu5e0+8Qg7ez4a15KQSoYKA Date: Thu, 26 Apr 2018 13:42:05 +0000 Message-ID: <310E5D20-FB07-420A-A8FA-B93D7C486263@juniper.net> References: <201804202134.w3KLYlMY016971@rumpleteazer.rhmr.com> In-Reply-To: <201804202134.w3KLYlMY016971@rumpleteazer.rhmr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-originating-ip: [66.129.239.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7PR05MB4579; 7:XLhxkAnbvof22TQ5addo/Kjv8ez0VAiJKZs+n5cDuTdhR2gsWzXsmFyaCAf0gvcVlWhiTJLmJ5KDRydGej+4CfGSP8nmn+Uck2LU6J2rd5wVLXd4AUAQ0oHg8mRimVjTZqRPG1WI97LzRaM5jJPTX0TXSiIM/Zva9GgGG7QSurJCYlfRi4PZTbO4S5gorqym3QGPYQQjdxWUbagcq6x70tXDD5UsfFF3d25EyOgBusRIohi3nYfKxIENLb4ftguA x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN7PR05MB4579; x-ms-traffictypediagnostic: BN7PR05MB4579: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231232)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123564045)(201703131423095)(201703011903075)(201702281528075)(20161123555045)(201703061421075)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:BN7PR05MB4579; BCL:0; PCL:0; RULEID:; SRVR:BN7PR05MB4579; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7966004)(346002)(396003)(366004)(39860400002)(39380400002)(376002)(51444003)(51914003)(37854004)(189003)(199004)(97736004)(2906002)(53936002)(5660300001)(2900100001)(186003)(486006)(6246003)(4326008)(33656002)(3660700001)(36756003)(2616005)(15650500001)(6486002)(11346002)(6512007)(446003)(102836004)(83716003)(2201001)(58126008)(81166006)(26005)(5250100002)(76176011)(8676002)(82746002)(6506007)(508600001)(81156014)(305945005)(86362001)(476003)(8936002)(229853002)(59450400001)(3280700002)(68736007)(3846002)(6116002)(106356001)(99286004)(6436002)(7736002)(110136005)(316002)(2501003)(14454004)(105586002)(66066001)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4579; H:BN7PR05MB3923.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: KigUy+UOnlGV0siQwY/2iyH3rdwy4DkIGIxpqS6t7t1bKUCg6yKC4AdNK1v4KHmyyQhobYCUqr/0ylCHPq87ksf2T8l4RZC6zikBxl1pgZi+cNpdV9Iha7W+Ny2ACu037Cn0RiFRIuRWxBulMSf4QpIIN22efqLxICDmQDiJZej8+17sBG6g9SHrK6HMhB95 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: ecb9fd54-f767-4a28-a0c3-08d5ab7b7fa5 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: ecb9fd54-f767-4a28-a0c3-08d5ab7b7fa5 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2018 13:42:05.3056 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4579 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-26_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804260131 Archived-At: Subject: Re: [secdir] Security review of draft-ietf-teas-sr-rsvp-coexistence-rec-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 13:42:11 -0000 DQpIaSBIaWxhcmllLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIFdlJ3ZlIHBvc3RlZCBhIC0w MyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gTGV0IHVzIGtub3cgaWYgaXQgaGVscHMgd2l0aCB5b3Vy IGNvbW1lbnRzLiBTZWUgaW5saW5lIFtIU10uLi4NCg0K77u/T24gNC8yMC8xOCwgMjozNSBQTSwg IkhpbGFyaWUgT3JtYW4iIDxoaWxhcmllQHB1cnBsZXN0cmVhay5jb20+IHdyb3RlOg0KDQogICAg CQkJICBTZWN1cml0eSByZXZpZXcgb2YNCiAgICAgICBSZWNvbW1lbmRhdGlvbnMgZm9yIFJTVlAt VEUgYW5kIFNlZ21lbnQgUm91dGluZyBMU1AgY28tZXhpc3RlbmNlDQogICAgCSAgICAgIGRyYWZ0 LWlldGYtdGVhcy1zci1yc3ZwLWNvZXhpc3RlbmNlLXJlYy0wMg0KICAgIA0KICAgIERvIG5vdCBi ZSBhbGFybWVkLiAgSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUN CiAgICBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwg SUVURiBkb2N1bWVudHMNCiAgICBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBj b21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5DQogICAgZm9yIHRoZSBiZW5lZml0IG9mIHRo ZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kDQogICAgV0cg Y2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxh c3QgY2FsbA0KICAgIGNvbW1lbnRzLg0KICAgIA0KICAgIFdoZW4gdHdvIGluZGVwZW5kZW50IHBy b3RvY29scyBhcmUgdXNlZCB0byBtYW5hZ2UgYmFuZHdpZHRoIG9uIG9uZQ0KICAgIHNoYXJlZCBs aW5rLCB0aGUgcHJvYmxlbSBvZiBlZmZpY2llbnQgdXNlIG9mIHRoZSB0b3RhbCBiYW5kd2lkdGgN CiAgICB3aWxsIGRlcGVuZCBvbiBob3cgbXVjaCBpbmZvcm1hdGlvbiB0aGUgdHJhZmZpYyBlbmdp bmVlcmluZyBkYXRhYmFzZQ0KICAgIGhhcyBhYm91dCB0aGUgdXRpbGl6YXRpb24gYW5kIHJlc2Vy dmF0aW9ucyBoYW5kbGVkIGJ5IHRoZSB0d28NCiAgICBwcm90b2NvbHMuICBUaGlzIHNpdHVhdGlv biBvY2N1cnMgd2hlbiBSU1ZQLVRFIGFuZCBTZWdtZW50IFJvdXRpbmcNCiAgICBMU1AgYXJlIHVz ZWQgc2ltdWx0YW5lb3VzbHkuDQogICAgDQogICAgVGhlIGRyYWZ0IHJ1bGVzIG91dCBjZW50cmFs aXplZCBjb250cm9sbGVycyBmb3IgUlNWUC1URSBhcyBhbiBvcHRpb24uDQogICAgSXQgYWxzbyBu b3RlcyB0aGF0IHRoZSBjby1leGlzdGVuY2Ugb2YgdHdvIHByb3RvY29scyBtaWdodCBiZSBhDQog ICAgdGVtcG9yYXJ5IHNpdHVhdGlvbiBhcmlzaW5nIGR1cmluZyBhIHRyYW5zaXRpb24gZnJvbSBS U1ZQLVRFIHRvIFNSDQogICAgTFNQLiAgVGhpcyBzZWVtcyB0byBpbXBseSB0aGF0IHRoZSByZWNv bW1lbmRhdGlvbnMgYXJlIGEgc3RvcGdhcA0KICAgIG1lYXN1cmUuDQogICAgDQogICAgQWx0aG91 Z2ggdGhlcmUgaXMgYSBjbGFpbSBvZiAibm8gbmV3IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIiwg SSB0aGluaw0KICAgIHRoYXQgdGhlIHByb3Bvc2VkIHNvbHV0aW9uLCBvZiBnaXZpbmcgU1IgdHJh ZmZpYyBkZW1hbmRzIHRoZSBiZXN0DQogICAgcHJlZW1wdGlvbiBwcmlvcml0eSBpbiB0aGUgbmV0 d29yaywgY291bGQgYmUgYSBwcm9ibGVtIGluIHRlcm1zIG9mDQogICAgY292ZXJ0IGNoYW5uZWxz IGFuZCBkZW5pYWwgb2Ygc2VydmljZS4gIElmIHRoZSBhZGp1c3RtZW50cyBpbiB0aGUgVEVEDQog ICAgcmVzdWx0IGluIGFueSBvYnNlcnZhYmxlIGNoYW5nZSBpbiB0cmFmZmljIHBhdHRlcm5zLCB0 aGVuIGEgbWFsaWNpb3VzDQogICAgcGFydHkgbWlnaHQgYmUgYWJsZSB0byBpbmZlciB1c2FnZSBv biBhbiBTUiBjaGFubmVsIG9yIGV2ZW4gZGlzcnVwdA0KICAgIHRoZSBSU1ZQLVRFIGNoYW5uZWxz IGJ5IGRyaXZpbmcgdXAgZGVtYW5kIG9uIHRoZSBTUiBjaGFubmVsLg0KICAgIE1vcmVvdmVyLCBp dCBtaWdodCBiZSBwb3NzaWJsZSB0byBzZW5kIHRoZSB0cmFmZmljIG1hbmFnZW1lbnQNCiAgICBh bGdvcml0aG1zIGludG8gc29tZSBraW5kIG9mIHJlc29uYW5jZSBjcmlzaXMgYnkgaW5jcmVhc2lu ZyBhbmQNCiAgICBkaW1pbmlzaGluZyBkZW1hbmQgcmFwaWRseS4gIEFsdGhvdWdoIHRoZSBwcm9w b3NlZCBzb2x1dGlvbiBoYXMNCiAgICBhIGRhbXBpbmcgZmFjdG9yLCBJIHdvdWxkIGJlIGNvbmNl cm5lZCBhYm91dCBzeXN0ZW1zIG9wZXJhdGluZw0KICAgIGluIHBhcmFsbGVsIHRoYXQgbWlnaHQg ZXhoaWJpdCBzZWNvbmQgb3JkZXIgZWZmZWN0cy4NCiAgICANCiAgICBDb3VsZCB0aGUgZHJhZnQg YWRkcmVzcyB0aGUgc2VjdXJpdHkgYW5kIHN0YWJpbGl0eSBjb25jZXJucyBpbg0KICAgIHNvbWUg cmVhc3N1cmluZyB3YXk/ICBMaWtlLCAiZG9uJ3QgbGV0IHRoaXMgaGFwcGVuIj8NCg0KW0hTXSBF eHBhbmRlZCBvbiB0aGUgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi4NCiAgICANCiAg ICBJbiBzZWN0aW9uIDMuNSwgdGhpcyBzZW50ZW5jZSB0aHJldyBtZSBmb3IgYSBsb29wOg0KICAg ICAgIEhvd2V2ZXIsIGNoYW5naW5nIHRoZSBtYXhpbXVtIGJhbmR3aWR0aCBmb3IgdGhlIFRFIGxp bmsgd2lsbA0KICAgICAgIHByZXZlbnQgYW55IGNvbXB1dGUgZW5naW5lIGZvciBTUiBvciBSU1ZQ IHRvIGRlY2lwaGVyIHRoZSByZWFsDQogICAgICAgc3RhdGljIGJhbmR3aWR0aCBvZiB0aGUgVEUg bGluaw0KICAgIEFmdGVyIHJlcmVhZGluZyBpdCBzZXZlcmFsIHRpbWVzLCBJIHRoaW5rIHRoYXQg ImRlY2lwaGVyIiBoYXMgbm8NCiAgICBjcnlwdG9ncmFwaGljIHNpZ25pZmljYW5jZSBhbmQgc2hv dWxkIGJlIHJlcGxhY2VkIGJ5ICJkZXRlcm1pbmUiDQogICAgb3IgIm1lYXN1cmUiLCBhbmQgcmV3 cml0dGVuIGluIHRoZSBmb3JtICJ3aWxsIHByZXZlbnQgYW55IGNvbXB1dGUNCiAgICBlbmdpbmUg Li4uIGZyb20gZGV0ZXJtaW5pbmcgLi4uIi4NCg0KW0hTXSBDaGFuZ2VkIHRvIHRoZSByZWNvbW1l bmRlZCB0ZXh0Lg0KICAgIA0KSGFyaXNoDQogICAgDQoNCg== From nobody Thu Apr 26 13:53:33 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BF1120454; Thu, 26 Apr 2018 06:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524748848; bh=FMvZ5PpKwbg+YOt3ZUuVzGLgCXQ8BRwPrmqYpAllUqA=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=fmf01IUHL9sexlTzJvpOtClOZfMphEm5bLeaVVMOr1nh+LPzANJojGuLrI9dvGGim 3SjJLfnpgHB5+xOcyluplMIz7Huhkx8lOlov6FtruE/LA2FYQgHvsNbH3ELcKLpokI 1RL+lFVxX+o93IseKcOKVZuni7kf159RG+YROg+o= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Apr 26 06:20:48 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F07126CD6; Thu, 26 Apr 2018 06:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524748848; bh=FMvZ5PpKwbg+YOt3ZUuVzGLgCXQ8BRwPrmqYpAllUqA=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=fmf01IUHL9sexlTzJvpOtClOZfMphEm5bLeaVVMOr1nh+LPzANJojGuLrI9dvGGim 3SjJLfnpgHB5+xOcyluplMIz7Huhkx8lOlov6FtruE/LA2FYQgHvsNbH3ELcKLpokI 1RL+lFVxX+o93IseKcOKVZuni7kf159RG+YROg+o= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D0A124E15 for ; Thu, 26 Apr 2018 06:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cua_Z4dQwBfg for ; Thu, 26 Apr 2018 06:20:45 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E28B126C22 for ; Thu, 26 Apr 2018 06:20:43 -0700 (PDT) Received: from [42.185.126.92] (helo=[192.168.1.3]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1fBgpC-0000PF-6d for new-work@ietf.org; Thu, 26 Apr 2018 13:20:38 +0000 To: new-work@ietf.org From: Xueyuan Message-ID: Date: Thu, 26 Apr 2018 21:20:35 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 26 Apr 2018 13:53:32 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Devices and Sensors Working Group (until 2018-05-25) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 13:20:50 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgRGV2aWNl cyBhbmQgU2Vuc29ycyBXb3JraW5nIEdyb3VwOgogwqAgaHR0cHM6Ly93M2MuZ2l0aHViLmlvL2Rh cC1jaGFydGVyL0RldmljZUFQSUNoYXJ0ZXIuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0 IHRoZSBjb21tdW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJh ZnQgY2hhcnRlciBpcyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3 IHBlcmlvZC4KClczQyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDIwMTgtMDUtMjUg b24gdGhlCnByb3Bvc2VkIGNoYXJ0ZXIuIFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvCnB1YmxpYy1u ZXctd29ya0B3My5vcmcsIHdoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cDovL2xp c3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBj b21tZW50cyBzZW50IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRl ZSBSZXByZXNlbnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29t bWVudHMuIElmIHlvdSB3b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0 ZQp5b3VyIGNvbW1lbnRzIHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRp dmUuIEZvcgpleGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlh IHRoaXMgbGlzdCBhbmQKaGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2 ZSByZWZlciB0byBpdCBmcm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KCklm IHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZvcm1hdGlv biwgcGxlYXNlCmNvbnRhY3QgU2FtdWVsIFdlaWxlciwgVzNDIFByaXZhY3kgYW5kIFNlY3VyaXR5 IFN0cmF0ZWdpc3QgPHdlaWxlckB3My5vcmc+LgoKVGhhbmsgeW91LAoKWHVleXVhbiBKaWEsIFcz QyBNYXJrZXRpbmcgJiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMub3JnL0NvbnNv cnRpdW0vTWVtYmVyL0xpc3QKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Thu Apr 26 14:45:32 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE5A12D7EA; Thu, 26 Apr 2018 14:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFhaYExhzLzH; Thu, 26 Apr 2018 14:45:21 -0700 (PDT) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF5412AF83; Thu, 26 Apr 2018 14:45:21 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1fBoha-00047Z-DH; Thu, 26 Apr 2018 15:45:18 -0600 Received: from mta1.zcs.xmission.com ([166.70.13.65]) by in01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1fBohK-0002eq-Vj; Thu, 26 Apr 2018 15:45:18 -0600 Received: from localhost (localhost [127.0.0.1]) by mta1.zcs.xmission.com (Postfix) with ESMTP id AE54A1C41F6; Thu, 26 Apr 2018 15:45:02 -0600 (MDT) Received: from mta1.zcs.xmission.com ([127.0.0.1]) by localhost (mta1.zcs.xmission.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9rGNOClhio4g; Thu, 26 Apr 2018 15:45:02 -0600 (MDT) Received: from zms04.zcs.xmission.com (zms04.zcs.xmission.com [166.70.13.74]) by mta1.zcs.xmission.com (Postfix) with ESMTP id 820AB1C41F0; Thu, 26 Apr 2018 15:45:02 -0600 (MDT) Date: Thu, 26 Apr 2018 15:45:02 -0600 (MDT) From: Hilarie Orman To: Harish Sitaraman Cc: The IESG , secdir , draft-ietf-teas-sr-rsvp-coexistence-rec all Message-ID: <109711878.11368458.1524779102310.JavaMail.zimbra@purplestreak.com> In-Reply-To: <310E5D20-FB07-420A-A8FA-B93D7C486263@juniper.net> References: <201804202134.w3KLYlMY016971@rumpleteazer.rhmr.com> <310E5D20-FB07-420A-A8FA-B93D7C486263@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [72.250.219.84] X-Mailer: Zimbra 8.7.4_GA_1730 (ZimbraWebClient - FF59 (Linux)/8.7.4_GA_1730) Thread-Topic: Security review of draft-ietf-teas-sr-rsvp-coexistence-rec-02 Thread-Index: AQHT2O+MQ8Ax6vu5e0+8Qg7ez4a15KQSoYKAwR1r6wg= X-XM-SPF: eid=1fBohK-0002eq-Vj; ; ; mid=<109711878.11368458.1524779102310.JavaMail.zimbra@purplestreak.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=166.70.13.65; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-SA-Exim-Connect-IP: 166.70.13.65 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *****;Harish Sitaraman X-Spam-Relay-Country: US X-Spam-Timing: total 15037 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.3 (0.0%), b_tie_ro: 1.60 (0.0%), parse: 0.91 (0.0%), extract_message_metadata: 19 (0.1%), get_uri_detail_list: 2.5 (0.0%), tests_pri_-1000: 2.8 (0.0%), tests_pri_-950: 0.90 (0.0%), tests_pri_-900: 0.95 (0.0%), tests_pri_-400: 32 (0.2%), check_bayes: 31 (0.2%), b_tokenize: 9 (0.1%), b_tok_get_all: 14 (0.1%), b_comp_prob: 3.4 (0.0%), b_tok_touch_all: 3.2 (0.0%), b_finish: 0.52 (0.0%), tests_pri_0: 411 (2.7%), check_dkim_signature: 1.04 (0.0%), check_dkim_adsp: 26 (0.2%), tests_pri_500: 14559 (96.8%), poll_dns_idle: 14546 (96.7%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: Re: [secdir] Security review of draft-ietf-teas-sr-rsvp-coexistence-rec-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 21:45:24 -0000 You have addressed each protocol separately, not the combination. However, the issues of denial-of-service and=20 covert channels on shared infrastructure do not seem to be=20 part of any previous security considerations, so I suppose=20 it is unreasonable to expect this draft to do so. The=20 situation is lamentable, but the draft is READY from my=20 point of view. Hilarie ----- Original Message ----- From: "Harish Sitaraman" To: "Hilarie Orman" , "The IESG" ,= "secdir" Cc: "draft-ietf-teas-sr-rsvp-coexistence-rec all" Sent: Thursday, April 26, 2018 7:42:05 AM Subject: Re: Security review of draft-ietf-teas-sr-rsvp-coexistence-rec-02 Hi Hilarie, Thanks for the review. We've posted a -03 version of the draft. Let us know= if it helps with your comments. See inline [HS]... =EF=BB=BFOn 4/20/18, 2:35 PM, "Hilarie Orman" wr= ote: =09=09=09 Security review of Recommendations for RSVP-TE and Segment Routing LSP co-existence =09 draft-ietf-teas-sr-rsvp-coexistence-rec-02 =20 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. =20 When two independent protocols are used to manage bandwidth on one shared link, the problem of efficient use of the total bandwidth will depend on how much information the traffic engineering database has about the utilization and reservations handled by the two protocols. This situation occurs when RSVP-TE and Segment Routing LSP are used simultaneously. =20 The draft rules out centralized controllers for RSVP-TE as an option. It also notes that the co-existence of two protocols might be a temporary situation arising during a transition from RSVP-TE to SR LSP. This seems to imply that the recommendations are a stopgap measure. =20 Although there is a claim of "no new security considerations", I think that the proposed solution, of giving SR traffic demands the best preemption priority in the network, could be a problem in terms of covert channels and denial of service. If the adjustments in the TED result in any observable change in traffic patterns, then a malicious party might be able to infer usage on an SR channel or even disrupt the RSVP-TE channels by driving up demand on the SR channel. Moreover, it might be possible to send the traffic management algorithms into some kind of resonance crisis by increasing and diminishing demand rapidly. Although the proposed solution has a damping factor, I would be concerned about systems operating in parallel that might exhibit second order effects. =20 Could the draft address the security and stability concerns in some reassuring way? Like, "don't let this happen"? [HS] Expanded on the Security considerations section. =20 In section 3.5, this sentence threw me for a loop: However, changing the maximum bandwidth for the TE link will prevent any compute engine for SR or RSVP to decipher the real static bandwidth of the TE link After rereading it several times, I think that "decipher" has no cryptographic significance and should be replaced by "determine" or "measure", and rewritten in the form "will prevent any compute engine ... from determining ...". [HS] Changed to the recommended text. =20 Harish From nobody Thu Apr 26 16:45:43 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0805C12D872 for ; Thu, 26 Apr 2018 16:45:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <152478634302.6047.3235373689931315934.idtracker@ietfa.amsl.com> Date: Thu, 26 Apr 2018 16:45:43 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 23:45:43 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-05-10 Reviewer LC end Draft John Bradley 2018-04-18 draft-ietf-acme-acme-12 Tobias Gondrom 2018-03-12 draft-ietf-tokbind-https-13 Leif Johansson R2018-02-26 draft-ietf-homenet-babel-profile-06 Barry Leiba 2018-04-10 draft-ietf-bess-evpn-prefix-advertisement-10 For telechat 2018-05-24 Reviewer LC end Draft Catherine Meadows 2018-04-30 draft-ietf-teas-actn-framework-13 Yoav Nir 2018-04-24 draft-ietf-idr-bgp-gr-notification-15 Radia Perlman 2018-04-20 draft-ietf-ccamp-microwave-framework-05 Tina Tsou 2018-02-26 draft-ietf-softwire-dslite-yang-15 Last calls: Reviewer LC end Draft Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Daniel Migault 2018-04-27 draft-ietf-lamps-rfc5751-bis-07 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-12 Sandra Murphy 2018-04-24 draft-ietf-mmusic-sdp-simulcast-12 Magnus Nystrom 2018-04-23 draft-ietf-httpbis-replay-02 Vincent Roca 2018-05-21 draft-hakala-urn-nbn-rfc3188bis-00 Kyle Rose 2018-05-10 draft-ietf-extra-imap-status-size-01 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Ólafur Guðmundsson 2018-01-09 draft-ietf-opsawg-nat-yang-09 Dan Harkins 2018-05-31 draft-ietf-dtn-bpsec-06 Next in the reviewer rotation: Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Robert Sparks Takeshi Takahashi Tina Tsou Sean Turner From nobody Fri Apr 27 12:24:31 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E568312DA15; Fri, 27 Apr 2018 12:24:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault To: Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-rfc5751-bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152485706488.6011.12980717250490137013@ietfa.amsl.com> Date: Fri, 27 Apr 2018 12:24:24 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lamps-rfc5751-bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 19:24:31 -0000 Reviewer: Daniel Migault Review result: Has Nits Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Has Minor Nits Please find my comments while reading the draft. Yours, Daniel 1. Introduction As a supplementary service, S/MIME provides for message compression. maybe : As a supplementary service, S/MIME provides message compression. 1.3. Conventions Used in This Document The term RSA in this document almost always refers to the PKCS#1 v1.5 RSA signature or encryption algorithms even when not qualified as such. I am not sure format would not be more appropriated than algorithm, so maybe: The term RSA in this document almost always refers to the PKCS#1 v1.5 RSA signature or encryption *format* even when not qualified as such. 2.3. KeyEncryptionAlgorithmIdentifier When ECDH ephemeral-static is used, a key wrap algorithm is also specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The underlying encryption functions for the key wrap and content encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes for the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm with AES-128 content encryption algorithm). I understand the recommendation for a sending agent, but it seems that additional text should be provided in order to describe the behavior of the receiver. I am wondering if the receiver is expected to reject the message or whether it should assume the associated protection is the least of the two. Maybe specifying this is only for sending agent may also clarify this. 2.4.4. AuthEnvelopedData Content Type This content type does not provide authentication or non-repudiation. is a really helpful clarification ;-) Maybe it could be helpful to use the same formulation for section 2.4.2. SignedData Content Type by replacing: Applying a signature to a message provides authentication, message integrity, and non-repudiation of origin. This content type provides provides authentication, message integrity, and non-repudiation of origin. A sender signs the message with its own private key and shares public part of it with the recipient to validate the signature. 2.5. Attributes and the SignerInfo Type It would probably ease the reading and clarifying the purpose of the SignerInfo's attribute. Typically, some of them might necessary to validate the received message, while others are informational in prevision of a response. This is clarified later in the document but could be introduced here. I also believe that would be good to also include that there is a bootstrapping issue that is solved by the compliance of the implementations in supporting the recommended algorithms. A reference to section 2.7 may be useful as this section clarifies how the sending agent uses these information - at least for the encryption. 2.5.1. Signing Time Attribute The message originator has not been specified before, it may be good to clarify how it differs from the sender. It may also be good to specify how this value is being used - against replay attacks. section 2.7.1 provides some indications of the expected usage of the signing time attribute but it seems more associated to the capabilities. 2.5.2. SMIME Capabilities Attribute A client does not have to list every capability it supports, and need not list all its capabilities so that the capabilities list doesn't get too long. It might be worth providing a recommendation on what too long means, especially as a resulting list of capabilities is (expected) to be relatively short compared to the message itself - but I might be wrong. My reading of this attribute - and again I might be wrong - is that it would be useless if implementations would follow the cryptographic recommendations. It is mostly useful to have non updated senders to received responses from up-to-date responders. In addition, this information is likely cached and as such may not be unnecessarily be repeated. Wouldn't a MAY be more appropriated ? Note also that while we have some cryptographic recommendations for RSA, I would have expected a table summarizing the cryptographic recommendations with other algorithms than RSA. 2.5.3. Encryption Key Preference Attribute This attribute is designed to enhance behavior for interoperating with those clients that use separate keys for encryption and signing. Maybe that would be good to position this attribute versus the keyusage when certificate are used to split the usage of each keys. I am wondering if a recommendation could be state on whether one or both means should be used and if one overwrite the other. A preference may still be useful to indicate a preference when multiple keys for a given role are available. Is key management a relevant usage for preference ? I understand that Signing Time is being used to update the preferred keys as one way to performed key roll over. 3.1. Preparing the MIME Entity for Signing, Enveloping, or Compressing A MIME entity can be a sub- part, sub-parts of a message, or the whole message with all its sub- parts. I am wondering if "a subpart, many subparts or ..." would not be clearer. I understand that "message" in the first paragraph is used as the MIME message and in other words, the message is not designating the mail. I am reading message as MIME multi-part message and the MIME entities as a subset of MIME headers and parts of MIME multi-part message. Similarly MIME body would be the MIME multi-part message. Is that correct ? I believe the terminology paragraph could be clarified. It is RECOMMENDED that a distinction be made between the location of the header. I believe the purpose is to make a distinction between "protected" and 'unprotected' to the end user. I would thus keep this distinction even though this translates into 'inner' / 'outer'. 3.3. Creating an Enveloped-Only Message A sample message would be: Content-Type: application/pkcs7-mime; name=smime.p7m; smime-type=enveloped-data Shouldn't we use an OID instead of data for the example ? 3.4. Creating an Authenticated Enveloped-Only Message I believe the word "proof" is missing. It is important to note that sending authenticated enveloped messages does not provide for origination when using S/MIME. Maybe we should specify that this is especially true when multiple recipients are involved. 3.5.3. Signing Using the multipart/signed Format The first part contains the MIME entity that is signed; the second part contains the "detached signature" CMS SignedData object in which the encapContentInfo eContent field is absent. I believe it would be good to specify parts are ordered as this is not always the case of parts. What is unclear to me is why the second part is separated by a boundary usually used to separate parts. It seems boundary can also be used as boundary inside a part which seems to make part parsing harder. 3.5.3.2. Creating a multipart/signed Message Algorithm Value Used MD5 md5 SHA-1 sha-1 SHA-224 sha-224 SHA-256 sha-256 SHA-384 sha-384 SHA-512 sha-512 Any other (defined separately in algorithm profile or "unknown" if not defined) Should we have any recommendations on the hash algorithm to be used by sender / receivers ? Is that possible to deprecate MD5, SHA-1 and SHA-224 for senders ? 3.7. Multiple Operations Would it be recommended to have signed clear text than encrypted and then signed encrypted ? This seems to address all security concerns. 3.9. Registration Requests Should we mention DANE rfc8162 as a way to register you public key ? 4. Certificate Processing EdDSA Signatures recommendations for curve25519 and curve448 seems to be missing in the key pair generating , signature section. Are there any reasons not to consider these curves ? May be useful to have the following references: [1] https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ [2] https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ 6. Security Considerations I am wondering if any considerations should be provided for data at rest. Does the email needs to be archived encrypted or not and whether S/MIME can be used to store encrypted content. I believe that email should not be stored encrypted and as such S/MIME is only intended to protect mails in transit.... but I might be wrong. As a general comment I would have like a table that summarizes or explicitly mention what crypto is recommended for encrypting / signing. RSA is being discussed, but ECDSA EdDSA, ECDH, hash... are not. I believe such tables should be updated regularly to deprecate and introduce new algorithms while leaving S/MIME unchanged. There are a lot of double space in the text. From nobody Sat Apr 28 15:24:00 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F41C0127871; Sat, 28 Apr 2018 15:23:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir To: Cc: idr@ietf.org, ietf@ietf.org, draft-ietf-idr-bgp-gr-notification.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152495422193.32590.4825231334524243779@ietfa.amsl.com> Date: Sat, 28 Apr 2018 15:23:41 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-idr-bgp-gr-notification-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 22:23:42 -0000 Reviewer: Yoav Nir Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document extends the BGP Graceful Restart feature from RFC 4724 to also cover Notification messages. It does not make significant changes to the security properties of the original RFC. The one concern I had while reading the draft was in section 4.1 where when the extension is active, stale routes are not deleted, so an attacker can use repeated resets (the BGP connection is just TCP) to prevent stale route deletion. As the security considerations section says, this is mitigating by elevating the stale timer (after which stale routes are deleted) from MAY to MUST in that case. In summary, the document is well-written and deals with the security issues adequately. From nobody Sun Apr 29 12:37:47 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBFE126D45; Sun, 29 Apr 2018 12:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRCvFMFOpxnZ; Sun, 29 Apr 2018 12:37:29 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7E8126BF6; Sun, 29 Apr 2018 12:37:29 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id v63so5127958pfk.8; Sun, 29 Apr 2018 12:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=uDpEeHGQeBo1fgHaY9Upxo91jNTBzuSfv8NS3wIKPL0=; b=BgzxarL7s7+cr5GXxkTHPlhrUSSI4FfYsxAVypy5dhHncaagtFOguy17lyvUO7rGBA PctnSQL7Kxy4BdB+RjrIEpIruucbs8bVsrclYnubeDQy2k3o0Z3VZRZ5VsFN8zwYnVTQ EYrr1/5nzqJHjg7czF4LGF7ijWlVK9G5Y+/czzS4nRenl175IJZ3ozZ5u0oUhTOyYRB+ 4CBRoKqQPVqPMR3+v0akRUhKHsn40Z6pdHSaTOTHrgPUndb6zYFdoKd6s1SgOairrJrV dV4OG3HyuHYjtzUpv1FAiR6iBo97F1672stMIJVornTGDtClZkUlix2A7C8xLiaSIa0O v0wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=uDpEeHGQeBo1fgHaY9Upxo91jNTBzuSfv8NS3wIKPL0=; b=RlmHJjNQ+WBW0lSQU7v/Nz9TbXIXBt7zi6tRBUCttomw4kro+Jjxpwx5WZTrKwe5Cn DVQWzG35WQYOEIfTUoNAZpVKimv78YbSR+K1j3+BEDYt8NN2tKiP91IZgCuOpMEjI0VP 4rNQSTtutReEXQrjOhAFsMhuxGXTu/9IWCrgs6lxc9elmiP3U3u8PXpaZamWs7gq+w3s 1miGoc54BTFdu5db6B4S16digBuNbfklhQriuiYYztUF8NYwXcMb15WRCerrtDDPvY+5 rEaocE0HybWyO+TncmL9dXWvrZqfdxMtRqjpdr8hwCd3gIZmOqfkTWPgdWNl+nXDE6la NUKw== X-Gm-Message-State: ALQs6tA8yOIUP59Zmobd3u+tW3hnzmrx/ilrNV/dx+gQGhWynE4ARV7F mU6pYKRKMNhW2r118UIYg4s= X-Google-Smtp-Source: AB8JxZqpyTk1jh2mVHUfnfYR+628QNcSONvqjD0/9zrTjBXFqtvQtmTsHTqlLIpvJKlOob9Fflup7w== X-Received: by 10.98.88.65 with SMTP id m62mr1365925pfb.116.1525030649176; Sun, 29 Apr 2018 12:37:29 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:91cb:6619:9683:6f0? ([2601:647:4700:1280:91cb:6619:9683:6f0]) by smtp.gmail.com with ESMTPSA id a23sm10769992pfi.176.2018.04.29.12.37.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Apr 2018 12:37:28 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7F0C69C0-A784-4D0F-A8DB-42222BAB00F3" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sun, 29 Apr 2018 12:37:27 -0700 In-Reply-To: <152468976242.23320.3891636367160271859@ietfa.amsl.com> Cc: secdir@ietf.org, ippm@ietf.org, ietf@ietf.org, draft-ietf-ippm-twamp-yang.all@ietf.org To: Adam Montville References: <152468976242.23320.3891636367160271859@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ippm-twamp-yang-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 19:37:32 -0000 --Apple-Mail=_7F0C69C0-A784-4D0F-A8DB-42222BAB00F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Adam, See comments below. > On Apr 25, 2018, at 1:56 PM, Adam Montville = wrote: >=20 > Reviewer: Adam Montville > Review result: Ready >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These > comments were written primarily for the benefit of the security area = directors. > Document editors and WG chairs should treat these comments just like = any other > last call comments. >=20 > The summary of the review is: Ready; the Security Considerations cover > in-transit protections well enough, and recommends controlling access = to > writable nodes. >=20 > One suggestion I have is that the security considerations could do a = better job > drawing a straight line between "a number of nodes...which are = writeable" and > the "Examples of notes that are particularly vulnerable..." The = example is > simply, "...several timeout values put in the protocol to protect = against > sessions that are not active but are consuming resources." This would = suggest > that controlling access to writable timeout values would mitigate = denial of > service, which could be beneficial to state explicitly. How about this? OLD: Examples of nodes that are particularly vulnerable include several timeout values put in the protocol to protect against sessions that are not active but are consuming resources. NEW: Examples of nodes that are particularly vulnerable include several timeout values put in the protocol to protect against sessions that are not active but are consuming resources. Limiting access to these nodes will limit the ability to launch an attack in network=20 environments. > Are all of the other > writable nodes of the same character, or would some lead to, for = example, > privilege escalation? In other words, while doing so is probably not = strictly > necessary for the success of the draft, making the security issues as = clear as > possible for at least each category of writable node seems like a good = idea to > help those who may not otherwise be aware. Writing to other writable nodes is probably not as harmful as the = timeout value. So while we consider all writeable nodes as vulnerable, = we consider timeout value particularly vulnerable, for the reasons = stated above. Cheers. >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_7F0C69C0-A784-4D0F-A8DB-42222BAB00F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Adam,

See = comments below.

On Apr 25, 2018, at 1:56 PM, = Adam Montville <adam.w.montville@gmail.com> wrote:

Reviewer: Adam Montville
Review result: = Ready

I have reviewed this document as part = of the security directorate's ongoing
effort to review all = IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the = security area directors.
Document editors and WG chairs = should treat these comments just like any other
last call = comments.

The summary of the review is: = Ready; the Security Considerations cover
in-transit = protections well enough, and recommends controlling access to
writable nodes.

One suggestion I = have is that the security considerations could do a better job
drawing a straight line between "a number of nodes...which = are writeable" and
the "Examples of notes that are = particularly vulnerable..." The example is
simply, = "...several timeout values put in the protocol to protect against
sessions that are not active but are consuming resources." = This would suggest
that controlling access to writable = timeout values would mitigate denial of
service, which = could be beneficial to state explicitly. =

How about = this?

OLD:
   Examples of nodes that are particularly =
vulnerable include several
   timeout values put in the protocol to protect against sessions that
   are not active but are consuming resources.


NEW:
   Examples of nodes that are particularly =
vulnerable include several
   timeout values put in the protocol to protect against sessions that
   are not active but are consuming resources. Limiting access to =
these
   nodes will =
limit the ability to launch an attack in network 
   environments.


Are all of the other
writable nodes of the same character, or would some lead to, = for example,
privilege escalation? In other words, while = doing so is probably not strictly
necessary for the = success of the draft, making the security issues as clear as
possible for at least each category of writable node seems = like a good idea to
help those who may not otherwise be = aware.

Writing to other writable nodes is probably = not as harmful as the timeout value. So while we consider all writeable = nodes as vulnerable, we consider timeout value particularly vulnerable, = for the reasons stated above.

Cheers.



Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_7F0C69C0-A784-4D0F-A8DB-42222BAB00F3-- From nobody Sun Apr 29 15:20:09 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651A812D574; Sun, 29 Apr 2018 15:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMuY4zskca2A; Sun, 29 Apr 2018 15:19:52 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0122.outbound.protection.outlook.com [104.47.36.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2591C127522; Sun, 29 Apr 2018 15:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u3UQ2TsAEQ1vTirLrsStyyFHCqzsaZniWGN/MbTbg3o=; b=bpqLpi7SRzYFeBfL4WRzGZuebOJ0o50OlyWr/5ykiIvhvOSIAYYo2GHAOhdLlL0GEetVnTD+p1hbx/4mJnjyUFcEssYdkDjlMCbBngY+cudWASCvoNHCYVQXLPP9HDRe+6sD3Ly7mOfVLKa3fft+EquDO+rkB/8160vRNXo4n9k= Received: from MW2PR00MB0300.namprd00.prod.outlook.com (2603:10b6:302:8::31) by MW2PR00MB0444.namprd00.prod.outlook.com (2603:10b6:302:b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.761.0; Sun, 29 Apr 2018 22:19:41 +0000 Received: from MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::6d59:ca3c:a1a0:6fc1]) by MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::6d59:ca3c:a1a0:6fc1%4]) with mapi id 15.20.0764.000; Sun, 29 Apr 2018 22:19:41 +0000 From: Mike Jones To: Russ Housley CC: Phil Hunt , "draft-ietf-secevent-token.all@ietf.org" , "ietf@ietf.org" , ID Events Mailing List , "secdir@ietf.org" Thread-Topic: [Id-event] Secdir last call review of draft-ietf-secevent-token-09 Thread-Index: AQHT2NHtvc95Fiwi1UCrOyZVUllp6qQQeq+AgAfjstA= Date: Sun, 29 Apr 2018 22:19:40 +0000 Message-ID: References: <152424742315.3484.7625515486296411114@ietfa.amsl.com> <2F2D2F99-8116-40EE-8245-D7C5F8793BC0@oracle.com> In-Reply-To: <2F2D2F99-8116-40EE-8245-D7C5F8793BC0@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0444; 7:zQy+TlIsFTykOHWVTvYWD307DR94FO1+5uIilpSMKuYJ+EIasStGenetFjNatVgRIpEUytRPI032IP1KfplkPO1U8IORc9XapWW8em+o6zNlDV1CrY4RBnjGvEW0MmZjUeRQLoZWLDH0PM6rNlf5bKIDHvlsCtSqY8ALGLmpKsMWl/O3PPT5rCjLM04V4136L2N7mvyE7zi/3EwIyt397C9++NVTWefO+op1ZQ1EK7NlKSkb/PvYlgh0I8wzoZpZ; 20:ZUggpi+W4O9QGbTdCFd3u+tTMw5h4m+r40i7RAEXT0IPRhmu7ZhOJ05RfZkA5OR4oNBCLeiGkhGWNAwd5Xi0Zc45cPWyD2WxpMCtCe3zl/id0Du0Lyz7RATyPBPk0PbaArbw8w4Ha/KLDO6W/pl4c0xBQCoiSc+RyPftBwnNZdY= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7193020); SRVR:MW2PR00MB0444; x-ms-traffictypediagnostic: MW2PR00MB0444: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(89211679590171)(192374486261705)(21748063052155)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(3231254)(2018427008)(944501410)(52105095)(93006095)(93001095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MW2PR00MB0444; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0444; x-forefront-prvs: 0657D528EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39380400002)(346002)(39860400002)(366004)(377424004)(189003)(199004)(7736002)(74316002)(10290500003)(76176011)(81156014)(14454004)(52396003)(7696005)(9326002)(19609705001)(105586002)(9686003)(236005)(99286004)(81166006)(8936002)(26005)(86362001)(59450400001)(102836004)(97736004)(229853002)(33656002)(68736007)(6506007)(575784001)(478600001)(53546011)(6436002)(8676002)(966005)(186003)(5660300001)(606006)(72206003)(53386004)(446003)(4326008)(11346002)(316002)(6916009)(476003)(486006)(6246003)(5250100002)(54906003)(22452003)(3660700001)(5890100001)(25786009)(10090500001)(2900100001)(8990500004)(1680700002)(53936002)(3280700002)(6116002)(790700001)(3846002)(86612001)(106356001)(55016002)(66066001)(2906002)(6306002)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0444; H:MW2PR00MB0300.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: cSgZHQRDlnbPzPtN5moTdbjOYEF6Q2m474MrgO63/sVOpd0nt3ovf2EBUigA8mLvf+rVYOGI84WxOzhOSGDUV4TVp7ly1X2zNyavV1xlpd2ftCwUrjgY6sx7k/1zhZV+fUcWtVQXPysMiF9VcQT848amifL5H0v2tQ6kFoIO0byh7DnYCkz/4L3Ta21JkMt0 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR00MB03008E6BC62F553A785D9D5DF5830MW2PR00MB0300namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 2ef8d77f-a376-42aa-0d2a-08d5ae1f4d89 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ef8d77f-a376-42aa-0d2a-08d5ae1f4d89 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2018 22:19:41.0339 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0444 Archived-At: Subject: Re: [secdir] [Id-event] Secdir last call review of draft-ietf-secevent-token-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2018 22:19:57 -0000 --_000_MW2PR00MB03008E6BC62F553A785D9D5DF5830MW2PR00MB0300namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUnVzcywNCg0KSSB3YW50ZWQgdG8gY2hlY2sgYmFjayBpbi4gIEFyZSB5b3UgZ29vZCB3aXRo IHRoZXNlIGNoYW5nZXMgdG8gYWRkcmVzcyB5b3VyIGNvbW1lbnQgb3IgZG8gd2FudCB0byBzdWdn ZXN0IHRoYXQgd2UgdGFrZSBhIGRpZmZlcmVudCBkaXJlY3Rpb24/DQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MsDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQpGcm9tOiBJZC1ldmVudCA8aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9m IFBoaWwgSHVudA0KU2VudDogVHVlc2RheSwgQXByaWwgMjQsIDIwMTggMjo1MCBQTQ0KVG86IFJ1 c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+DQpDYzogZHJhZnQtaWV0Zi1zZWNldmVu dC10b2tlbi5hbGxAaWV0Zi5vcmc7IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT47IGlldGZAaWV0Zi5vcmc7IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGll dGYub3JnPjsgc2VjZGlyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBTZWNkaXIg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXNlY2V2ZW50LXRva2VuLTA5DQoNClJ1c3Ms DQoNCkhlcmUgYXJlIHByb3Bvc2VkIGNoYW5nZXMgdG8gYWRkcmVzcyB5b3VyIHF1ZXN0aW9ucyBh Ym91dCBTZWN0aW9uIDMuICBZb3XigJlyZSByaWdodCB0aGF0IHRoaXMgc2VjdGlvbiBpcyBwbGFj aW5nIHJlcXVpcmVtZW50cyBvbiBwcm9maWxpbmcgc3BlY2lmaWNhdGlvbnMuICBUaGUgY2hhbmdl cyBtYWRlIGFyZSBpbnRlbmRlZCB0byBtYWtlIHRoaXMgbW9yZSBleHBsaWNpdC4gIFBsZWFzZSBs ZXQgdXMga25vdyBpZiB0aGUgdXBkYXRlZCB0ZXh0IHdvcmtzIGZvciB5b3UsIGFuZCBpZiBzbywg d2XigJlsbCBwdWJsaXNoIGFuIHVwZGF0ZWQgZHJhZnQgdXNpbmcgaXQuDQoNClBsZWFzZSBzZWUg dGhlIHdkaWZmIHRleHQgZm9yIHNlY3Rpb24gMyBiZWxvdyAoYWxzbyBhdHRhY2hlZCkuDQoNClRo YW5rcywNCg0KUGhpbCAmIE1pa2UNCg0K4oCUd2RpZmYgZm9yIHNlYyAzLS0NCg0KMy4gIFJlcXVp cmVtZW50cyBmb3IgU0VUIFByb2ZpbGVzDQoNCg0KDQogICBQcm9maWxpbmcgc3BlY2lmaWNhdGlv bnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZSBhY3R1YWwgU0VUcyB0bw0KDQogICBiZSB1 c2VkIGluIHBhcnRpY3VsYXIgdXNlIGNhc2VzLiAgVGhlc2UgcHJvZmlsaW5nIHNwZWNpZmljYXRp b25zDQoNCiAgIGRlZmluZSB0aGUgc3ludGF4IGFuZCBzZW1hbnRpY3Mgb2YgU0VUcyBjb25mb3Jt aW5nIHRvIHRoYXQgU0VUDQoNCiAgIHByb2ZpbGUgYW5kIHJ1bGVzIGZvciB2YWxpZGF0aW5nIHRo b3NlIFNFVHMuICBQcm9maWxpbmcNCg0KICAgc3BlY2lmaWNhdGlvbnMgU0hPVUxEIGRlZmluZSBz eW50YXgsIHNlbWFudGljcywgc3ViamVjdA0KDQogICBpZGVudGlmaWNhdGlvbiwgYW5kIHZhbGlk YXRpb24uDQoNCg0KDQogICBTeW50YXgNCg0KICAgICAgVGhlIHN5bnRheCBkZWZpbmVkIGJ5DQoN CiAgIHByb2ZpbGluZyBzcGVjaWZpY2F0aW9ucyBpbmNsdWRlcyB3aGF0IGNsYWltcyBvZiB0aGUg U0VUcyBkZWZpbmVkLCBpbmNsdWRpbmc6DQoNCg0KDQogICAgICBUb3AtTGV2ZWwgQ2xhaW1zDQoN CiAgICAgICAgIENsYWltcyBhbmQgZXZlbnQgcGF5bG9hZCB2YWx1ZXMgcGxhY2VkIGF0IHRoZSBK V1QgQ2xhaW1zIFNldC4gRXhhbXBsZXMgYXJlIHVzZWQNCg0KICAgICAgICAgY2xhaW1zIGRlZmlu ZWQgYnkgU0VUcyB1dGlsaXppbmcgdGhlIHByb2ZpbGUuIEpXVCBzcGVjaWZpY2F0aW9uIChzZWUg W1JGQzc1MTldKSwgdGhlDQoNCiAgICAgICAgIFNFVCBzcGVjaWZpY2F0aW9uLCBhbmQgYnkgdGhl IHByb2ZpbGluZyBzcGVjaWZpY2F0aW9uLg0KDQoNCg0KICAgICAgRXZlbnQgUGF5bG9hZA0KDQog ICAgICAgICBUaGUgSlNPTiBkYXRhIHN0cnVjdHVyZSBjb250ZW50cyBhbmQgZm9ybWF0LCBjb250 YWluaW5nIGV2ZW50LQ0KDQogICAgICAgICBzcGVjaWZpYyBpbmZvcm1hdGlvbiwgaWYgYW55IChz ZWUgU2VjdGlvbiAxLjIpLg0KDQoNCg0KICAgU2VtYW50aWNzDQoNCiAgICAgIERlZmluaW5nIHRo ZSBzZW1hbnRpY3Mgb2YgdGhlIFNFVCBjb250ZW50cyBmb3IgU0VUcyB1dGlsaXppbmcgdGhlDQoN CiAgICAgIHByb2ZpbGUgaXMgZXF1YWxseSBpbXBvcnRhbnQuICBQb3NzaWJseSBtb3N0IGltcG9y dGFudCBpcyBkZWZpbmluZw0KDQogICAgICB0aGUgcHJvY2VkdXJlcyB1c2VkIHRvIHZhbGlkYXRl IHRoZSBTRVQgaXNzdWVyIGFuZCB0byBvYnRhaW4gdGhlDQoNCiAgICAgIGtleXMgY29udHJvbGxl ZCBieSB0aGUgaXNzdWVyIHRoYXQgd2VyZSB1c2VkIGZvciBjcnlwdG9ncmFwaGljDQoNCiAgICAg IG9wZXJhdGlvbnMgdXNlZCBpbiB0aGUgSldUIHJlcHJlc2VudGluZyB0aGUgU0VULiAgRm9yIGlu c3RhbmNlLA0KDQogICAgICBzb21lIHByb2ZpbGVzIG1heSBkZWZpbmUgYW4gYWxnb3JpdGhtIGZv ciByZXRyaWV2aW5nIHRoZSBTRVQNCg0KICAgICAgaXNzdWVyJ3Mga2V5cyB0aGF0IHVzZXMgdGhl ICJpc3MiIGNsYWltIHZhbHVlIGFzIGl0cyBpbnB1dC4NCg0KICAgICAgTGlrZXdpc2UsIGlmIHRo ZSBwcm9maWxlIGFsbG93cyAob3IgcmVxdWlyZXMpIHRoYXQgdGhlIEpXVCBiZQ0KDQogICAgICB1 bnNlY3VyZWQsIHRoZSBtZWFucyBieSB3aGljaCB0aGUgaW50ZWdyaXR5IG9mIHRoZSBKV1QgaXMg ZW5zdXJlZA0KDQogICAgICBNVVNUIGJlIHNwZWNpZmllZC4NCg0KDQoNCiAgIFN1YmplY3QgSWRl bnRpZmljYXRpb24NCg0KICAgICAgUHJvZmlsaW5nIHNwZWNpZmljYXRpb25zIE1VU1QgZGVmaW5l IGhvdyB0aGUgZXZlbnQgc3ViamVjdCBpcw0KDQogICAgICBpZGVudGlmaWVkIGluIHRoZSBTRVQs IGFzIHdlbGwgYXMgaG93IHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiB0aGUNCg0KICAgICAgZXZl bnQgc3ViamVjdCdzIGlzc3VlciBhbmQgdGhlIFNFVCBpc3N1ZXIsIGlmIGFwcGxpY2FibGUuICBJ dCBpcw0KDQogICAgICBOT1QgUkVDT01NRU5ERUQgZm9yIHByb2ZpbGluZyBzcGVjaWZpY2F0aW9u cyB0byB1c2UgdGhlICJzdWIiDQoNCiAgICAgIGNsYWltIGluIGNhc2VzIGluIHdoaWNoIHRoZSBz dWJqZWN0IGlzIG5vdCBnbG9iYWxseSB1bmlxdWUgYW5kIGhhcw0KDQogICAgICBhIGRpZmZlcmVu dCBpc3N1ZXIgZnJvbSB0aGUgU0VUIGl0c2VsZi4NCg0KDQoNCiAgIFZhbGlkYXRpb24NCg0KICAg ICAgUHJvZmlsaW5nIHNwZWNpZmljYXRpb25zIE1VU1QgY2xlYXJseSBzcGVjaWZ5IHRoZSBzdGVw cyB0aGF0IGENCg0KICAgICAgcmVjaXBpZW50IG9mIGEgU0VUIHV0aWxpemluZyB0aGF0IHByb2Zp bGUgTVVTVCBwZXJmb3JtIHRvIHZhbGlkYXRlDQoNCiAgICAgIHRoYXQgdGhlIFNFVCBpcyBib3Ro IHN5bnRhY3RpY2FsbHkgYW5kIHNlbWFudGljYWxseSB2YWxpZC4NCg0KDQoNCiAgICAgIEFtb25n IHRoZSBzeW50YXggYW5kIHNlbWFudGljcyBvZiBTRVRzIHRoYXQgYSBwcm9maWxpbmcNCg0KICAg ICAgc3BlY2lmaWNhdGlvbiBtYXkgZGVmaW5lIGlzIHdoZXRoZXIgdGhlIHZhbHVlIG9mIHRoZSAi ZXZlbnRzIg0KDQogICAgICBjbGFpbSBtYXkgY29udGFpbiBtdWx0aXBsZSBtZW1iZXJzLCBhbmQg d2hhdCBwcm9jZXNzaW5nDQoNCiAgICAgIGluc3RydWN0aW9ucyBhcmUgZW1wbG95ZWQgaW4gdGhl IHNpbmdsZS0gYW5kIG11bHRpcGxlLXZhbHVlZCBjYXNlcw0KDQogICAgICBmb3IgU0VUcyBjb25m b3JtaW5nIHRvIHRoYXQgcHJvZmlsZS4gIE1hbnkgdmFsaWQgY2hvaWNlcyBhcmUNCg0KICAgICAg cG9zc2libGUuICBGb3IgaW5zdGFuY2UsIHNvbWUgcHJvZmlsZXMgbWlnaHQgYWxsb3cgbXVsdGlw bGUgZXZlbnQNCg0KICAgICAgaWRlbnRpZmllcnMgdG8gYmUgcHJlc2VudCBhbmQgc3BlY2lmeSB0 aGF0IGFueSB0aGF0IGFyZSBub3QNCg0KICAgICAgdW5kZXJzdG9vZCBieSByZWNpcGllbnRzIGJl IGlnbm9yZWQsIHRodXMgZW5hYmxpbmcgZXh0ZW5zaWJpbGl0eS4NCg0KICAgICAgT3RoZXIgcHJv ZmlsZXMgbWlnaHQgYWxsb3cgbXVsdGlwbGUgZXZlbnQgaWRlbnRpZmllcnMgdG8gYmUNCg0KICAg ICAgcHJlc2VudCBidXQgcmVxdWlyZSB0aGF0IGFsbCBiZSB1bmRlcnN0b29kIGlmIHRoZSBTRVQg aXMgdG8gYmUNCg0KICAgICAgYWNjZXB0ZWQuICBTb21lIHByb2ZpbGVzIG1pZ2h0IHJlcXVpcmUg dGhhdCBvbmx5IGEgc2luZ2xlIHZhbHVlIGJlDQoNCiAgICAgIHByZXNlbnQuICBBbGwgc3VjaCBj aG9pY2VzIGFyZSB3aXRoaW4gdGhlIHNjb3BlIG9mIHByb2ZpbGluZw0KDQogICAgICBzcGVjaWZp Y2F0aW9ucyB0byBkZWZpbmUuDQoNCg0KDQogICBQcm9maWxpbmcgc3BlY2lmaWNhdGlvbnMgTVVT VCBjbGVhcmx5IHNwZWNpZnkgdGhlIHN0ZXBzIHRoYXQgYQ0KDQogICByZWNpcGllbnQgb2YgYSBT RVQgdXRpbGl6aW5nIHRoYXQgcHJvZmlsZSBNVVNUIHBlcmZvcm0gdG8gdmFsaWRhdGUNCg0KICAg dGhhdCB0aGUgU0VUIGlzIGJvdGggc3ludGFjdGljYWxseSBhbmQgc2VtYW50aWNhbGx5IHZhbGlk Lg0KDQpQaGlsDQoNCk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2VydmljZXMg QXJjaGl0ZWN0DQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93 d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20+DQoNCg0KT24gQXByIDIwLCAyMDE4LCBhdCAxMTowMyBBTSwgUnVzcyBI b3VzbGV5IDxob3VzbGV5QHZpZ2lsc2VjLmNvbTxtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20+ PiB3cm90ZToNCg0KUmV2aWV3ZXI6IFJ1c3MgSG91c2xleQ0KUmV2aWV3IHJlc3VsdDogSGFzIElz c3Vlcw0KDQpJIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgU2VjdXJpdHkg RGlyZWN0b3JhdGUncyBvbmdvaW5nDQplZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50 cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZQ0KY29tbWVudHMgd2VyZSB3cml0 dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIFNlY3VyaXR5IEFyZWENCkRpcmVj dG9ycy4gIERvY3VtZW50IGF1dGhvcnMsIGRvY3VtZW50IGVkaXRvcnMsIGFuZCBXRyBjaGFpcnMg c2hvdWxkDQp0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIElFVEYgTGFz dCBDYWxsIGNvbW1lbnRzLg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1zZWNldmVudC10b2tlbi0w OQ0KUmV2aWV3ZXI6IFJ1c3MgSG91c2xleQ0KUmV2aWV3IERhdGU6IDIwMTgtMDQtMjANCklFVEYg TEMgRW5kIERhdGU6IHVua25vd24NCklFU0cgVGVsZWNoYXQgZGF0ZTogMjAxOC0wNS0xMA0KDQpT dW1tYXJ5OiBIYXMgSXNzdWVzDQoNCk1ham9yIENvbmNlcm5zDQoNCkkgZG8gbm90IHVuZGVyc3Rh bmQgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDMuICBJIG1hZGUgdGhpcw0KY29tbWVu dCBvbiB2ZXJzaW9uIC0wNywgYW5kIHNvbWUgd29yZHMgd2VyZSBhZGRlZCwgYnV0IEkgc3RpbGwg ZG8NCm5vdCB1bmRlcnN0YW5kIHRoaXMgcGFyYWdyYXBoLiAgSSB0aGluayB5b3UgYXJlIHRyeWlu ZyB0byBpbXBvc2Ugc29tZQ0KcnVsZXMgb24gZnV0dXJlIHNwZWNpZmljYXRpb25zIHRoYXQgdXNl IFNFVCB0byBkZWZpbmUgZXZlbnRzLiAgTGV0IG1lDQphc2sgYSBjb3VwbGUgb2YgcXVlc3Rpb25z IHRoYXQgbWF5IGhlbHAuICBJIHVuZGVyc3RhbmQgdGhhdCBhDQpwcm9maWxpbmcgc3BlY2lmaWNh dGlvbiBNVVNUIHNwZWNpZnkgdGhlIHN5bnRheCBhbmQgc2VtYW50aWNzIGZvciBhDQpjb2xsZWN0 aW9uIG9mIHNlY3VyaXR5IGV2ZW50IHRva2VucywgaW5jbHVkaW5nIHRoZSBjbGFpbXMgYW5kIHBh eWxvYWRzDQp0aGF0IGFyZSBleHBlY3RlZC4gIFdoYXQgTVVTVCBhIHByb2ZpbGluZyBzcGVjaWZp Y2F0aW9uIGluY2x1ZGU/ICBXaGF0DQpNVVNUIGEgcHJvZmlsaW5nIHNwZWNpZmljYXRpb24gTk9U IGluY2x1ZGU/DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklk LWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi4ub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZk PUR3SUNBZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1u YTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09aEpGeC1aMmloMTh1 VU5DWG9zQWp2eWdIcW4yX0sybXROenFJZWozQWgtYyZzPTI4T1dlNDJTMGJnOFkyZW8zVlZ6QUNl U1luemdpeXllWExsN3RUdTlpMVkmZT0NCg0K --_000_MW2PR00MB03008E6BC62F553A785D9D5DF5830MW2PR00MB0300namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7fQ0Kc3Bhbi54YXBwbGUtc3R5bGUtc3Bh bg0KCXttc28tc3R5bGUtbmFtZTp4X2FwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxl MjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPkhpIFJ1c3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj5JIHdhbnRlZCB0byBjaGVjayBiYWNrIGluLiZuYnNwOyBBcmUgeW91IGdvb2Qgd2l0aCB0 aGVzZSBjaGFuZ2VzIHRvIGFkZHJlc3MgeW91ciBjb21tZW50IG9yIGRvIHdhbnQgdG8gc3VnZ2Vz dCB0aGF0IHdlIHRha2UgYSBkaWZmZXJlbnQgZGlyZWN0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBJZC1ldmVudCAmbHQ7aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyZndDsg PGI+T24gQmVoYWxmIE9mDQo8L2I+UGhpbCBIdW50PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IEFwcmlsIDI0LCAyMDE4IDI6NTAgUE08YnI+DQo8Yj5Ubzo8L2I+IFJ1c3MgSG91c2xleSAmbHQ7 aG91c2xleUB2aWdpbHNlYy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1pZXRmLXNlY2V2 ZW50LXRva2VuLmFsbEBpZXRmLm9yZzsgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tJmd0OzsgaWV0ZkBpZXRmLm9yZzsgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7 aWQtZXZlbnRAaWV0Zi5vcmcmZ3Q7OyBzZWNkaXJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtJZC1ldmVudF0gU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1z ZWNldmVudC10b2tlbi0wOTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SdXNzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SGVyZSBhcmUgcHJv cG9zZWQgY2hhbmdlcyB0byBhZGRyZXNzIHlvdXIgcXVlc3Rpb25zIGFib3V0IFNlY3Rpb24gMy4m bmJzcDsgWW914oCZcmUgcmlnaHQgdGhhdCB0aGlzIHNlY3Rpb24gaXMgcGxhY2luZyByZXF1aXJl bWVudHMgb24gcHJvZmlsaW5nIHNwZWNpZmljYXRpb25zLiZuYnNwOyBUaGUgY2hhbmdlcyBtYWRl IGFyZSBpbnRlbmRlZCB0byBtYWtlIHRoaXMgbW9yZSBleHBsaWNpdC4mbmJzcDsNCiBQbGVhc2Ug bGV0IHVzIGtub3cgaWYgdGhlIHVwZGF0ZWQgdGV4dCB3b3JrcyBmb3IgeW91LCBhbmQgaWYgc28s IHdl4oCZbGwgcHVibGlzaCBhbiB1cGRhdGVkIGRyYWZ0IHVzaW5nIGl0Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPlBsZWFzZSBzZWUgdGhlIHdkaWZmIHRleHQgZm9yIHNlY3Rpb24g MyBiZWxvdyAoYWxzbyBhdHRhY2hlZCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlBoaWwgJmFtcDsgTWlrZTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPuKAlHdkaWZmIGZvciBzZWMgMy0tPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cHJlPjMuJm5ic3A7IFJlcXVpcmVtZW50cyBmb3Ig U0VUIFByb2ZpbGVzPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFByb2ZpbGluZyBzcGVjaWZpY2F0aW9ucyBvZiB0aGlzIHNw ZWNpZmljYXRpb24gZGVmaW5lIGFjdHVhbCBTRVRzIHRvPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IGJlIHVzZWQgaW4gcGFydGljdWxhciB1c2UgY2FzZXMuJm5ic3A7IFRoZXNl IHByb2ZpbGluZyBzcGVjaWZpY2F0aW9uczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBkZWZpbmUgdGhlIHN5bnRheCBhbmQgc2VtYW50aWNzIG9mIFNFVHMgY29uZm9ybWluZyB0 byB0aGF0IFNFVDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBwcm9maWxlIGFu ZCBydWxlcyBmb3IgdmFsaWRhdGluZyB0aG9zZSBTRVRzLiZuYnNwOyA8c3Ryb25nPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpncmVlbiI+UHJv ZmlsaW5nPG86cD48L286cD48L3NwYW4+PC9zdHJvbmc+PC9wcmU+DQo8cHJlPjxzdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmdyZWVu Ij4mbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbnMgU0hPVUxEIGRlZmluZSBzeW50YXgsIHNlbWFu dGljcywgc3ViamVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvc3Ryb25nPjwvcHJlPg0KPHByZT48c3Ry b25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpncmVlbiI+Jm5ic3A7Jm5ic3A7IGlkZW50aWZpY2F0aW9uLCBhbmQgdmFsaWRhdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3N0cm9uZz48L3ByZT4NCjxwcmU+PHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvc3Ryb25nPjwvcHJlPg0KPHByZT48c3Ryb25nPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpncmVlbiI+Jm5ic3A7 Jm5ic3A7IFN5bnRheDwvc3Bhbj48L3N0cm9uZz48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHN5bnRheCA8cz48c3BhbiBzdHlsZT0iY29s b3I6cmVkIj5kZWZpbmVkIGJ5PG86cD48L286cD48L3NwYW4+PC9zPjwvcHJlPg0KPHByZT48cz48 c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgcHJvZmlsaW5nIHNwZWNpZmljYXRp b25zIGluY2x1ZGVzIHdoYXQgY2xhaW1zPC9zcGFuPjwvcz4gPHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4iPm9mIHRoZSBT RVRzIGRlZmluZWQsIGluY2x1ZGluZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3N0cm9uZz48L3ByZT4N CjxwcmU+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6Z3JlZW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Ryb25nPjwvcHJl Pg0KPHByZT48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpncmVlbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRvcC1M ZXZlbCBDbGFpbXM8bzpwPjwvbzpwPjwvc3Bhbj48L3N0cm9uZz48L3ByZT4NCjxwcmU+PHN0cm9u Zz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 Z3JlZW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBD bGFpbXM8L3NwYW4+PC9zdHJvbmc+IGFuZCA8cz48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5ldmVu dCBwYXlsb2FkPC9zcGFuPjwvcz4gdmFsdWVzIDxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmdyZWVuIj5wbGFjZWQgYXQgdGhlIEpX VCBDbGFpbXMgU2V0LiBFeGFtcGxlczwvc3Bhbj48L3N0cm9uZz4gYXJlIDxzPjxzcGFuIHN0eWxl PSJjb2xvcjpyZWQiPnVzZWQ8L3NwYW4+PC9zPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8c3Ryb25nPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpncmVlbiI+ Y2xhaW1zIGRlZmluZWQ8L3NwYW4+PC9zdHJvbmc+IGJ5IDxzPjxzcGFuIHN0eWxlPSJjb2xvcjpy ZWQiPlNFVHMgdXRpbGl6aW5nPC9zcGFuPjwvcz4gdGhlIDxzPjxzcGFuIHN0eWxlPSJjb2xvcjpy ZWQiPnByb2ZpbGUuPC9zcGFuPjwvcz4gPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4iPkpXVCBzcGVjaWZpY2F0aW9uIChz ZWUgW1JGQzc1MTldKSwgdGhlPG86cD48L286cD48L3NwYW4+PC9zdHJvbmc+PC9wcmU+DQo8cHJl PjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmdyZWVuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgU0VUIHNwZWNpZmljYXRpb24sIGFuZCBieSB0aGUgcHJvZmlsaW5nIHNwZWNpZmljYXRp b24uPG86cD48L286cD48L3NwYW4+PC9zdHJvbmc+PC9wcmU+DQo8cHJlPjxzdHJvbmc+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmdyZWVuIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3N0cm9uZz48L3ByZT4NCjxwcmU+PHN0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFdmVudCBQYXlsb2FkPG86cD48L286cD48 L3NwYW4+PC9zdHJvbmc+PC9wcmU+DQo8cHJlPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmdyZWVuIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIEpTT04gZGF0YSBzdHJ1Y3R1cmUg Y29udGVudHMgYW5kIGZvcm1hdCwgY29udGFpbmluZyBldmVudC08bzpwPjwvbzpwPjwvc3Bhbj48 L3N0cm9uZz48L3ByZT4NCjxwcmU+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpYyBpbmZvcm1hdGlvbiwgaWYgYW55IChz ZWUgU2VjdGlvbiAxLjIpLjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Ryb25nPjwvcHJlPg0KPHByZT48 c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpncmVlbiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zdHJvbmc+PC9wcmU+DQo8cHJl PjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmdyZWVuIj4mbmJzcDsmbmJzcDsgU2VtYW50aWNzPC9zcGFuPjwvc3Ryb25nPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEZWZpbmlu ZyB0aGUgc2VtYW50aWNzIG9mIHRoZSBTRVQgY29udGVudHMgZm9yIFNFVHMgdXRpbGl6aW5nIHRo ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBw cm9maWxlIGlzIGVxdWFsbHkgaW1wb3J0YW50LiZuYnNwOyBQb3NzaWJseSBtb3N0IGltcG9ydGFu dCBpcyBkZWZpbmluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB0aGUgcHJvY2VkdXJlcyB1c2VkIHRvIHZhbGlkYXRlIHRoZSBTRVQgaXNzdWVy IGFuZCB0byBvYnRhaW4gdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGtleXMgY29udHJvbGxlZCBieSB0aGUgaXNzdWVyIHRoYXQgd2VyZSB1 c2VkIGZvciBjcnlwdG9ncmFwaGljPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wZXJhdGlvbnMgdXNlZCBpbiB0aGUgSldUIHJlcHJlc2VudGlu ZyB0aGUgU0VULiZuYnNwOyBGb3IgaW5zdGFuY2UsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNvbWUgcHJvZmlsZXMgbWF5IGRlZmluZSBhbiBh bGdvcml0aG0gZm9yIHJldHJpZXZpbmcgdGhlIFNFVDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpc3N1ZXIncyBrZXlzIHRoYXQgdXNlcyB0aGUg JnF1b3Q7aXNzJnF1b3Q7IGNsYWltIHZhbHVlIGFzIGl0cyBpbnB1dC48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTGlrZXdpc2UsIGlmIHRoZSBw cm9maWxlIGFsbG93cyAob3IgcmVxdWlyZXMpIHRoYXQgdGhlIEpXVCBiZTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1bnNlY3VyZWQsIHRoZSBt ZWFucyBieSB3aGljaCB0aGUgaW50ZWdyaXR5IG9mIHRoZSBKV1QgaXMgZW5zdXJlZDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNVVNUIGJlIHNw ZWNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4iPlN1YmplY3QgSWRlbnRpZmljYXRpb248L3Nw YW4+PC9zdHJvbmc+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFByb2ZpbGluZyBzcGVjaWZpY2F0aW9ucyBNVVNUIGRlZmluZSBob3cgdGhlIGV2 ZW50IHN1YmplY3QgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaWRlbnRpZmllZCBpbiB0aGUgU0VULCBhcyB3ZWxsIGFzIGhvdyB0byBkaWZm ZXJlbnRpYXRlIGJldHdlZW4gdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV2ZW50IHN1YmplY3QncyBpc3N1ZXIgYW5kIHRoZSBTRVQgaXNz dWVyLCBpZiBhcHBsaWNhYmxlLiZuYnNwOyBJdCBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOT1QgUkVDT01NRU5ERUQgZm9yIHByb2ZpbGlu ZyBzcGVjaWZpY2F0aW9ucyB0byB1c2UgdGhlICZxdW90O3N1YiZxdW90OzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjbGFpbSBpbiBjYXNlcyBp biB3aGljaCB0aGUgc3ViamVjdCBpcyBub3QgZ2xvYmFsbHkgdW5pcXVlIGFuZCBoYXM8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBkaWZmZXJl bnQgaXNzdWVyIGZyb20gdGhlIFNFVCBpdHNlbGYuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IDxzdHJvbmc+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmdyZWVuIj5WYWxp ZGF0aW9uPG86cD48L286cD48L3NwYW4+PC9zdHJvbmc+PC9wcmU+DQo8cHJlPjxzdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmdyZWVu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUHJvZmlsaW5nIHNwZWNpZmljYXRpb25z IE1VU1QgY2xlYXJseSBzcGVjaWZ5IHRoZSBzdGVwcyB0aGF0IGE8bzpwPjwvbzpwPjwvc3Bhbj48 L3N0cm9uZz48L3ByZT4NCjxwcmU+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Z3JlZW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyByZWNpcGllbnQgb2YgYSBTRVQgdXRpbGl6aW5nIHRoYXQgcHJvZmlsZSBNVVNUIHBl cmZvcm0gdG8gdmFsaWRhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3N0cm9uZz48L3ByZT4NCjxwcmU+ PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6Z3JlZW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGF0IHRoZSBTRVQg aXMgYm90aCBzeW50YWN0aWNhbGx5IGFuZCBzZW1hbnRpY2FsbHkgdmFsaWQuPC9zcGFuPjwvc3Ry b25nPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBbW9uZyB0aGUgc3ludGF4IGFuZCBzZW1h bnRpY3Mgb2YgU0VUcyB0aGF0IGEgcHJvZmlsaW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRpb24gbWF5IGRlZmluZSBpcyB3 aGV0aGVyIHRoZSB2YWx1ZSBvZiB0aGUgJnF1b3Q7ZXZlbnRzJnF1b3Q7PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNsYWltIG1heSBjb250YWlu IG11bHRpcGxlIG1lbWJlcnMsIGFuZCB3aGF0IHByb2Nlc3Npbmc8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5zdHJ1Y3Rpb25zIGFyZSBlbXBs b3llZCBpbiB0aGUgc2luZ2xlLSBhbmQgbXVsdGlwbGUtdmFsdWVkIGNhc2VzPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciBTRVRzIGNvbmZv cm1pbmcgdG8gdGhhdCBwcm9maWxlLiZuYnNwOyBNYW55IHZhbGlkIGNob2ljZXMgYXJlPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBvc3NpYmxl LiZuYnNwOyBGb3IgaW5zdGFuY2UsIHNvbWUgcHJvZmlsZXMgbWlnaHQgYWxsb3cgbXVsdGlwbGUg ZXZlbnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgaWRlbnRpZmllcnMgdG8gYmUgcHJlc2VudCBhbmQgc3BlY2lmeSB0aGF0IGFueSB0aGF0IGFy ZSBub3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdW5kZXJzdG9vZCBieSByZWNpcGllbnRzIGJlIGlnbm9yZWQsIHRodXMgZW5hYmxpbmcgZXh0 ZW5zaWJpbGl0eS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgT3RoZXIgcHJvZmlsZXMgbWlnaHQgYWxsb3cgbXVsdGlwbGUgZXZlbnQgaWRlbnRp ZmllcnMgdG8gYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgcHJlc2VudCBidXQgcmVxdWlyZSB0aGF0IGFsbCBiZSB1bmRlcnN0b29kIGlmIHRo ZSBTRVQgaXMgdG8gYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgYWNjZXB0ZWQuJm5ic3A7IFNvbWUgcHJvZmlsZXMgbWlnaHQgcmVxdWlyZSB0 aGF0IG9ubHkgYSBzaW5nbGUgdmFsdWUgYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJlc2VudC4mbmJzcDsgQWxsIHN1Y2ggY2hvaWNlcyBh cmUgd2l0aGluIHRoZSBzY29wZSBvZiBwcm9maWxpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbnMgdG8gZGVmaW5lLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyA8cz48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5Qcm9maWxpbmcgc3BlY2lmaWNhdGlv bnMgTVVTVCBjbGVhcmx5IHNwZWNpZnkgdGhlIHN0ZXBzIHRoYXQgYTxvOnA+PC9vOnA+PC9zcGFu Pjwvcz48L3ByZT4NCjxwcmU+PHM+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7 IHJlY2lwaWVudCBvZiBhIFNFVCB1dGlsaXppbmcgdGhhdCBwcm9maWxlIE1VU1QgcGVyZm9ybSB0 byB2YWxpZGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcz48L3ByZT4NCjxwcmU+PHM+PHNwYW4gc3R5 bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IHRoYXQgdGhlIFNFVCBpcyBib3RoIHN5bnRhY3Rp Y2FsbHkgYW5kIHNlbWFudGljYWxseSB2YWxpZC48L3NwYW4+PC9zPjxvOnA+PC9vOnA+PC9wcmU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5PcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZp Y2VzIEFyY2hpdGVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRl bnRpZC5jb20iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXByIDIwLCAyMDE4LCBh dCAxMTowMyBBTSwgUnVzcyBIb3VzbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86aG91c2xleUB2aWdp bHNlYy5jb20iPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZXZpZXdlcjogUnVzcyBIb3VzbGV5 PGJyPg0KUmV2aWV3IHJlc3VsdDogSGFzIElzc3Vlczxicj4NCjxicj4NCkkgcmV2aWV3ZWQgdGhp cyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBTZWN1cml0eSBEaXJlY3RvcmF0ZSdzIG9uZ29pbmc8 YnI+DQplZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQg YnkgdGhlIElFU0cuICZuYnNwO1RoZXNlPGJyPg0KY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1h cmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIFNlY3VyaXR5IEFyZWE8YnI+DQpEaXJlY3RvcnMu ICZuYnNwO0RvY3VtZW50IGF1dGhvcnMsIGRvY3VtZW50IGVkaXRvcnMsIGFuZCBXRyBjaGFpcnMg c2hvdWxkPGJyPg0KdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBJRVRG IExhc3QgQ2FsbCBjb21tZW50cy48YnI+DQo8YnI+DQpEb2N1bWVudDogZHJhZnQtaWV0Zi1zZWNl dmVudC10b2tlbi0wOTxicj4NClJldmlld2VyOiBSdXNzIEhvdXNsZXk8YnI+DQpSZXZpZXcgRGF0 ZTogMjAxOC0wNC0yMDxicj4NCklFVEYgTEMgRW5kIERhdGU6IHVua25vd248YnI+DQpJRVNHIFRl bGVjaGF0IGRhdGU6IDIwMTgtMDUtMTA8YnI+DQo8YnI+DQpTdW1tYXJ5OiBIYXMgSXNzdWVzPGJy Pg0KPGJyPg0KTWFqb3IgQ29uY2VybnM8YnI+DQo8YnI+DQpJIGRvIG5vdCB1bmRlcnN0YW5kIHRo ZSBmaXJzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiAzLiAmbmJzcDtJIG1hZGUgdGhpczxicj4NCmNv bW1lbnQgb24gdmVyc2lvbiAtMDcsIGFuZCBzb21lIHdvcmRzIHdlcmUgYWRkZWQsIGJ1dCBJIHN0 aWxsIGRvPGJyPg0Kbm90IHVuZGVyc3RhbmQgdGhpcyBwYXJhZ3JhcGguICZuYnNwO0kgdGhpbmsg eW91IGFyZSB0cnlpbmcgdG8gaW1wb3NlIHNvbWU8YnI+DQpydWxlcyBvbiBmdXR1cmUgc3BlY2lm aWNhdGlvbnMgdGhhdCB1c2UgU0VUIHRvIGRlZmluZSBldmVudHMuICZuYnNwO0xldCBtZTxicj4N CmFzayBhIGNvdXBsZSBvZiBxdWVzdGlvbnMgdGhhdCBtYXkgaGVscC4gJm5ic3A7SSB1bmRlcnN0 YW5kIHRoYXQgYTxicj4NCnByb2ZpbGluZyBzcGVjaWZpY2F0aW9uIE1VU1Qgc3BlY2lmeSB0aGUg c3ludGF4IGFuZCBzZW1hbnRpY3MgZm9yIGE8YnI+DQpjb2xsZWN0aW9uIG9mIHNlY3VyaXR5IGV2 ZW50IHRva2VucywgaW5jbHVkaW5nIHRoZSBjbGFpbXMgYW5kIHBheWxvYWRzPGJyPg0KdGhhdCBh cmUgZXhwZWN0ZWQuICZuYnNwO1doYXQgTVVTVCBhIHByb2ZpbGluZyBzcGVjaWZpY2F0aW9uIGlu Y2x1ZGU/ICZuYnNwO1doYXQ8YnI+DQpNVVNUIGEgcHJvZmlsaW5nIHNwZWNpZmljYXRpb24gTk9U IGluY2x1ZGU/PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYuLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0Fn JmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9 bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1oSkZ4LVoy aWgxOHVVTkNYb3NBanZ5Z0hxbjJfSzJtdE56cUllajNBaC1jJmFtcDtzPTI4T1dlNDJTMGJnOFky ZW8zVlZ6QUNlU1luemdpeXllWExsN3RUdTlpMVkmYW1wO2UiPmh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYuLm9yZ19tYWlsbWFuX2xp c3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4 UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZ cVBrQUkxYUxjTE40S1pOQSZhbXA7bT1oSkZ4LVoyaWgxOHVVTkNYb3NBanZ5Z0hxbjJfSzJtdE56 cUllajNBaC1jJmFtcDtzPTI4T1dlNDJTMGJnOFkyZW8zVlZ6QUNlU1luemdpeXllWExsN3RUdTlp MVkmYW1wO2U8L2E+PTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MW2PR00MB03008E6BC62F553A785D9D5DF5830MW2PR00MB0300namp_--