From nobody Tue Sep 1 01:09:48 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75FA1ACD5C; Tue, 1 Sep 2015 01:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5TfPxNGaxmVE; Tue, 1 Sep 2015 01:09:45 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6831E1B854D; Tue, 1 Sep 2015 01:09:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.17,447,1437429600"; d="asc'?scan'208,217";a="175547351" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Sep 2015 10:09:20 +0200 From: Vincent Roca X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_A9AD1682-5E90-46EF-95DB-FFFD28AA47B0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 1 Sep 2015 10:09:18 +0200 Message-Id: To: IESG , secdir@ietf.org, draft-hansen-scram-sha256@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [secdir] Secdir review of draft-hansen-scram-sha256-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 08:09:47 -0000 --Apple-Mail=_A9AD1682-5E90-46EF-95DB-FFFD28AA47B0 Content-Type: multipart/alternative; boundary="Apple-Mail=_A238F2F7-8E65-4A12-B6E3-EED421EF5AC4" --Apple-Mail=_A238F2F7-8E65-4A12-B6E3-EED421EF5AC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I have reviewed this document as part of the security directorate=E2=80=99= 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. IMHO, the document is ready. Just a minor comment: it is said in the Security Considerations section = that: =C2=ABan iteration count of 4096 takes around 0.5 seconds on = current mobile handsets.=C2=BB It may be useful to give an idea of the features of a representative = =C2=ABcurrent mobile handset=C2=BB. It can simplify comparisons in a few years from now as things are = evolving quite rapidly in this domain. Cheers, Vincent --Apple-Mail=_A238F2F7-8E65-4A12-B6E3-EED421EF5AC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

I have reviewed this = document as part of the security directorate=E2=80=99s 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.


IMHO, the document = is ready. 

Just a minor comment: it is said in the = Security Considerations section that:
=C2=ABan = iteration count of 4096 takes around 0.5 seconds on current mobile = handsets.=C2=BB
It may be useful to give an idea of = the features of a representative =C2=ABcurrent mobile = handset=C2=BB.
It can simplify comparisons in a few = years from now as things are evolving quite rapidly in this
domain.

Cheers,

  Vincent

= --Apple-Mail=_A238F2F7-8E65-4A12-B6E3-EED421EF5AC4-- --Apple-Mail=_A9AD1682-5E90-46EF-95DB-FFFD28AA47B0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJV5V0vAAoJEHBYw8t72N4rCyoP/A+G5eR2AhJBDwKhSxRMHBma EtEWRmc4ggfnLcgPtGHQopnhObyXYv8oyv6PXDiA0B+WrMv5C7aYk68poTKFuSuW h8Ybrlw6SSS361CNYEvspATLpuw8ob6zwFoNwM97Ys4LoDfNmlfGDRLhsEgxZEFV xCnuIxK3sSltuxZ7X2Ui+ed7fXiqS7oq9Iw+VrmzbdwIl5igxVQ2lzQoMWxzTiE9 T/qganfWbXll5HZiBThth9NhhGLPDoAvcX+n4sYV8CIqT8VgTBQsBqhi1GDGmamX m15S36DnPz+gO6XKSeOOYv52ZGvN6QHsj59dnLtO3Sfb8/IYnt04KeuIRSMIuPar CI3sHumdlC6ehw2Dx7IMy7rDUQFbY2NhA2njsJrAKS1kh8dYFrDCvOi6rqDtFk90 Ufp3Z5z6/l5QtPwcBBm3vm84bTu7uf3Wy9Yb+9SygUeJnC2ocLfrS2hdpsD0yXNl iQsHuGzEoTEUYehrsuTr6NiMxb+Ew9+Ptp1dOeuCOjUb0rnJLT993xUMmri0vaQG 3BbhGwe2ouurWLi/oh6aAWj9biPuuuA3ldj99vUpukzX7CRJ8SBCKJz9Ut3NwIvU u+cOKuqrC+fUeh+jVGRwxxLWkaf4zIzT662YrdnZqrt90X80hY/3pl4tDSqYAGvb 8/B2NFmMeZQXRhX/7o7P =F7WJ -----END PGP SIGNATURE----- --Apple-Mail=_A9AD1682-5E90-46EF-95DB-FFFD28AA47B0-- From nobody Tue Sep 1 01:25:33 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF4B1B8878; Tue, 1 Sep 2015 01:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 YegHOo0drsll; Tue, 1 Sep 2015 01:25:27 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEEC81B899C; Tue, 1 Sep 2015 01:25:27 -0700 (PDT) Received: from [192.168.0.3] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 11D3522E2E7; Tue, 1 Sep 2015 04:25:22 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <009901d0e470$2e74c8e0$8b5e5aa0$@huitema.net> Date: Tue, 1 Sep 2015 18:25:19 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <1C5092C0-36BA-47C2-A80E-02B09957E03F@mnot.net> References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> <55E22119.9080106@bogus.com> <003001d0e40e$5ce522e0$16af68a0$@huitema.net> <4E6CC84B-791C-4016-9934-3F75083E4C70@mnot.net> <009901d0e470$2e74c8e0$8b5e5aa0$@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.2104) Archived-At: Cc: secdir , Alec Muffett , joel jaeggli , Kathleen Moriarty , draft-ietf-dnsop-onion-tld.all@tools.ietf.org, Brad Hill , The IESG , Barry Leiba Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 08:25:30 -0000 Applied in = . Thanks, > On 1 Sep 2015, at 2:39 pm, Christian Huitema = wrote: >=20 > On Monday, August 31, 2015 5:48 PM, Mark Nottingham wrote >>=20 >> On 1 Sep 2015, at 2:59 am, Christian Huitema = wrote: >>>=20 >>> A legacy client may inadvertently attempt to resolve a ".onion" name >> through >>> the DNS. This causes a disclosure that the client is using TOR to = reach > a >>> specific service. Malicious resolvers could be engineered to capture = and >>> record such leaks, which might have very adverse consequences for = the >>> well-being of the TOR user. This issue is mitigated if the client's = TOR >>> software is updated to not leak such queries, or if the client's DNS >>> software is updated to drop any request to the ".onion" TLD. >>=20 >> Is that just a drop-in replacement for this? >>=20 >> """ >> If client software attempts to resolve a .onion name, it can leak the > identity >> of the service that the user is attempting to access to DNS = resolvers, >> authoritative DNS servers, and observers on the intervening network. = This > risk >> is mitigated when the recommendations in {{onion}} are followed, but = are > still >> present when using systems that are not updated. >> """ >=20 > You challenged me to produce some text, so I did... But I should have = taken > a closer look at your change. We are definitely expressing the same = idea. My > text is perhaps a bit more explicit, but it lacks the pointer to the > specific section in which the recommendations are made. Your text = maybe > lacks the motivating part that fixing DNS software is part of "defense = in > depth." >=20 > -- Christian Huitema >=20 >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Sep 1 01:36:08 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768451B8A7E; Tue, 1 Sep 2015 01:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 qKWk3DxKTDOp; Tue, 1 Sep 2015 01:36:03 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3811B8748; Tue, 1 Sep 2015 01:36:03 -0700 (PDT) Received: from [192.168.0.3] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BBF9722E2EF; Tue, 1 Sep 2015 04:35:58 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <55E414D7.3070600@cs.tcd.ie> Date: Tue, 1 Sep 2015 18:35:55 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <371BFDC3-19C6-4B5F-AA49-525DBA26EA67@mnot.net> References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> <55E22119.9080106@bogus.com> <55E414D7.3070600@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: secdir , Alec Muffett , joel jaeggli , Kathleen Moriarty , "draft-ietf-dnsop-onion-tld.all@tools.ietf.org" , The IESG , Brad Hill , Barry Leiba Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 08:36:07 -0000 Hey Stephen, On 31 Aug 2015, at 6:48 pm, Stephen Farrell = wrote: >=20 >=20 > Hi Mark, >=20 > I thought there was also to be a change to say that .onion names would > in future need to continue to adhere to the DNS name syntax (lengths > mainly) just so that we don't get more ickkiness when/if .onion names > are handled by code expecting DNS names? >=20 > That wasn't from the secdir review but came up in the general IETF > list discussion in the last call. See: = https://github.com/mnot/I-D/commit/3b691672b94455f2038353ae03c04c3b1001193= d Note that I just stole that text out of RFC3986. If there's a better way = to do it, I'm all ears. Cheers, >=20 > S. >=20 > On 31/08/15 08:58, Mark Nottingham wrote: >> Attempting to address all of the outstanding feedback I've seen: >>=20 >> * = uses .onion "names" instead of "addresses" consistently. >>=20 >> * = clarifies the requirements placed upon registrars, as per the IANA = review. >>=20 >> * = updates the Tor URLs, but does NOT flip the two references suggested = in Gen-ART to Normative; as per subsequent discussion, they aren't = necessary to register the TLD, merely informative. Please advise if I = read that wrong. >>=20 >> * = moves much of the generic explanatory text from Security = Considerations into the Introduction, as per the SecDir review.=20 >>=20 >> * = notes what happens when legacy systems get DNS queries leaked to = them, as per the SecDir review. >>=20 >> * I didn't yet do anything to address this feedback in the SecDir = review: >>=20 >>> Then, the security section also does not discuss how malicious name = resolvers could be deployed in order to attack the TOR network. For = example, if TOR security relies on DNS servers =E2=80=9Cblack holing=E2=80= =9D misrouted request to resolve =E2=80=9C.onion=E2=80=9D names, what = happens if malicious servers replace the suggested black-holing with = some malicious tampering? >>=20 >> Christian, how would that work? I don't see how this kind of attack = (by having a malicious server leverage clients who erroneously forward = DNS requests for .onion) is going to be qualitatively different from any = other attack on the Tor network; indeed, it doesn't seem like a very = effective way to attack the network itself. Now, it may be that you can = trick some users into thinking they're on Tor when they're not, in the = right circumstances, but that's not an attack on the network.=20 >>=20 >> Can you give some more detail here (or ideally some suggested text)? >>=20 >> Cheers, >>=20 >>=20 >>=20 >>> On 30 Aug 2015, at 7:16 am, joel jaeggli wrote: >>>=20 >>> On 8/29/15 3:10 AM, Mark Nottingham wrote: >>>=20 >>>> If the IESG would like to set a clear, unambiguous policy about = this, >>>> I'm sure it would be welcomed; personally, I've heard advice both >>>> ways, and have not yet figured out how to make everyone happy. >>>=20 >>> Well... you can ask me. imho the situation looks like the following = to me. >>>=20 >>> I think it's fine to have the discussion, propose the updates and = hold >>> the draft update till the end; or to roll a new version as the = product >>> of the discussion. The former runs the risk of accumulating a = discuss >>> either from me or from another AD due to something that "really = needs to >>> be addressed" prior to exit from iesg review. the later that we need >>> more time, if it comes shortly before thursday. ( the call is now at >>> 0700 pacific) so it's extremely unlikely that I will manange to >>> re-review something submitted late wednesday evening. >>>=20 >>> I'm kind of waiting on the update to the iana language I asked for = on >>> 8/15 and that is a barrier to publication, but I expect we know what >>> it's going to say in that respect already so I'm not going to hold = up >>> the dicussion on that... >>>=20 >>> thanks >>> joel >>>=20 >>>> Cheers, >>>>=20 >>>> -- Mark Nottingham https://www.mnot.net/ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Sep 1 02:33:46 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B381B8DFE; Tue, 1 Sep 2015 02:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pFsZX9sSV6MK; Tue, 1 Sep 2015 02:33:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED8F1B6341; Tue, 1 Sep 2015 02:33:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 42FA9BE98; Tue, 1 Sep 2015 10:33:39 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Neckvw5Y3ZY9; Tue, 1 Sep 2015 10:33:39 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 46592BE5D; Tue, 1 Sep 2015 10:33:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441100019; bh=AHP+M/j/sprUVZD48hkClbFaLeUZt8bWRuMvxpMXitE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=s9EzBYkCHA45ISWvZhzBiutbgzxWtV9c1hQ5oUUy26uMzx0KVnWpcqiaVqtUU134S uPnagfW9tv8VTqABvpu3pA9oHFdQOF9sugBR5k/60cu8dB3hyzpHbS5tswN+IH0c/L PXaioVDZjqUwLqmA3gD8hBYuQtruEobyGbUSOhNk= To: Mark Nottingham References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> <55E22119.9080106@bogus.com> <55E414D7.3070600@cs.tcd.ie> <371BFDC3-19C6-4B5F-AA49-525DBA26EA67@mnot.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55E570E6.4090603@cs.tcd.ie> Date: Tue, 1 Sep 2015 10:33:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <371BFDC3-19C6-4B5F-AA49-525DBA26EA67@mnot.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: secdir , Alec Muffett , joel jaeggli , Kathleen Moriarty , "draft-ietf-dnsop-onion-tld.all@tools.ietf.org" , The IESG , Brad Hill , Barry Leiba Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 09:33:44 -0000 On 01/09/15 09:35, Mark Nottingham wrote: > Hey Stephen, > > On 31 Aug 2015, at 6:48 pm, Stephen Farrell wrote: >> >> >> Hi Mark, >> >> I thought there was also to be a change to say that .onion names would >> in future need to continue to adhere to the DNS name syntax (lengths >> mainly) just so that we don't get more ickkiness when/if .onion names >> are handled by code expecting DNS names? >> >> That wasn't from the secdir review but came up in the general IETF >> list discussion in the last call. > > See: > https://github.com/mnot/I-D/commit/3b691672b94455f2038353ae03c04c3b1001193d > > Note that I just stole that text out of RFC3986. If there's a better way to do it, I'm all ears. I think that's a fine change and reflects the list discussion perfectly. Ta, S. > > Cheers, > > > >> >> S. >> >> On 31/08/15 08:58, Mark Nottingham wrote: >>> Attempting to address all of the outstanding feedback I've seen: >>> >>> * uses .onion "names" instead of "addresses" consistently. >>> >>> * clarifies the requirements placed upon registrars, as per the IANA review. >>> >>> * updates the Tor URLs, but does NOT flip the two references suggested in Gen-ART to Normative; as per subsequent discussion, they aren't necessary to register the TLD, merely informative. Please advise if I read that wrong. >>> >>> * moves much of the generic explanatory text from Security Considerations into the Introduction, as per the SecDir review. >>> >>> * notes what happens when legacy systems get DNS queries leaked to them, as per the SecDir review. >>> >>> * I didn't yet do anything to address this feedback in the SecDir review: >>> >>>> Then, the security section also does not discuss how malicious name resolvers could be deployed in order to attack the TOR network. For example, if TOR security relies on DNS servers “black holing” misrouted request to resolve “.onion” names, what happens if malicious servers replace the suggested black-holing with some malicious tampering? >>> >>> Christian, how would that work? I don't see how this kind of attack (by having a malicious server leverage clients who erroneously forward DNS requests for .onion) is going to be qualitatively different from any other attack on the Tor network; indeed, it doesn't seem like a very effective way to attack the network itself. Now, it may be that you can trick some users into thinking they're on Tor when they're not, in the right circumstances, but that's not an attack on the network. >>> >>> Can you give some more detail here (or ideally some suggested text)? >>> >>> Cheers, >>> >>> >>> >>>> On 30 Aug 2015, at 7:16 am, joel jaeggli wrote: >>>> >>>> On 8/29/15 3:10 AM, Mark Nottingham wrote: >>>> >>>>> If the IESG would like to set a clear, unambiguous policy about this, >>>>> I'm sure it would be welcomed; personally, I've heard advice both >>>>> ways, and have not yet figured out how to make everyone happy. >>>> >>>> Well... you can ask me. imho the situation looks like the following to me. >>>> >>>> I think it's fine to have the discussion, propose the updates and hold >>>> the draft update till the end; or to roll a new version as the product >>>> of the discussion. The former runs the risk of accumulating a discuss >>>> either from me or from another AD due to something that "really needs to >>>> be addressed" prior to exit from iesg review. the later that we need >>>> more time, if it comes shortly before thursday. ( the call is now at >>>> 0700 pacific) so it's extremely unlikely that I will manange to >>>> re-review something submitted late wednesday evening. >>>> >>>> I'm kind of waiting on the update to the iana language I asked for on >>>> 8/15 and that is a barrier to publication, but I expect we know what >>>> it's going to say in that respect already so I'm not going to hold up >>>> the dicussion on that... >>>> >>>> thanks >>>> joel >>>> >>>>> Cheers, >>>>> >>>>> -- Mark Nottingham https://www.mnot.net/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Tue Sep 1 04:37:07 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4131B781C; Tue, 1 Sep 2015 04:37:05 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 faxjh5mhpzUc; Tue, 1 Sep 2015 04:37:03 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 881841B780F; Tue, 1 Sep 2015 04:37:03 -0700 (PDT) Received: by qgz60 with SMTP id 60so33359205qgz.2; Tue, 01 Sep 2015 04:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tOxF5GVz5Sb51+DZQdtGBKzfeFhpKSqGlhMd2awtTCM=; b=IXG8NIs3v+L43sWcMMgOYQ2/6h7+VfVLTmP635SJ8XgFdVYZfw7/Qvh8VgJ8sTfqMo 5zQfR6KOYoo2nuQhW2lTZdmJom6UyG/MK0FAZNm6b92gADRXXRnEPK1eQQui5FwkRQft aoWpRQOzjRPljkTjWJt9x3ZbnLu4LJbc9Nw1PSvY6DieduVRfhNZXQiYtdtRQDv0tkqj TD8hJS3lv20dGY/NLG/B73uyP6RlM0FL1Ai/fiKmSt5jPbSk1NdeY6uwoULPnwZhJT6H pGdj72uVCEasRkWujNtCP0CWrKSj2uqnqVZr/LM6jpVX7HlFO4Vy42t1sr3NnDZNTFKo Mgiw== X-Received: by 10.140.235.14 with SMTP id g14mr48458264qhc.5.1441107422713; Tue, 01 Sep 2015 04:37:02 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id 78sm10559565qhh.27.2015.09.01.04.37.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Sep 2015 04:37:01 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <55E570E6.4090603@cs.tcd.ie> Date: Tue, 1 Sep 2015 07:36:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05AC4751-6317-4EB6-BFF7-1C822B8D44BB@gmail.com> References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> <55E22119.9080106@bogus.com> <55E414D7.3070600@cs.tcd.ie> <371BFDC3-19C6-4B5F-AA49-525DBA26EA67@mnot.net> <55E570E6.4090603@cs.tcd.ie> To: Stephen Farrell Archived-At: Cc: secdir , Alec Muffett , joel jaeggli , Mark Nottingham , "draft-ietf-dnsop-onion-tld.all@tools.ietf.org" , The IESG , Brad Hill , Barry Leiba Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 11:37:05 -0000 I still have the outstanding question on security properties that may be bur= ied in this thread. Thanks, Kathleen=20 Sent from my iPhone > On Sep 1, 2015, at 5:33 AM, Stephen Farrell wr= ote: >=20 >=20 >=20 >> On 01/09/15 09:35, Mark Nottingham wrote: >> Hey Stephen, >>=20 >>> On 31 Aug 2015, at 6:48 pm, Stephen Farrell w= rote: >>>=20 >>>=20 >>> Hi Mark, >>>=20 >>> I thought there was also to be a change to say that .onion names would >>> in future need to continue to adhere to the DNS name syntax (lengths >>> mainly) just so that we don't get more ickkiness when/if .onion names >>> are handled by code expecting DNS names? >>>=20 >>> That wasn't from the secdir review but came up in the general IETF >>> list discussion in the last call. >>=20 >> See: >> https://github.com/mnot/I-D/commit/3b691672b94455f2038353ae03c04c3b10011= 93d >>=20 >> Note that I just stole that text out of RFC3986. If there's a better way t= o do it, I'm all ears. >=20 > I think that's a fine change and reflects the list > discussion perfectly. >=20 > Ta, > S. >=20 >=20 >>=20 >> Cheers, >>=20 >>=20 >>=20 >>>=20 >>> S. >>>=20 >>>> On 31/08/15 08:58, Mark Nottingham wrote: >>>> Attempting to address all of the outstanding feedback I've seen: >>>>=20 >>>> * uses .onion "names" instead of "addresses" consistently. >>>>=20 >>>> * clarifies the requirements placed upon registrars, as per the IANA r= eview. >>>>=20 >>>> * updates the Tor URLs, but does NOT flip the two references suggeste= d in Gen-ART to Normative; as per subsequent discussion, they aren't necessa= ry to register the TLD, merely informative. Please advise if I read that wro= ng. >>>>=20 >>>> * moves much of the generic explanatory text from Security Considerat= ions into the Introduction, as per the SecDir review.=20 >>>>=20 >>>> * notes what happens when legacy systems get DNS queries leaked to th= em, as per the SecDir review. >>>>=20 >>>> * I didn't yet do anything to address this feedback in the SecDir revie= w: >>>>=20 >>>>> Then, the security section also does not discuss how malicious name re= solvers could be deployed in order to attack the TOR network. For example, i= f TOR security relies on DNS servers =E2=80=9Cblack holing=E2=80=9D misroute= d request to resolve =E2=80=9C.onion=E2=80=9D names, what happens if malicio= us servers replace the suggested black-holing with some malicious tampering?= >>>>=20 >>>> Christian, how would that work? I don't see how this kind of attack (by= having a malicious server leverage clients who erroneously forward DNS requ= ests for .onion) is going to be qualitatively different from any other attac= k on the Tor network; indeed, it doesn't seem like a very effective way to a= ttack the network itself. Now, it may be that you can trick some users into t= hinking they're on Tor when they're not, in the right circumstances, but tha= t's not an attack on the network.=20 >>>>=20 >>>> Can you give some more detail here (or ideally some suggested text)? >>>>=20 >>>> Cheers, >>>>=20 >>>>=20 >>>>=20 >>>>> On 30 Aug 2015, at 7:16 am, joel jaeggli wrote: >>>>>=20 >>>>> On 8/29/15 3:10 AM, Mark Nottingham wrote: >>>>>=20 >>>>>> If the IESG would like to set a clear, unambiguous policy about this,= >>>>>> I'm sure it would be welcomed; personally, I've heard advice both >>>>>> ways, and have not yet figured out how to make everyone happy. >>>>>=20 >>>>> Well... you can ask me. imho the situation looks like the following to= me. >>>>>=20 >>>>> I think it's fine to have the discussion, propose the updates and hold= >>>>> the draft update till the end; or to roll a new version as the product= >>>>> of the discussion. The former runs the risk of accumulating a discuss >>>>> either from me or from another AD due to something that "really needs t= o >>>>> be addressed" prior to exit from iesg review. the later that we need >>>>> more time, if it comes shortly before thursday. ( the call is now at >>>>> 0700 pacific) so it's extremely unlikely that I will manange to >>>>> re-review something submitted late wednesday evening. >>>>>=20 >>>>> I'm kind of waiting on the update to the iana language I asked for on >>>>> 8/15 and that is a barrier to publication, but I expect we know what >>>>> it's going to say in that respect already so I'm not going to hold up >>>>> the dicussion on that... >>>>>=20 >>>>> thanks >>>>> joel >>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> -- Mark Nottingham https://www.mnot.net/ >>>>=20 >>>> -- >>>> Mark Nottingham https://www.mnot.net/ >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 From nobody Tue Sep 1 06:58:48 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257E51B57F4 for ; Tue, 1 Sep 2015 06:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 EDFujUNNsR8n for ; Tue, 1 Sep 2015 06:58:45 -0700 (PDT) Received: from xsmtp06.mail2web.com (xsmtp26.mail2web.com [168.144.250.193]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A751B31F2 for ; Tue, 1 Sep 2015 06:58:45 -0700 (PDT) Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ZWm5A-0003SQ-GJ for secdir@ietf.org; Tue, 01 Sep 2015 09:58:44 -0400 Received: (qmail 18284 invoked from network); 1 Sep 2015 13:58:39 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Sep 2015 13:58:38 -0000 From: "Christian Huitema" To: "'Kathleen Moriarty'" , "'Stephen Farrell'" References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> <55E22119.9080106@bogus.com> <55E414D7.3070600@cs.tcd.ie> <371BFDC3-19C6-4B5F-AA49-525DBA26EA67@mnot.net> <55E570E6.4090603@cs.tcd.ie> <05AC4751-6317-4EB6-BFF7-1C822B8D44BB@gmail.com> In-Reply-To: <05AC4751-6317-4EB6-BFF7-1C822B8D44BB@gmail.com> Date: Tue, 1 Sep 2015 06:58:42 -0700 Message-ID: <00be01d0e4be$50fcac40$f2f604c0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI50R8PuDN5FgYzzyJG3m5SgMEMYAJVzMtaAgL9VGEBO6r6yQGDmJGEAalbUnsCAexJawG5pZLqAhMpnEQCU8+F4QJR/RDBAqv/AJ2cpshQIA== Content-Language: en-us Archived-At: Cc: 'secdir' , 'Alec Muffett' , 'joel jaeggli' , 'Mark Nottingham' , draft-ietf-dnsop-onion-tld.all@tools.ietf.org, 'Brad Hill' , 'The IESG' , 'Barry Leiba' Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 13:58:46 -0000 On Tuesday, September 1, 2015 4:37 AM, Kathleen Moriarty wrote: >=20 > I still have the outstanding question on security properties that may = be buried > in this thread. The question was, how could malicious DNS agents trick TOR clients into = disclosing their presence. The recent exchange with Mark was about such = agents passively listening for clients' mistakes. Is there a way to = actively trigger such mistakes? Such attacks would require actively sending information to clients, such = as "if you have a request for example.onion, send it to me." The way to = do that in the DNS is through NS records. Malicious agents could send an = NS record for ".onion" as additional record in a response, asking = resolvers to send them such traffic. This might trick legacy clients. = Maybe. -- Christian Huitema From nobody Tue Sep 1 07:07:45 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5FC1B3768; Tue, 1 Sep 2015 07:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_75=0.6, SPF_PASS=-0.001] autolearn=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 PosElWxr5G-5; Tue, 1 Sep 2015 07:07:44 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 CEA011A0369; Tue, 1 Sep 2015 07:07:43 -0700 (PDT) Received: by wiclp12 with SMTP id lp12so32202305wic.1; Tue, 01 Sep 2015 07:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eg++FvuKK4ocqMiuBkiqY4377Og/6zPXHGIn7fOR7Po=; b=ju7Qbwt7PB4N13wTvsv8n5muiQIFeqxDfyEC2Iouwp5E1VKPQMJF0iMiW6hOGr+HCr VspjwdVF51kt6quSILhVCn6UzsM+i/Ulij4u7f+1YQmkKyIG8x/00AScuxQpJyayuMc2 Iyw3duCi+Ywmx1mAXNd6uA8YOnQoah2f3Qjf5+Cs2pCYoIOwmiFSMSVw0Meop7vURVYh bKToZqyKH8UkOQwTtNs9Zc/YJwS8VngeUEr+EarmOEp2PSw6e2+OXbAQ0BDngWxtG/l8 jL2EMTdMwkT7svEaGHvsPBrGU4bPpgcZ4j5gvHBCW2RUuMYeNz9i5wxHZd6uTKLqgGUa c9/g== MIME-Version: 1.0 X-Received: by 10.180.73.229 with SMTP id o5mr3466401wiv.36.1441116461816; Tue, 01 Sep 2015 07:07:41 -0700 (PDT) Received: by 10.28.157.84 with HTTP; Tue, 1 Sep 2015 07:07:41 -0700 (PDT) In-Reply-To: <00be01d0e4be$50fcac40$f2f604c0$@huitema.net> References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> <55E22119.9080106@bogus.com> <55E414D7.3070600@cs.tcd.ie> <371BFDC3-19C6-4B5F-AA49-525DBA26EA67@mnot.net> <55E570E6.4090603@cs.tcd.ie> <05AC4751-6317-4EB6-BFF7-1C822B8D44BB@gmail.com> <00be01d0e4be$50fcac40$f2f604c0$@huitema.net> Date: Tue, 1 Sep 2015 10:07:41 -0400 Message-ID: From: Kathleen Moriarty To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: secdir , Alec Muffett , joel jaeggli , Mark Nottingham , draft-ietf-dnsop-onion-tld.all@tools.ietf.org, Brad Hill , The IESG , Barry Leiba Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 14:07:45 -0000 On Tue, Sep 1, 2015 at 9:58 AM, Christian Huitema wro= te: > On Tuesday, September 1, 2015 4:37 AM, Kathleen Moriarty wrote: >> >> I still have the outstanding question on security properties that may be= buried >> in this thread. > > The question was, how could malicious DNS agents trick TOR clients into d= isclosing their presence. The recent exchange with Mark was about such agen= ts passively listening for clients' mistakes. Is there a way to actively tr= igger such mistakes? > > Such attacks would require actively sending information to clients, such = as "if you have a request for example.onion, send it to me." The way to do = that in the DNS is through NS records. Malicious agents could send an NS re= cord for ".onion" as additional record in a response, asking resolvers to s= end them such traffic. This might trick legacy clients. Maybe. > > -- Christian Huitema > > > My outstanding question is in my message from Aug 30th on Section 2 text that I think needs further clarification since the first bullet makes a broad statement without naming the security properties people are supposed to recognize. Here is the snippet from that message (similar to a point made by Alvaro as well): > That would seem doable, if something sufficiently brief can be constructe= d, > because much of the actual mechanism which should lead to the desired > behaviour is described in Section 2 of the draft, the elements of which a= re > heavily modeled upon the examples provided in RFC6761. > It's fine to have them in section 2. When I read through them again, what are the special security properties that users and applications should recognize that are mentioned in the first bullet? Are these properties provided through the subsequent bullets handling requirements? I'm guessing that's the case, but since they are not sub-bullets, I'm not sure. It would be good to clarify this text to list the properties and to see how the first bullet relates to the subsequent bullets. --=20 Best regards, Kathleen From nobody Tue Sep 1 07:11:04 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384D31A019B; Tue, 1 Sep 2015 07:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 d7_ikcEl_paa; Tue, 1 Sep 2015 07:11:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8721A01D8; Tue, 1 Sep 2015 07:10:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXA29135; Tue, 01 Sep 2015 14:10:57 +0000 (GMT) Received: from SZXEML429-HUB.china.huawei.com (10.82.67.184) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Sep 2015 15:10:54 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.212]) by SZXEML429-HUB.china.huawei.com ([10.82.67.184]) with mapi id 14.03.0235.001; Tue, 1 Sep 2015 22:09:56 +0800 From: Tina TSOU To: "secdir@ietf.org" , "draft-ietf-mpls-tp-oam-id-mib.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-mpls-tp-oam-id-mib-08 Thread-Index: AQHQ5L/gEot3P+eKLk6oIdN2iw08Qg== Date: Tue, 1 Sep 2015 14:09:55 +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: [10.46.126.124] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A818DAD4F1szxeml557mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: The IESG Subject: [secdir] Secdir review of draft-ietf-mpls-tp-oam-id-mib-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 14:11:02 -0000 --_000_C0E0A32284495243BDE0AC8A066631A818DAD4F1szxeml557mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhl IHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRG IGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlIGNvbW1lbnRzIHdl cmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVh IGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0 aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0K VGhlIGRvY3VtZW50IHNlZW1zIHJlYWR5IHRvIGdvLiBJIG9ubHkgZm91bmQgdGhlc2UgbWlub3Ig bml0czoNCg0KVGhlIHRpdGxlIG9mIHRoaXMgZHJhZnQgaW5kaWNhdGVzIG1pYiBmb3IgTVBMUy1U UCBPQU0gSUQgYnV0IGluIHRoZSBib2R5IE1QTFMgaXMgdXNlZCBtb3N0bHkgYW5kIHNvbWV0aW1l cyBNUExTLVRQIGFwcGVhcnMsIGZvciBleGFtcGxlLCBib3RoIE1QTFMgdHVubmVscyBhbmQgTVBM Uy1UUCB0dW5uZWxzIGFyZSBtZW50aW9uZWQuIEknbSBub3Qgc3VyZSBpZiB0aGV5IGNhbiBiZSB1 c2VkIGludGVyY2hhbmdlYWJsZS4gQmVzaWRlcywgSSBub3RpY2UgdGhhdCB0aGUgbmFtZXMgZm9y IHRoZSBvYmplY3RzIGFsbCBzdGFydCB3aXRoICJtcGxzb2FtaWR4eHgiLCB3aGljaCBzZWVtcyB0 byBhZGRyZXNzIG1pYiBmb3IgTVBMUyBPQU0gSUQuIFRoZW4gaXQgaXMgbm90IGFsaWduZWQgd2l0 aCB0aGUgdGl0bGUgb2YgdGhpcyBkcmFmdC4gQSBiaXQgY29uZnVzZWQuIENvdWxkIHRoZSBhdXRo b3JzIHByb3ZpZGUgYW55IGNsYXJpZmljYXRpb24gb24gdGhpcz8gQSBnZW5lcmFsIHN1Z2dlc3Rp b24gaXMgdG8gbWFrZSBhbGlnbm1lbnQgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQsIGluY2x1ZGlu ZyB0aGUgdGl0bGUgb2YgdGhlIGRyYWZ0Lg0KDQoqIEFic3RyYWN0Og0KDQo+IGl0IGRlc2NyaWJl cyBPcGVyYXRpb25zLCBBZG1pbmlzdHJhdGlvbiwgYW5kIE1hbmFnZW1lbnQgKE9BTSkNCj4gaWRl bnRpZmllcnMgcmVsYXRlZCBtYW5hZ2VkIG9iamVjdHMgZm9yIE11bHRpcHJvdG9jb2wgTGFiZWwg U3dpdGNoaW5nDQo+IChNUExTKSBhbmQgTVBMUyBiYXNlZCBUcmFuc3BvcnQgUHJvZmlsZSAoVFAp Lg0KDQpJIGZpbmQgdGhpcyBzZW50ZW5jZSBoYXJkIHRvIHBhcnNlLiBNYXliZSBzL3JlbGF0ZWQg bWFuYWdlZCBvYmplY3RzL3JlbGF0ZWQgdG8gbWFuYWdlZCBvYmplY3RzLyA/DQoNCg0KKiBTZWN0 aW9uIDEsIHBhZ2UgMzoNCj4gTVBMUyBMU1AoTGFiZWwNCg0KVGhlcmUncyBhIG1pc3Npbmcgc3Bh Y2UuDQoNCg0KKiBTZWN0aW9uIDUuMSwgcGFnZSA0Og0KDQo+IFRoZSBtcGxzT2FtSWRNZWdUYWJs ZSBpcyB1c2VkIHRvIG1hbmFnZSBvbmUgb3IgbW9yZSBNYWludGVuYW5jZQ0KPiBFbnRpdGllcyAo TUVzKSB0aGF0IGJlbG9uZ3MNCg0Kcy9iZWxvbmdzL2JlbG9uZy8NCg0KDQoqIFNlY3Rpb24gNiwg Y29weSZwYXN0ZSBtaXN0YWtlDQoNCi0tIFNvdXJjZSBNRVAgaWQgaXMgZGVyaXZlZCBmcm9tIHRo ZSBJUCBjb21wYXRpYmxlIE1QTFMgTFNQDQogICAgICAgbXBsc09hbUlkTWVTaW5rTWVwSW5kZXgg ICAgICAgICAgID0gMCwNCg0KVGhlIGRlc2NyaXB0aW9uIGluIHRoZSBub3RlIHNob3VsZCBiZSBz aW5rIE1FUC4gVGhlcmUgaXMgYWxyZWFkeSBhbm90aGVyIGxpbmUgdG8gZGVzY3JpYmUgc291cmNl IE1FUC4NCg0KDQoqIFBhZ2UgMTU6DQoNCj4gQkZEDQoNClRoaXMgaXMgdGhlIGZpcnN0IGFuZCBv bmx5IGluc3RhbmNlIG9mIEJGRC4gUGxlYXNlIGV4cGFuZC4gKGFuZCBtYXliZSByZWZlcmVuY2Ug UkZDNTg4MCk/DQoNCg0KKiBQYWdlIDE3Og0KDQoicDJwIiBhbmQgIlAyUCIgZmlyc3QgdXNlZCBo ZXJlLiBzaG91bGQgcHJvYmFibHkgYmUgZXhwYW5kZWQuDQoNCg0KVGhhbmsgeW91LA0KVGluYQ0K DQo= --_000_C0E0A32284495243BDE0AC8A066631A818DAD4F1szxeml557mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxsLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRo ZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVU RiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21tZW50cw0K IHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBh cmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVh dCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBkb2N1 bWVudCBzZWVtcyByZWFkeSB0byBnby4gSSBvbmx5IGZvdW5kIHRoZXNlIG1pbm9yIG5pdHM6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGUgdGl0bGUgb2YgdGhpcyBkcmFmdCBpbmRpY2F0ZXMgbWliIGZvciBNUExTLVRQ IE9BTSBJRCBidXQgaW4gdGhlIGJvZHkgTVBMUyBpcyB1c2VkIG1vc3RseSBhbmQgc29tZXRpbWVz IE1QTFMtVFAgYXBwZWFycywgZm9yIGV4YW1wbGUsIGJvdGggTVBMUyB0dW5uZWxzIGFuZA0KIE1Q TFMtVFAgdHVubmVscyBhcmUgbWVudGlvbmVkLiBJJ20gbm90IHN1cmUgaWYgdGhleSBjYW4gYmUg dXNlZCBpbnRlcmNoYW5nZWFibGUuIEJlc2lkZXMsIEkgbm90aWNlIHRoYXQgdGhlIG5hbWVzIGZv ciB0aGUgb2JqZWN0cyBhbGwgc3RhcnQgd2l0aCAmcXVvdDttcGxzb2FtaWR4eHgmcXVvdDssIHdo aWNoIHNlZW1zIHRvIGFkZHJlc3MgbWliIGZvciBNUExTIE9BTSBJRC4gVGhlbiBpdCBpcyBub3Qg YWxpZ25lZCB3aXRoIHRoZSB0aXRsZSBvZiB0aGlzIGRyYWZ0Lg0KIEEgYml0IGNvbmZ1c2VkLiBD b3VsZCB0aGUgYXV0aG9ycyBwcm92aWRlIGFueSBjbGFyaWZpY2F0aW9uIG9uIHRoaXM/IEEgZ2Vu ZXJhbCBzdWdnZXN0aW9uIGlzIHRvIG1ha2UgYWxpZ25tZW50IHRocm91Z2hvdXQgdGhlIGRvY3Vt ZW50LCBpbmNsdWRpbmcgdGhlIHRpdGxlIG9mIHRoZSBkcmFmdC48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KiBBYnN0cmFjdDo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZndDsgaXQgZGVzY3JpYmVzIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBhbmQg TWFuYWdlbWVudCAoT0FNKQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgaWRl bnRpZmllcnMgcmVsYXRlZCBtYW5hZ2VkIG9iamVjdHMgZm9yIE11bHRpcHJvdG9jb2wgTGFiZWwg U3dpdGNoaW5nDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OyAoTVBMUykgYW5k IE1QTFMgYmFzZWQgVHJhbnNwb3J0IFByb2ZpbGUgKFRQKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZmluZCB0aGlz IHNlbnRlbmNlIGhhcmQgdG8gcGFyc2UuIE1heWJlIHMvcmVsYXRlZCBtYW5hZ2VkIG9iamVjdHMv cmVsYXRlZCB0byBtYW5hZ2VkIG9iamVjdHMvID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4qIFNlY3Rpb24gMSwgcGFnZSAzOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mZ3Q7IE1QTFMgTFNQKExhYmVsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZSdzIGEgbWlz c2luZyBzcGFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4qIFNlY3Rpb24gNS4xLCBwYWdlIDQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7IFRoZSBtcGxzT2FtSWRNZWdU YWJsZSBpcyB1c2VkIHRvIG1hbmFnZSBvbmUgb3IgbW9yZSBNYWludGVuYW5jZQ0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgRW50aXRpZXMgKE1FcykgdGhhdCBiZWxvbmdzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5zL2JlbG9uZ3MvYmVsb25nLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiogU2VjdGlvbiA2LCBjb3B5JmFtcDtwYXN0ZSBtaXN0YWtlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4tLSBTb3VyY2UgTUVQIGlkIGlzIGRlcml2ZWQgZnJvbSB0aGUgSVAgY29tcGF0aWJsZSBN UExTIExTUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgbXBsc09hbUlkTWVTaW5rTWVwSW5kZXgmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPSAwLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhlIGRlc2NyaXB0aW9uIGluIHRoZSBub3RlIHNob3VsZCBiZSBzaW5rIE1FUC4gVGhlcmUg aXMgYWxyZWFkeSBhbm90aGVyIGxpbmUgdG8gZGVzY3JpYmUgc291cmNlIE1FUC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4qIFBhZ2UgMTU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mZ3Q7IEJGRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyB0aGUgZmlyc3QgYW5kIG9ubHkgaW5zdGFuY2Ug b2YgQkZELiBQbGVhc2UgZXhwYW5kLiAoYW5kIG1heWJlIHJlZmVyZW5jZSBSRkM1ODgwKT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4qIFBhZ2UgMTc6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mcXVvdDtwMnAmcXVvdDsgYW5kICZxdW90O1AyUCZxdW90OyBmaXJzdCB1c2VkIGhl cmUuIHNob3VsZCBwcm9iYWJseSBiZSBleHBhbmRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRpbmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_C0E0A32284495243BDE0AC8A066631A818DAD4F1szxeml557mbschi_-- From nobody Tue Sep 1 10:25:35 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9801A1B4A2D for ; Tue, 1 Sep 2015 10:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 pQ-_SY12OtpV for ; Tue, 1 Sep 2015 10:25:31 -0700 (PDT) Received: from xsmtp05.mail2web.com (xsmtp05.mail2web.com [168.144.250.245]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B671B5679 for ; Tue, 1 Sep 2015 10:25:07 -0700 (PDT) Received: from [10.5.2.11] (helo=xmail01.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ZWpIv-0005hj-KL for secdir@ietf.org; Tue, 01 Sep 2015 13:25:06 -0400 Received: (qmail 17575 invoked from network); 1 Sep 2015 17:25:04 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[131.107.192.88]) (envelope-sender ) by xmail01.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Sep 2015 17:25:03 -0000 From: "Christian Huitema" To: "'Kathleen Moriarty'" , "'Stephen Farrell'" References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> <55E22119.9080106@bogus.com> <55E414D7.3070600@cs.tcd.ie> <371BFDC3-19C6-4B5F-AA49-525DBA26EA67@mnot.net> <55E570E6.4090603@cs.tcd.ie> <05AC4751-6317-4EB6-BFF7-1C822B8D44BB@gmail.com> <00be01d0e4be$50fcac40$f2f604c0$@huitema.net> In-Reply-To: <00be01d0e4be$50fcac40$f2f604c0$@huitema.net> Date: Tue, 1 Sep 2015 10:25:07 -0700 Message-ID: <00f601d0e4db$26c4b220$744e1660$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI50R8PuDN5FgYzzyJG3m5SgMEMYAJVzMtaAgL9VGEBO6r6yQGDmJGEAalbUnsCAexJawG5pZLqAhMpnEQCU8+F4QJR/RDBAqv/AJ0CWLLcdJyUOwNw Content-Language: en-us Archived-At: Cc: 'secdir' , 'Alec Muffett' , 'joel jaeggli' , 'Mark Nottingham' , draft-ietf-dnsop-onion-tld.all@tools.ietf.org, 'Brad Hill' , 'The IESG' , 'Barry Leiba' Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 17:25:32 -0000 On Tuesday, September 1, 2015 6:59 AM, Christian Huitema wrote: > > On Tuesday, September 1, 2015 4:37 AM, Kathleen Moriarty wrote: > > > > I still have the outstanding question on security properties that may be > buried > > in this thread. > > The question was, how could malicious DNS agents trick TOR clients into > disclosing their presence. The recent exchange with Mark was about such > agents passively listening for clients' mistakes. Is there a way to actively > trigger such mistakes? > > Such attacks would require actively sending information to clients, such as "if > you have a request for example.onion, send it to me." The way to do that in > the DNS is through NS records. Malicious agents could send an NS record for > ".onion" as additional record in a response, asking resolvers to send them such > traffic. This might trick legacy clients. Maybe. Thinking about this a bit more -- this is the general problem of cache poisoning. The additional section could also include A or AAAA records for .onion domains. This could fool a caching resolver -- receive a request for a name, check first if there is an exact match in the cache, and only attempt to forward the request if there is no hit in the cache. The checks in the draft are only considering request forwarding, not cache operation. What about adding this text to cover the malicious server attack -- coming after the paragraph on leaks by the legacy clients: >>> Malicious DNS agents could insert records for ".onion" names in the additional section of DNS responses, with the intent of poisoning the cache of DNS resolvers. These resolvers could then be tricked into serving the record from their cache, bypassing the checks described in section 2. To mitigate such attacks, it is important that caching resolvers prevent the insertion in their caches of records for ".onion" names. <<< You may actually want to add part of that text in section 2. -- Christian Huitema From nobody Tue Sep 1 16:55:49 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170C51B5063; Tue, 1 Sep 2015 16:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 DW68M-mCCa3E; Tue, 1 Sep 2015 16:55:42 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791EB1B5054; Tue, 1 Sep 2015 16:55:42 -0700 (PDT) Received: from [192.168.0.3] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id ABA4322E273; Tue, 1 Sep 2015 19:55:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: Date: Wed, 2 Sep 2015 09:55:29 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <65D73339-F470-4D78-89CD-907E76B229B0@mnot.net> References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> <55E22119.9080106@bogus.com> <55E414D7.3070600@cs.tcd.ie> <371BFDC3-19C6-4B5F-AA49-525DBA26EA67@mnot.net> <55E570E6.4090603@cs.tcd.ie> <05AC4751-6317-4EB6-BFF7-1C822B8D44BB@gmail.com> <00be01d0e4be$50fcac40$f2f604c0$@huitema.net> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2104) Archived-At: Cc: secdir , Alec Muffett , joel jaeggli , draft-ietf-dnsop-onion-tld.all@tools.ietf.org, The IESG , Brad Hill , Barry Leiba Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 23:55:45 -0000 See: = https://github.com/mnot/I-D/commit/f9975381389d556709cfe77a520eae73ace0659= c = https://github.com/mnot/I-D/commit/cb43f69aa37f94baeb78aa3eca368dd712a0615= 4 Do they suffice? The references were flipped to normative here: = https://github.com/mnot/I-D/commit/8486c73357b0421c013a6e99e90374c54190ce3= 6 With all changes to date incorporated: = http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.tx= t = http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.ht= ml Cheers, > On 2 Sep 2015, at 12:07 am, Kathleen Moriarty = wrote: >=20 > On Tue, Sep 1, 2015 at 9:58 AM, Christian Huitema = wrote: >> On Tuesday, September 1, 2015 4:37 AM, Kathleen Moriarty wrote: >>>=20 >>> I still have the outstanding question on security properties that = may be buried >>> in this thread. >>=20 >> The question was, how could malicious DNS agents trick TOR clients = into disclosing their presence. The recent exchange with Mark was about = such agents passively listening for clients' mistakes. Is there a way to = actively trigger such mistakes? >>=20 >> Such attacks would require actively sending information to clients, = such as "if you have a request for example.onion, send it to me." The = way to do that in the DNS is through NS records. Malicious agents could = send an NS record for ".onion" as additional record in a response, = asking resolvers to send them such traffic. This might trick legacy = clients. Maybe. >>=20 >> -- Christian Huitema >>=20 >>=20 >>=20 >=20 > My outstanding question is in my message from Aug 30th on Section 2 > text that I think needs further clarification since the first bullet > makes a broad statement without naming the security properties people > are supposed to recognize. Here is the snippet from that message > (similar to a point made by Alvaro as well): >=20 >> That would seem doable, if something sufficiently brief can be = constructed, >> because much of the actual mechanism which should lead to the desired >> behaviour is described in Section 2 of the draft, the elements of = which are >> heavily modeled upon the examples provided in RFC6761. >>=20 >=20 > It's fine to have them in section 2. When I read through them again, > what are the special security properties that users and applications > should recognize that are mentioned in the first bullet? Are these > properties provided through the subsequent bullets handling > requirements? I'm guessing that's the case, but since they are not > sub-bullets, I'm not sure. >=20 > It would be good to clarify this text to list the properties and to > see how the first bullet relates to the subsequent bullets. > --=20 >=20 > Best regards, > Kathleen -- Mark Nottingham https://www.mnot.net/ From nobody Tue Sep 1 18:44:57 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5851B35BC; Tue, 1 Sep 2015 18:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 cfpSvp5ge4CZ; Tue, 1 Sep 2015 18:44:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214091B340E; Tue, 1 Sep 2015 18:44:52 -0700 (PDT) Received: from [192.168.0.3] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2D40322E271; Tue, 1 Sep 2015 21:44:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <65D73339-F470-4D78-89CD-907E76B229B0@mnot.net> Date: Wed, 2 Sep 2015 11:44:42 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> <55E22119.9080106@bogus.com> <55E414D7.3070600@cs.tcd.ie> <371BFDC3-19C6-4B5F-AA49-525DBA26EA67@mnot.net> <55E570E6.4090603@cs.tcd.ie> <05AC4751-6317-4EB6-BFF7-1C822B8D44BB@gmail.com> <00be01d0e4be$50fcac40$f2f604c0$@huitema.net> <65D73339-F470-4D78-89CD-907E76B229B0@mnot.net> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2104) Archived-At: Cc: secdir , Alec Muffett , joel jaeggli , draft-ietf-dnsop-onion-tld.all@tools.ietf.org, The IESG , Brad Hill , Barry Leiba Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 01:44:54 -0000 Diff URL for the curious: = http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=3Dhttps://www.ietf.org/id/dr= aft-ietf-dnsop-onion-tld-00.txt&url2=3Dhttp://mnot.github.io/I-D/dnsop-oni= on-tld/draft-ietf-dnsop-onion-tld-01.txt Cheers, > On 2 Sep 2015, at 9:55 am, Mark Nottingham wrote: >=20 > See: > = https://github.com/mnot/I-D/commit/f9975381389d556709cfe77a520eae73ace0659= c > = https://github.com/mnot/I-D/commit/cb43f69aa37f94baeb78aa3eca368dd712a0615= 4 > Do they suffice? >=20 > The references were flipped to normative here: > = https://github.com/mnot/I-D/commit/8486c73357b0421c013a6e99e90374c54190ce3= 6 >=20 > With all changes to date incorporated: > = http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.tx= t > = http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.ht= ml >=20 > Cheers, >=20 >> On 2 Sep 2015, at 12:07 am, Kathleen Moriarty = wrote: >>=20 >> On Tue, Sep 1, 2015 at 9:58 AM, Christian Huitema = wrote: >>> On Tuesday, September 1, 2015 4:37 AM, Kathleen Moriarty wrote: >>>>=20 >>>> I still have the outstanding question on security properties that = may be buried >>>> in this thread. >>>=20 >>> The question was, how could malicious DNS agents trick TOR clients = into disclosing their presence. The recent exchange with Mark was about = such agents passively listening for clients' mistakes. Is there a way to = actively trigger such mistakes? >>>=20 >>> Such attacks would require actively sending information to clients, = such as "if you have a request for example.onion, send it to me." The = way to do that in the DNS is through NS records. Malicious agents could = send an NS record for ".onion" as additional record in a response, = asking resolvers to send them such traffic. This might trick legacy = clients. Maybe. >>>=20 >>> -- Christian Huitema >>>=20 >>>=20 >>>=20 >>=20 >> My outstanding question is in my message from Aug 30th on Section 2 >> text that I think needs further clarification since the first bullet >> makes a broad statement without naming the security properties people >> are supposed to recognize. Here is the snippet from that message >> (similar to a point made by Alvaro as well): >>=20 >>> That would seem doable, if something sufficiently brief can be = constructed, >>> because much of the actual mechanism which should lead to the = desired >>> behaviour is described in Section 2 of the draft, the elements of = which are >>> heavily modeled upon the examples provided in RFC6761. >>>=20 >>=20 >> It's fine to have them in section 2. When I read through them again, >> what are the special security properties that users and applications >> should recognize that are mentioned in the first bullet? Are these >> properties provided through the subsequent bullets handling >> requirements? I'm guessing that's the case, but since they are not >> sub-bullets, I'm not sure. >>=20 >> It would be good to clarify this text to list the properties and to >> see how the first bullet relates to the subsequent bullets. >> --=20 >>=20 >> Best regards, >> Kathleen >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Sep 2 04:36:46 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689861A1B25; Wed, 2 Sep 2015 04:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 QbHP_g7ij6qm; Wed, 2 Sep 2015 04:36:39 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D636C1B3054; Wed, 2 Sep 2015 04:36:39 -0700 (PDT) Received: from pps.filterd (m0044012 [127.0.0.1]) by mx0a-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id t82BaTju008166; Wed, 2 Sep 2015 04:36:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=rWfe4oIjeMfdNZOt2mZEGbHi4QUWrU2Mv+yoOcv3lX8=; b=R5dFVORoEqS5jjzuMWytJkKL80JiHhcFY6+qtI96qFfxkZMbTUIywiuLdAmu3myN3v+S hjHyQHk83CtsauEUFist5zrxL0P2Fi/EMedVxq1mWNk+X2Zerz2HBU9WKxhHddswwXG+ VnuRUxUWrhJb7lRrGv3SnrOXoY2cqOksIvw= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 1wnv05rfaj-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 02 Sep 2015 04:36:29 -0700 Received: from PRN-MBX02-4.TheFacebook.com ([169.254.2.38]) by PRN-CHUB14.TheFacebook.com ([fe80::5977:3d0b:700b:8bb%12]) with mapi id 14.03.0248.002; Wed, 2 Sep 2015 04:36:27 -0700 From: Alec Muffett To: Kathleen Moriarty Thread-Topic: Security review of draft-ietf-dnsop-onion-tld-00.txt Thread-Index: AdDCwrgI+PKUtFTlQwu24Fnrr5jdagegWveAACR0AIAAAL0/gAABmQkAAHdoZIAAfFgpgA== Date: Wed, 2 Sep 2015 11:36:26 +0000 Message-ID: References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.54.13] Content-Type: multipart/signed; boundary="Apple-Mail=_97D5860A-8F01-4FD8-9B71-7B97329FDD78"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-02_06:2015-09-02,2015-09-02,1970-01-01 signatures=0 Archived-At: Cc: secdir , joel jaeggli , Mark Nottingham , "draft-ietf-dnsop-onion-tld.all@tools.ietf.org" , The IESG , Brad Hill Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 11:36:41 -0000 --Apple-Mail=_97D5860A-8F01-4FD8-9B71-7B97329FDD78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello All! Back from some manner of brief holiday, and I=E2=80=99ll try and pick up = some loose ends without treading on Mark=E2=80=99s epic work. >> The goal of leak-reduction is to reduce leaks, rather >> than to assure security. >=20 > Are there privacy considerations with leak reduction? Either leaks exist (likely) or they do not. It=E2=80=99s hard to = conceive of where a reduction in efficacy of leak-prevention would = benefit privacy, so onion-leak-reduction would seem to be one of those = things that can be classified as "net win at scale=E2=80=9D and the need = for it should reduce with time. >> Tor security does not rely on blackholing DNS requests, it relies = upon >> cryptographic technology. >>=20 >> Tools which are Tor-aware will not have the leakage problem. >=20 > OK, great, so I think just adding something on this point in the > security considerations would be good. We are fine on the other > points and I just have the question about security properties for > section 2. I think Mark=E2=80=99s revisions nail this with the =E2=80=9Clegacy = client=E2=80=9D paragraph. :-) I will skim the rest of the mails and try to consolidate the next = response, if any is required. -a --Apple-Mail=_97D5860A-8F01-4FD8-9B71-7B97329FDD78 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJV5t9JAAoJECldTB9TIAHG+RsP+wUabp3oD3B4fD3lE/Z2y665 lAH4ClFTRDZzm3+K0slkvDVv80OfObj4f5ZKPbB9arpVPu5fJhiTETXWc+tZuYbs u50smZ+SsPArqGoqQHwDKCqzwxEcOhBq361TCOVavPHf1qvvo0P3jW4k096S+AAt z1tudKeT9fkWFcycRVCYQcWRyDnEvZ7Z72Yr0dnZ1xTvSPtbFTCrZO0xO4E/y/XP 4s4bM2hVJk2k+3WiHV2zUPyoQPzLa7ttdWcF1VPIHzrd5QiVAN2lPyna7sXyOCDq l9auprCBxNlRKvD5JHaRUAJz8EfqN4n86dgEtvaNd+Rl0HOmeAnABnOO2kATKL8n arLaaEEYZJ6hxfjy8tQ0RuhCzqBzZDTFhh3jSfNGSiNjeUFLUEY4mpnpPcLvwOXE esfooYEVUXOs0FaTS+ltwgHdAkzPX62hIA77CZ7UQcqtZvfszEq5VG+0CTH0AI+b j3dwWdt688y4uXPvQGZzdlSR8awLhrhbPDMexeeldFZQzZSYy0yMZqauARKQJUr7 5C7UuhFTqPA5yDsRBGS+SqDqxHWbqGNpgcC/7iO+0lsmzJ8C/+qy2pC9xiDioYWw 5tMdvI3DOxtdMdmVoM98Ful7Ezi+md3zArFpgTCCfRHsQ3aPIoppfOtlixsW8xji MDP9wqnYs/7lLpBdPPUd =Eq7R -----END PGP SIGNATURE----- --Apple-Mail=_97D5860A-8F01-4FD8-9B71-7B97329FDD78-- From nobody Wed Sep 2 04:51:46 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBBB1ACEAD; Wed, 2 Sep 2015 04:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 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, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 nP7J_pET8hOb; Wed, 2 Sep 2015 04:51:44 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5BA1A8AF5; Wed, 2 Sep 2015 04:51:42 -0700 (PDT) Received: from pps.filterd (m0004347 [127.0.0.1]) by m0004347.ppops.net (8.14.5/8.14.5) with SMTP id t82BpYjc011822; Wed, 2 Sep 2015 04:51:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=6j3C8iXf33Kk6iFt88TiMQK0oo8Tfcv/mAHoixosJ5k=; b=IBJgDNb2Zsuj1c18HLjfJlno7Iy1v9uL/OpXQD+R+e7DgfWZeoiZFllw+sRdvv4Upax6 7JyuI91Hy76OS/8SN4KhfQ5Agfp1tr8lf8XAjtk3gvfi9dEyeuXREC6QljKkyhHl5H1F 481X/SZTTYkNlg+YDFddfbyfEQSSzpQoAg4= Received: from mail.thefacebook.com ([199.201.64.23]) by m0004347.ppops.net with ESMTP id 1wnrmvrsyn-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 02 Sep 2015 04:51:34 -0700 Received: from PRN-MBX02-4.TheFacebook.com ([169.254.2.38]) by PRN-CHUB08.TheFacebook.com ([fe80::c9c7:30fd:ad3:b94%12]) with mapi id 14.03.0248.002; Wed, 2 Sep 2015 04:51:33 -0700 From: Alec Muffett To: Kathleen Moriarty Thread-Topic: Security review of draft-ietf-dnsop-onion-tld-00.txt Thread-Index: AdDCwrgI+PKUtFTlQwu24Fnrr5jdagegWveAACR0AIAAAL0/gAABmQkAAHdoZIAAfFgpgAAAhtsA Date: Wed, 2 Sep 2015 11:51:32 +0000 Message-ID: References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.54.13] Content-Type: multipart/signed; boundary="Apple-Mail=_790B9BCC-A56D-4EB1-8BA5-69E7342AF6E9"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-02_06:2015-09-02,2015-09-02,1970-01-01 signatures=0 Archived-At: Cc: secdir , joel jaeggli , Mark Nottingham , "draft-ietf-dnsop-onion-tld.all@tools.ietf.org" , The IESG , Brad Hill Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 11:51:46 -0000 --Apple-Mail=_790B9BCC-A56D-4EB1-8BA5-69E7342AF6E9 Content-Type: multipart/alternative; boundary="Apple-Mail=_DDDA63C8-E1AE-4E73-8D73-1086E2E96429" --Apple-Mail=_DDDA63C8-E1AE-4E73-8D73-1086E2E96429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ah, apologies, I see that I have just been unclear: > On Sep 2, 2015, at 12:36 PM, Alec Muffett wrote: >=20 > I think Mark=E2=80=99s revisions nail this with the =E2=80=9Clegacy = client=E2=80=9D paragraph. :-) =E2=80=A6nails the =E2=80=9Cblackholing DNS=E2=80=9D matter with the = =E2=80=9Clegacy client=E2=80=9D paragraph. :-) I am quite confident that Mark=E2=80=99s latest diff: = http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=3Dhttps://www.ietf.org/id/dr= aft-ietf-dnsop-onion-tld-00.txt&url2=3Dhttp://mnot.github.io/I-D/dnsop-oni= on-tld/draft-ietf-dnsop-onion-tld-01.txt = =E2=80=A6covers the =E2=80=9Chuman factors=E2=80=9D element quite well. The primary risks to users of Onion names are: * prefix collision phishing such as facebookXXX.onion versus = facebookYYY.onion ** best mitigation: SSL, hence this draft ** documented Users must take special precautions to ensure that the .onion name they are communicating with is the intended one, as attackers may be able to find keys which produce service names that are visually or semantically similar to the desired service. This risk is magnified because .onion names are typically not human-meaningful. It can be mitigated by generating human meaningful .onion names (at considerable computing expense), or through users using bookmarks and other trusted stores when following links. * tld proxy-phishing facebookXXX.onion (real) versus = facebookXXX.onion.tld (proxy) ** best mitigation: again, SSL, hence this draft ** documented Also, users need to understand the difference between a .onion name used and accessed directly via Tor-capable software, versus .onion subdomains of other top-level domain names and providers (e.g., the difference between example.onion and example.onion.tld). * leakage (risk to user) ** best mitigation: use current software. DNS NXDOMAIN will help reduce = risk. ** documented A legacy client may inadvertently attempt to resolve a ".onion" name through the DNS. This causes a disclosure that the client is using TOR to reach a specific service. Malicious resolvers could be engineered to capture and record such leaks, which might have very adverse consequences for the well-being of the TOR user. This issue is mitigated if the client's TOR software is updated to not leak such queries, or if the client's DNS software is updated to drop any request to the ".onion" TLD. =E2=80=94 Alec Muffett Security Infrastructure Facebook Engineering London --Apple-Mail=_DDDA63C8-E1AE-4E73-8D73-1086E2E96429 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Ah, = apologies, I see that I have just been unclear:


On Sep 2, 2015, at 12:36 PM, = Alec Muffett <alecm@fb.com> wrote:

I think Mark=E2=80=99s revisions nail this with the =E2=80=9Cle= gacy client=E2=80=9D paragraph.  :-)

=E2=80=A6nails the =E2=80=9Cblackholing DNS=E2=80=9D= matter with the =E2=80=9Clegacy client=E2=80=9D paragraph. =  :-)


I = am quite confident that Mark=E2=80=99s latest diff:


=E2=80=A6covers the = =E2=80=9Chuman factors=E2=80=9D element quite well.  



The primary risks to = users of Onion names are:

* prefix collision phishing such as facebookXXX.onion versus = facebookYYY.onion
** best = mitigation: SSL, hence this draft
** = documented

   Users must take special precautions to ensure that the =
.onion name
   they are communicating with is the intended one, as attackers may be
   able to find keys which produce service names that are visually or
   semantically similar to the desired service.  This risk is magnified
   because .onion names are typically not human-meaningful.  It can be
   mitigated by generating human meaningful .onion names (at
   considerable computing expense), or through users using bookmarks and
   other trusted stores when following links.


* tld proxy-phishing facebookXXX.onion = (real) versus facebookXXX.onion.tld (proxy)
** best mitigation: again, SSL, hence this = draft
** documented

   Also, users need to =
understand the difference between a .onion name
   used and accessed directly via Tor-capable software, versus .onion
   subdomains of other top-level domain names and providers (e.g., the
   difference between example.onion and example.onion.tld).


* leakage (risk to user)
** best mitigation: use current software. DNS NXDOMAIN will = help reduce risk.
** documented

   A legacy =
client may inadvertently attempt to resolve a ".onion" name
   through the DNS.  This causes a disclosure that the client is using
   TOR to reach a specific service.  Malicious resolvers could be
   engineered to capture and record such leaks, which might have very
   adverse consequences for the well-being of the TOR user.  This issue
   is mitigated if the client's TOR software is updated to not leak such
   queries, or if the client's DNS software is updated to drop any
   request to the ".onion" TLD.


=E2=80=94
Alec = Muffett
Security Infrastructure
Facebook Engineering
London

= --Apple-Mail=_DDDA63C8-E1AE-4E73-8D73-1086E2E96429-- --Apple-Mail=_790B9BCC-A56D-4EB1-8BA5-69E7342AF6E9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJV5uLSAAoJECldTB9TIAHGXY4QAIDBll/Y7hZvUu6o4cViZVNX SV+iU2UPEah0Co0Jai6GAJVjXrgQMqIkoQHa6FZISRqLeUrLICz6EagPTqwkgVgj 6dYkfl11TIFezpPsttvo1ac7AtAzhjM4wP4kqI/Dm18UjXAQP69no33m8ZG4eYls b56bfLEyVWwxNqXzG2HhjZG4VAzALs7jdlVW7BN4Twbuy/k9GFuwzeSPGv522rr5 gQzhX7yUfPee+lkcF2A8qhtnCAI2TdBZmdiLUz5h2s3jlwlpOTpeIjCMi1GO/7nA 7UmH6NB9KNx07OSJNUdofyjTSWWXuTx9Q2TsaJj87nQlznhJMG0AEky0rxETw4A+ WFjFoOrNQPOw4wgAJOBdq+MnwOKM5ls+pc/XnWdIACSpqYz8PQzFQNEpefKrD4fT 3FkVxbpp99h13LCt7vrxykKwdSmf1IBg0Gb9GrbfCgAsYgY7BolpJIzxFvRp3NwS YS0lci+9onTpKfWT4i3ZmP0LOD8JGwDygSnB9JqTHCJ3F+hFcj3kkuHZhnffK7Ra F9SI22ZT0aCFc05Ik0ZWMVuBucJcBi6lMctMIXmAO/Iiv08+Y6ZgGG/c8N+S3qVk p9z1X7aLqN1ZiZ9+EASCYhlZzp4T33cUKbjjAtW5tLA+hY1MMAIV/51tAdKGRC13 7MVm5z+OZXZXpZl5f7vd =YbBc -----END PGP SIGNATURE----- --Apple-Mail=_790B9BCC-A56D-4EB1-8BA5-69E7342AF6E9-- From nobody Wed Sep 2 06:07:05 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9723F1ACD09; Wed, 2 Sep 2015 06:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 xOD5U6OLuAxO; Wed, 2 Sep 2015 06:07:02 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8851B2E9D; Wed, 2 Sep 2015 06:07:02 -0700 (PDT) Received: from pps.filterd (m0044012 [127.0.0.1]) by mx0a-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id t82D6jqc027325; Wed, 2 Sep 2015 06:06:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=li+3qyj5bga6x+H5rrGgICSphs7EkejUD9sOrMwXh60=; b=nhd23IKL8ipOh9XSyMzaOaDpgPGLA/zMFwtJezM3xIkIyeOVbMOCh//VateJd9ibaKja YEtryYJFuML/h66EGmivmv0Pb4V1mBtAW3UWyxQp1U1ThEzl7o1ASztDe7U807zCnXDF rriy+xnvTLnANVMj3h7XoYKvO0i7I3DUF4c= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 1wnv05rmgm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 02 Sep 2015 06:06:49 -0700 Received: from PRN-MBX02-4.TheFacebook.com ([169.254.2.38]) by PRN-CHUB16.TheFacebook.com ([fe80::7948:a494:45d7:3dd9%12]) with mapi id 14.03.0248.002; Wed, 2 Sep 2015 06:06:47 -0700 From: Alec Muffett To: Mark Nottingham Thread-Topic: Security review of draft-ietf-dnsop-onion-tld-00.txt Thread-Index: AdDCwrgI+PKUtFTlQwu24Fnrr5jdagegWveAACR0AIAAAL0/gAAA1DGAAChahwAAFz1KgABItVeAAAHCUIAAMdskgAACAj4AAARQn4AABPMMAAAAUFGAABSHWIAAG6SPgA== Date: Wed, 2 Sep 2015 13:06:45 +0000 Message-ID: <0B6C8B4B-F11D-43E7-B6F9-EBC53FC97F39@fb.com> References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> <55E22119.9080106@bogus.com> <55E414D7.3070600@cs.tcd.ie> <371BFDC3-19C6-4B5F-AA49-525DBA26EA67@mnot.net> <55E570E6.4090603@cs.tcd.ie> <05AC4751-6317-4EB6-BFF7-1C822B8D44BB@gmail.com> <00be01d0e4be$50fcac40$f2f604c0$@huitema.net> <65D73339-F470-4D78-89CD-907E76B229B0@mnot.net> In-Reply-To: <65D73339-F470-4D78-89CD-907E76B229B0@mnot.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/signed; boundary="Apple-Mail=_76BCBA9F-14D5-48AB-9594-77C1AA5E4E18"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-02_06:2015-09-02,2015-09-02,1970-01-01 signatures=0 Archived-At: Cc: secdir , joel jaeggli , Kathleen Moriarty , "draft-ietf-dnsop-onion-tld.all@tools.ietf.org" , The IESG , Brad Hill , Barry Leiba Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 13:07:03 -0000 --Apple-Mail=_76BCBA9F-14D5-48AB-9594-77C1AA5E4E18 Content-Type: multipart/alternative; boundary="Apple-Mail=_6B804046-3F77-4E97-B7E8-5DA4F2326382" --Apple-Mail=_6B804046-3F77-4E97-B7E8-5DA4F2326382 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 nit: =E2=80=9C well-being of the TOR user=E2=80=9D Tor is no longer an acrorym / not capitalised throughout. =E2=80=94 Alec Muffett Security Infrastructure Facebook Engineering London --Apple-Mail=_6B804046-3F77-4E97-B7E8-5DA4F2326382 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 nit: =E2=80=9C well-being of the TOR user=E2=80=9D

Tor is no longer an acrorym / not = capitalised throughout.

=E2=80=94
Alec = Muffett
Security Infrastructure
Facebook Engineering
London

= --Apple-Mail=_6B804046-3F77-4E97-B7E8-5DA4F2326382-- --Apple-Mail=_76BCBA9F-14D5-48AB-9594-77C1AA5E4E18 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJV5vR0AAoJECldTB9TIAHGfuUP/3JLVhBtv63opq8UGGOlv+zV Kg5Z1NhZmmPi7Us+Lo5Ha6NwDzWTFl48khlcWMX6h2RCQUz9dSHqaaRNaa4dGX5/ 68oaLCac+nxt8FUt4BADq9aUz/xP01773TkpR1nA+hk4nMctv3uXzDnMoaAwROWs V2Z6ClSfqe560BOW6fxp0YrQ9+YT6bt5TX+TA4hCeC2qOQX7Xrdls2RbRpZEBKM/ Lnk1n2PJkUnfcPJL3k7ByQ9hxk46nk7RLu0kjAqrtiLErWcFn2KBxM5cdRu8qzvv HbhHj3ETD9GWdYAatHPyr7faaiCpiC7i+vokZ4E5p8mCnaCgRaPa5ZFImFTIddKO aYINv2aZBfXGeKv4rLPqMwHIWKyFskXAxooDsb2n0Kdm5D/OnyRd4o16KeNBjev+ vHy4N37XpirbGvYOx6yDeBWMHzrKDlmq1CkHPzj6D102K1RVXF2dGi8pkzLQDbuJ 0UuSuG5gn7JZpvgN0nmAXVvrf6tjuBgO/ejjR6/jmBmHguURfLXs3yFfEmmBd4sQ aiHIgk/zmZKstSqHmTvURraMqgjeL6pVpBaqBA0j5PNGsYoad0TX5GoXnaMTmUl0 q1TD/85sH6S1QuUaNHf1gSXv89IMLJwWjPsj9vgggclIPvLSIOFNCOHlri9eWt5c o0stFDJZ15ZAibqo2+34 =LppF -----END PGP SIGNATURE----- --Apple-Mail=_76BCBA9F-14D5-48AB-9594-77C1AA5E4E18-- From nobody Wed Sep 2 07:10:53 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993461B4CFD for ; Tue, 1 Sep 2015 10:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 CoYC-kN1akaw for ; Tue, 1 Sep 2015 10:11:34 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 3BF3C1B55A9 for ; Tue, 1 Sep 2015 10:11:32 -0700 (PDT) Received: by vkhf67 with SMTP id f67so60986504vkh.1 for ; Tue, 01 Sep 2015 10:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=f+Wp3yWwPvAGpaLsUJHbuyVPXQe+tv4jG/MQTyBFZ2s=; b=h1ikSj12yRwI6l3l6TqvHPRq/INxljgAJPRGGUlykUtFVV2/Z5Xj1RaSJX2EILIhPP XX5NyX6ND1HZtJ05fvjjN9rGzE2EKPfVCtKXmryj97NgRPfukvstbaijx9wDOXGCPNUG R3+Z5hnWz83kb8DyyoUgf+QWxupCLNDe4YF7hYlvkdLcV1PJcRMSmRCwujDTp3KzFXHH biOTdlsWhHuwj2zsubiX1u3S+Hz7kCqv8JOIxJmQodHkvWgwb95ki8AYbURaoYffxBiS DXFR4OY+dW7NFHyfLzmlxSgGaTiacktWqrxg8UMCKaOSUCRHjaVi+UGqCxgL8urrXcLJ cMDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=f+Wp3yWwPvAGpaLsUJHbuyVPXQe+tv4jG/MQTyBFZ2s=; b=gxapSs44oF0kkQRfLlcLtbJmdv4+R5zv7gaf3QCbJCi+h6/2QSABBy4O4YF9iyOPbp LdCpT8e0dDLkQrKKCr7qySt9S31xENoT7CaOdhfXdOIBXvOFapuTnq7fxXjR9W93lbGz ibpEJxQ39KY4WmkDa0VaS4GnWPblJ+EsXJK+dAPD4ysGAlam1AhcEHvGD2eGF8oSovbq /ytUMvWsqazymDCwDWhMCdBiY5K98aA6epZsNgFDB+AUQ6Q4hCzu4WHOC0J5frtB4YIv fKXz7zopXw+9H0ralX86hqFEbm23CJXZ3f5lp4moNXcYenDEJmZrHubG6cO3Q5FkdZm1 JcBQ== X-Gm-Message-State: ALoCoQkYj9inOTBO++VIvw7JIuD0BnYuT2QS6+71UcxGd3p6bel5RRI5yG9+3DB43CAq2BhHRTtU X-Received: by 10.52.232.225 with SMTP id tr1mr32729815vdc.0.1441127491172; Tue, 01 Sep 2015 10:11:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.193.8 with HTTP; Tue, 1 Sep 2015 10:11:11 -0700 (PDT) In-Reply-To: <7DBFEE57-B11D-4A09-94A5-86C386E77FC2@inria.fr> References: <7DBFEE57-B11D-4A09-94A5-86C386E77FC2@inria.fr> From: Adam Langley Date: Tue, 1 Sep 2015 10:11:11 -0700 Message-ID: To: Vincent Roca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 02 Sep 2015 07:10:52 -0700 Cc: draft-ietf-tls-padding@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-tls-padding-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 17:11:35 -0000 On Mon, Aug 31, 2015 at 9:16 AM, Vincent Roca wrote= : > That=E2=80=99s perhaps a naive question, but let me ask it. Shouldn=E2=80= =99t a receiver > check > that the actual length of the extension_data field is in line with the va= lue > of the > extension_data length field. Since those zero bytes are actually carried > over > the net and present in the reception buffer, there could be several ways = to > calculate this length=E2=80=A6 (I really don=E2=80=99t know if it=E2=80= =99s the case or not) I don't think that we want to pin down the exact length of the padding and would rather leave it up to the sender. Although, for now, we have only a single use case for this, some other uses have been suggested(*) and it would be nice just to have a single padding extension if we decide that we need them in the future. (*) for example, padding a DTLS ClientHello to reduce the amplification factor of DTLS. > Additionally, section 3 says: > > The client MUST fill the padding extension completely with zero > bytes, although the padding extension may be empty. > > I think that you mean =C2=AB padding extension_data field =C2=BB and not = =C2=AB padding > extension =C2=BB: Done, thanks. > And finally, in the example (figure), instead of: > > 16-bit, extension_data length > > I=E2=80=99d rather add a =C2=AB _ =C2=BB as in: > > 16-bit, extension_data_length Although I don't have strong feelings either way, I didn't make this change. In the TLS 1.2 RFC (https://tools.ietf.org/html/rfc5246#section-7.4.1.4), extension_data is a named field, but extension_data_length is not. Rather it's an implicit part of extension_data. Since this draft isn't defining anything new about extensions in general, I feel that it shouldn't name new things here. Cheers AGL From nobody Wed Sep 2 07:10:54 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EAC1B3BFB; Tue, 1 Sep 2015 20:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 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, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=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 y5P56vvn2Lty; Tue, 1 Sep 2015 20:58:41 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (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 951901B3597; Tue, 1 Sep 2015 20:58:40 -0700 (PDT) Received: by laeb10 with SMTP id b10so13085721lae.1; Tue, 01 Sep 2015 20:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZEdfGoYhUX0b9VBZC/9GfwMnRMzBR692YiM9BwM3li8=; b=Zn4igDWjUagms5oZc5d5xnBIGo1DlUp+gV6lJqiyhUk/1z7w2jsG7STZU6+5yBjHAA Ad6RrxmbIWw+wWq4WB6SUqR0LkFK/dy6Br3ypnqJYEoH1GmiD2yfZjRjx41xeqMu8M0d 1wT3yANcd1guYpgD3W2c1dwNL1Mw631P1XSdSL5OOxSqyVOHWQgphSQHEpvZuP1pEZxy HBhkUaaQlNu2ku0BUgXJ9pB/JcboWGyB9stYXGowUh5r+iiK2JYwnG07jvWmMIb//hZJ sY749IDr/Gapjxz2Pltu95qFupucjmypRWkJlfMlCxKaFEaXL0yXYMdFWQFjqMWEGdPG UCsw== MIME-Version: 1.0 X-Received: by 10.152.219.172 with SMTP id pp12mr14700452lac.17.1441166318889; Tue, 01 Sep 2015 20:58:38 -0700 (PDT) Received: by 10.25.84.147 with HTTP; Tue, 1 Sep 2015 20:58:38 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Sep 2015 20:58:38 -0700 Message-ID: From: Venkatesan Mahalingam To: Tina TSOU Content-Type: multipart/alternative; boundary=001a1134328a7ff4b7051ebbae1d Archived-At: X-Mailman-Approved-At: Wed, 02 Sep 2015 07:10:52 -0700 Cc: "draft-ietf-mpls-tp-oam-id-mib.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-tp-oam-id-mib-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 03:58:42 -0000 --001a1134328a7ff4b7051ebbae1d Content-Type: text/plain; charset=UTF-8 Thanks for your comments Tina, will address and publish the new version 09 soon. -Venkat, On Tue, Sep 1, 2015 at 7:09 AM, Tina TSOU wrote: > 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 document seems ready to go. I only found these minor nits: > > > > The title of this draft indicates mib for MPLS-TP OAM ID but in the body > MPLS is used mostly and sometimes MPLS-TP appears, for example, both MPLS > tunnels and MPLS-TP tunnels are mentioned. I'm not sure if they can be used > interchangeable. Besides, I notice that the names for the objects all start > with "mplsoamidxxx", which seems to address mib for MPLS OAM ID. Then it is > not aligned with the title of this draft. A bit confused. Could the authors > provide any clarification on this? A general suggestion is to make > alignment throughout the document, including the title of the draft. > > > > * Abstract: > > > > > it describes Operations, Administration, and Management (OAM) > > > identifiers related managed objects for Multiprotocol Label Switching > > > (MPLS) and MPLS based Transport Profile (TP). > > > > I find this sentence hard to parse. Maybe s/related managed > objects/related to managed objects/ ? > > > > > > * Section 1, page 3: > > > MPLS LSP(Label > > > > There's a missing space. > > > > > > * Section 5.1, page 4: > > > > > The mplsOamIdMegTable is used to manage one or more Maintenance > > > Entities (MEs) that belongs > > > > s/belongs/belong/ > > > > > > * Section 6, copy&paste mistake > > > > -- Source MEP id is derived from the IP compatible MPLS LSP > > mplsOamIdMeSinkMepIndex = 0, > > > > The description in the note should be sink MEP. There is already another > line to describe source MEP. > > > > > > * Page 15: > > > > > BFD > > > > This is the first and only instance of BFD. Please expand. (and maybe > reference RFC5880)? > > > > > > * Page 17: > > > > "p2p" and "P2P" first used here. should probably be expanded. > > > > > > Thank you, > > Tina > > > --001a1134328a7ff4b7051ebbae1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your comments Tina, will address and publish th= e new version 09 soon.

-Venkat,

On Tue, Sep 1, 2015 at 7:09 AM= , Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:=

Dear all,

=C2=A0

I have reviewed this docu= ment 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. Doc= ument editors and WG chairs should treat these comments just like any other= last call comments.

The document seems ready = to go. I only found these minor nits:

=C2=A0

The title of this draft i= ndicates mib for MPLS-TP OAM ID but in the body MPLS is used mostly and som= etimes MPLS-TP appears, for example, both MPLS tunnels and MPLS-TP tunnels are mentioned. I'm not sure if they can be used interc= hangeable. Besides, I notice that the names for the objects all start with = "mplsoamidxxx", which seems to address mib for MPLS OAM ID. Then = it is not aligned with the title of this draft. A bit confused. Could the authors provide any clarification on this? A gen= eral suggestion is to make alignment throughout the document, including the= title of the draft.=

=C2=A0

* Abstract:=

=C2=A0

> it describes Operati= ons, Administration, and Management (OAM)

> identifiers related = managed objects for Multiprotocol Label Switching

> (MPLS) and MPLS base= d Transport Profile (TP).

=C2=A0

I find this sentence hard= to parse. Maybe s/related managed objects/related to managed objects/ ?=

=C2=A0

=C2=A0

* Section 1, page 3:

> MPLS LSP(Label

=C2=A0

There's a missing spa= ce.

=C2=A0

=C2=A0

* Section 5.1, page 4:=

=C2=A0

> The mplsOamIdMegTabl= e is used to manage one or more Maintenance

> Entities (MEs) that = belongs

=C2=A0

s/belongs/belong/<= u>

=C2=A0

=C2=A0

* Section 6, copy&pas= te mistake

=C2=A0

-- Source MEP id is deriv= ed from the IP compatible MPLS LSP

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 mplsOamIdMeSinkMepIndex=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =3D 0,

=C2=A0

The description in the no= te should be sink MEP. There is already another line to describe source MEP= .

=C2=A0

=C2=A0

* Page 15:<= /span>

=C2=A0

> BFD

=C2=A0

This is the first and onl= y instance of BFD. Please expand. (and maybe reference RFC5880)?<= /u>

=C2=A0

=C2=A0

* Page 17:<= /span>

=C2=A0

"p2p" and "= ;P2P" first used here. should probably be expanded.

=C2=A0

=C2=A0

Thank you,<= /span>

Tina=

=C2=A0


--001a1134328a7ff4b7051ebbae1d-- From nobody Wed Sep 2 07:10:56 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513DF1B4AD1; Tue, 1 Sep 2015 23:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 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, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=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 Vu_8WvPmyCF0; Tue, 1 Sep 2015 23:47:08 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 3F0351B4AD5; Tue, 1 Sep 2015 23:47:08 -0700 (PDT) Received: by lbbmp1 with SMTP id mp1so422200lbb.1; Tue, 01 Sep 2015 23:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TU8c9mGLQ0pITCRG52VCTBPBaQzxe4SRLzQZyxpDHXM=; b=cNQUypfKCgAcqNpA32axFXLGKXEVt/RmB0GT4JLCwzaeKzMXOaXNNDH5btmqQHRXkh pBS1F34cbK2ZciIcRC2luXfxvbPJOQ8F6ID0CGV188QjOJoMz9baqXFyIt5Po1HFQNgq tjVSibZuApwUjZeH/TDfpD6Cyb+GXT0NGvctzR5WYFbSqexna5EwAjtij+INoEywN0G3 yoMiQsD1ZSMxPuYyNl3eoCsc6zRqRJpol8uV5n+gqdDhpVHVCy6A2hTljbT197tVIdTP oKnf2V0BBFwWdZKfepWiqOOpjbOf11Ljk/AaXkYxt+Yye6n1IK/LmtsZmxVU7ne7M+3E bUYg== MIME-Version: 1.0 X-Received: by 10.152.8.233 with SMTP id u9mr15307334laa.8.1441176426558; Tue, 01 Sep 2015 23:47:06 -0700 (PDT) Received: by 10.25.84.147 with HTTP; Tue, 1 Sep 2015 23:47:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Sep 2015 23:47:06 -0700 Message-ID: From: Venkatesan Mahalingam To: Tina TSOU Content-Type: multipart/alternative; boundary=089e0158b77cf6c109051ebe081a Archived-At: X-Mailman-Approved-At: Wed, 02 Sep 2015 07:10:52 -0700 Cc: "draft-ietf-mpls-tp-oam-id-mib.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-tp-oam-id-mib-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 06:47:11 -0000 --089e0158b77cf6c109051ebe081a Content-Type: text/plain; charset=UTF-8 Tina, We have published the new version 09, please go through the diff, if you have any further comments, please let us know. URL: https://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-id-mib-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib/ Htmlized: https://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-09 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-oam-id-mib-09 >>The title of this draft indicates mib for MPLS-TP OAM ID but in the body MPLS is used mostly and sometimes MPLS-TP appears, for example, both MPLS tunnels and MPLS-TP tunnels are mentioned. I'm not sure if they can be used >>interchangeable. Besides, I notice that the names for the objects all start with "mplsoamidxxx", which seems to address mib for MPLS OAM ID. Then it is not aligned with the title of this draft. A bit confused. Could the authors provide >>any clarification on this? A general suggestion is to make alignment throughout the document, including the title of the draft. As Loa suggested, we have included MPLS-TP (as we do this work as part of MPLS-TP) in the title but this draft actually describes the managed object for both MPLS and MPLS-TP tunnel identifiers. -Venkat. On Tue, Sep 1, 2015 at 8:58 PM, Venkatesan Mahalingam < venkat.mahalingams@gmail.com> wrote: > Thanks for your comments Tina, will address and publish the new version 09 > soon. > > -Venkat, > > On Tue, Sep 1, 2015 at 7:09 AM, Tina TSOU > wrote: > >> 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 document seems ready to go. I only found these minor nits: >> >> >> >> The title of this draft indicates mib for MPLS-TP OAM ID but in the body >> MPLS is used mostly and sometimes MPLS-TP appears, for example, both MPLS >> tunnels and MPLS-TP tunnels are mentioned. I'm not sure if they can be used >> interchangeable. Besides, I notice that the names for the objects all start >> with "mplsoamidxxx", which seems to address mib for MPLS OAM ID. Then it is >> not aligned with the title of this draft. A bit confused. Could the authors >> provide any clarification on this? A general suggestion is to make >> alignment throughout the document, including the title of the draft. >> >> >> >> * Abstract: >> >> >> >> > it describes Operations, Administration, and Management (OAM) >> >> > identifiers related managed objects for Multiprotocol Label Switching >> >> > (MPLS) and MPLS based Transport Profile (TP). >> >> >> >> I find this sentence hard to parse. Maybe s/related managed >> objects/related to managed objects/ ? >> >> >> >> >> >> * Section 1, page 3: >> >> > MPLS LSP(Label >> >> >> >> There's a missing space. >> >> >> >> >> >> * Section 5.1, page 4: >> >> >> >> > The mplsOamIdMegTable is used to manage one or more Maintenance >> >> > Entities (MEs) that belongs >> >> >> >> s/belongs/belong/ >> >> >> >> >> >> * Section 6, copy&paste mistake >> >> >> >> -- Source MEP id is derived from the IP compatible MPLS LSP >> >> mplsOamIdMeSinkMepIndex = 0, >> >> >> >> The description in the note should be sink MEP. There is already another >> line to describe source MEP. >> >> >> >> >> >> * Page 15: >> >> >> >> > BFD >> >> >> >> This is the first and only instance of BFD. Please expand. (and maybe >> reference RFC5880)? >> >> >> >> >> >> * Page 17: >> >> >> >> "p2p" and "P2P" first used here. should probably be expanded. >> >> >> >> >> >> Thank you, >> >> Tina >> >> >> > > --089e0158b77cf6c109051ebe081a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tina,

We have published the new version= 09, please go through the diff, if you have any further comments, please l= et us know.


>>The t= itle of this draft indicates mib for MPLS-TP OAM ID but in the body MPLS is= used mostly and sometimes MPLS-TP appears, for example, both MPLS tunnels = and MPLS-TP tunnels are mentioned. I'm not sure if they can be used >= ;>interchangeable. Besides, I notice that the names for the objects all = start with "mplsoamidxxx", which seems to address mib for MPLS OA= M ID. Then it is not aligned with the title of this draft. A bit confused. = Could the authors provide >>any clarification on this? A general sugg= estion is to make alignment throughout the document, including the title of= the draft.

As= Loa suggested, we have included MPLS-TP (as we do this work as part of MPL= S-TP) in the title but this draft actually describes the managed object for= both MPLS and MPLS-TP tunnel identifiers.


-Venkat.

On Tue, Sep 1, 2015 at 8:58 PM, Venkatesan Mahalin= gam <venkat.mahalingams@gmail.com> wrote:
Thanks for your comments Tina, = will address and publish the new version 09 soon.

-Venka= t,

On Tue, Sep 1, 2015 at 7:09 AM, Tina T= SOU <Tina.Tsou.Zouting@huawei.com> wrote:

Dear all,

=C2=A0

I have reviewed this docu= ment 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. Doc= ument editors and WG chairs should treat these comments just like any other= last call comments.

The document seems ready = to go. I only found these minor nits:

=C2=A0

The title of this draft i= ndicates mib for MPLS-TP OAM ID but in the body MPLS is used mostly and som= etimes MPLS-TP appears, for example, both MPLS tunnels and MPLS-TP tunnels are mentioned. I'm not sure if they can be used interc= hangeable. Besides, I notice that the names for the objects all start with = "mplsoamidxxx", which seems to address mib for MPLS OAM ID. Then = it is not aligned with the title of this draft. A bit confused. Could the authors provide any clarification on this? A gen= eral suggestion is to make alignment throughout the document, including the= title of the draft.=

=C2=A0

* Abstract:=

=C2=A0

> it describes Operati= ons, Administration, and Management (OAM)

> identifiers related = managed objects for Multiprotocol Label Switching

> (MPLS) and MPLS base= d Transport Profile (TP).

=C2=A0

I find this sentence hard= to parse. Maybe s/related managed objects/related to managed objects/ ?=

=C2=A0

=C2=A0

* Section 1, page 3:

> MPLS LSP(Label

=C2=A0

There's a missing spa= ce.

=C2=A0

=C2=A0

* Section 5.1, page 4:=

=C2=A0

> The mplsOamIdMegTabl= e is used to manage one or more Maintenance

> Entities (MEs) that = belongs

=C2=A0

s/belongs/belong/<= u>

=C2=A0

=C2=A0

* Section 6, copy&pas= te mistake

=C2=A0

-- Source MEP id is deriv= ed from the IP compatible MPLS LSP

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 mplsOamIdMeSinkMepIndex=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =3D 0,

=C2=A0

The description in the no= te should be sink MEP. There is already another line to describe source MEP= .

=C2=A0

=C2=A0

* Page 15:<= /span>

=C2=A0

> BFD

=C2=A0

This is the first and onl= y instance of BFD. Please expand. (and maybe reference RFC5880)?<= /u>

=C2=A0

=C2=A0

* Page 17:<= /span>

=C2=A0

"p2p" and "= ;P2P" first used here. should probably be expanded.

=C2=A0

=C2=A0

Thank you,<= /span>

Tina=

=C2=A0



--089e0158b77cf6c109051ebe081a-- From nobody Wed Sep 2 07:10:57 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647561B3FCF; Wed, 2 Sep 2015 06:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 RqkcYGjjqHeK; Wed, 2 Sep 2015 06:47:54 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14681B4000; Wed, 2 Sep 2015 06:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4583; q=dns/txt; s=iport; t=1441201670; x=1442411270; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NRLSQXgSWZJ19xbSSb6Qytq5MFQqTbc6iejwaAkZimg=; b=VMn6+EeqMW2lmEiSzmHLAy6gyO1q/fYwCvh4ToOwHoEbUd1OdHDEyPnj FRxJJWZSUTtHXXclXxeZDvtqbIFy1n+qOW2oh7jigQSGSlyJhbm7HziSG AhmGl4gLZ3INEqjUDHlSLnPMsOEMVkgL9boRTimNkzUd+6amF+anL8PHW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CuAgB2/eZV/40NJK1dgk5NVGkGvUIBCYFyhgACgTQ4FAEBAQEBAQGBCoQkAQEEeRACAQgEOwcyFBECBAENBQmIJQ3LJgEBAQEBAQEBAQEBAQEBAQEBAQEBAReGcwGEeoULBwmEIwWFNz+GfYU5gx0BhCFlhT6CMYFKRocLkVQmgg8cgVRxAQEBAYFEgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,453,1437436800"; d="scan'208,217";a="184505038" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Sep 2015 13:47:49 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t82DlnbN026277 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Sep 2015 13:47:49 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Sep 2015 08:47:48 -0500 Received: from xhc-rcd-x01.cisco.com (173.37.183.75) by xch-rcd-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 2 Sep 2015 08:47:48 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.140]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0248.002; Wed, 2 Sep 2015 08:47:48 -0500 From: "Alvaro Retana (aretana)" To: Alec Muffett , Kathleen Moriarty Thread-Topic: Security review of draft-ietf-dnsop-onion-tld-00.txt Thread-Index: AdDCwrgI60FbfiD1VUm8SJFVl8ANngegWveAACR0AIAAAL0/gAABmQkAAHdoZIAAfFgpgP//4p8A///daQA= Date: Wed, 2 Sep 2015 13:47:48 +0000 Message-ID: References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.23] Content-Type: multipart/alternative; boundary="_000_D20C73C3CD207aretanaciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 02 Sep 2015 07:10:52 -0700 Cc: secdir , joel jaeggli , Mark Nottingham , "draft-ietf-dnsop-onion-tld.all@tools.ietf.org" , The IESG , Brad Hill Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 13:47:57 -0000 --_000_D20C73C3CD207aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 9/2/15, 7:51 AM, "iesg on behalf of Alec Muffett" on behalf of alecm@fb.com> wrote: Alec: Hi! I am quite confident that Mark=92s latest diff: http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=3Dhttps://www.ietf.org/id/dra= ft-ietf-dnsop-onion-tld-00.txt&url2=3Dhttp://mnot.github.io/I-D/dnsop-onion= -tld/draft-ietf-dnsop-onion-tld-01.txt =85covers the =93human factors=94 element quite well. There is more there, but as an average Internet user (not a Tor user) I sti= ll don=92t know what to look out for if presented with a .onion name (or so= mething that looks like it). I suspect that most average users will just c= lick on something w/out realizing (ever!) it is a .onion name, and not a = =93plain old link=94 to some other page. However, the more I read this thread the more I am convinced not much can b= e said/done. Just like the facebookXXX.onion versus facebookYYY.onion case= , average users don=92t pay enough attention to distinguish between faceboo= k.com and faceboook.com, much less would they know that .onion (or any othe= r name for that matter) is special. As you already wrote in the latest ver= sion, we can just hope that the appropriate sw is updated to prevent the av= erage user from doing something they don=92t even understand that may resul= t in some leakage of information. Thanks for addressing this point. Alvaro. --_000_D20C73C3CD207aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 9/2/15, 7:51 AM, "iesg on behalf of Alec Muffett" <iesg-bounces@ietf.org on behalf o= f alecm@fb.com> wrote:

Alec:

Hi!


There is more there, but as an average Internet user (not a Tor user) = I still don=92t know what to look out for if presented with a .onion name (= or something that looks like it).  I suspect that most average users w= ill just click on something w/out realizing (ever!) it is a .onion name, and not a =93plain old link=94 to some other = page.

However, the more I read this thread the more I am convinced not much = can be said/done.  Just like the facebookXXX.onion versus facebookYYY.= onion case, average users don=92t pay enough attention to distinguish betwe= en facebook.com and faceboook.com, much less would they know that .onion (or any other name for that matter) is sp= ecial.  As you already wrote in the latest version, we can just hope t= hat the appropriate sw is updated to prevent the average user from doing so= mething they don=92t even understand that may result in some leakage of information.

Thanks for addressing this point.

Alvaro.
--_000_D20C73C3CD207aretanaciscocom_-- From nobody Wed Sep 2 08:09:51 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA49E1B49AA; Wed, 2 Sep 2015 08:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 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, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 LrubrfpIHR4E; Wed, 2 Sep 2015 08:09:31 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B021B498C; Wed, 2 Sep 2015 08:09:25 -0700 (PDT) Received: from pps.filterd (m0004347 [127.0.0.1]) by m0004347.ppops.net (8.14.5/8.14.5) with SMTP id t82F6QlW005337; Wed, 2 Sep 2015 08:09:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=4numPYA7LG4AUgteS4vaImcPmeBPI2btpvbXXFU197k=; b=Nj4TgmwTFdF+90q41kjcBhZRYKYq/euF7k9xLrVHlpZirNziNdO9c9HCfx2hcMZ8g2xk d2JT4jkNou5nFkrvoCILbWDN2Wh8T9yy3qyJU7AAcIjgeJ0nMtcmFNvBlquRlNHzySYn xK+3Bzr6krcb4x1raDvbZ6zzD9u+EJtqjS4= Received: from mail.thefacebook.com ([199.201.64.23]) by m0004347.ppops.net with ESMTP id 1wp1f1g8d1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 02 Sep 2015 08:09:14 -0700 Received: from PRN-MBX02-4.TheFacebook.com ([169.254.2.38]) by PRN-CHUB05.TheFacebook.com ([fe80::9886:b2c2:db18:5ba7%12]) with mapi id 14.03.0248.002; Wed, 2 Sep 2015 08:09:13 -0700 From: Alec Muffett To: "Alvaro Retana (aretana)" Thread-Topic: Security review of draft-ietf-dnsop-onion-tld-00.txt Thread-Index: AdDCwrgI+PKUtFTlQwu24Fnrr5jdagegWveAACR0AIAAAL0/gAABmQkAAHdoZIAAfFgpgAAAhtsAAAQNawAAAtmQAA== Date: Wed, 2 Sep 2015 15:09:11 +0000 Message-ID: <88A83735-7C8C-49C6-BDE9-CB0CC6059AB6@fb.com> References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/signed; boundary="Apple-Mail=_9FEAFDDD-3C98-41F8-9527-C8A32F229211"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-02_06:2015-09-02,2015-09-02,1970-01-01 signatures=0 Archived-At: Cc: secdir , Mark Nottingham , joel jaeggli , Kathleen Moriarty , "draft-ietf-dnsop-onion-tld.all@tools.ietf.org" , The IESG , Brad Hill Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:09:34 -0000 --Apple-Mail=_9FEAFDDD-3C98-41F8-9527-C8A32F229211 Content-Type: multipart/alternative; boundary="Apple-Mail=_2CCCE9C8-4129-46A9-A38F-1CD74B811BA1" --Apple-Mail=_2CCCE9C8-4129-46A9-A38F-1CD74B811BA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Alvaro! > On Sep 2, 2015, at 2:47 PM, Alvaro Retana (aretana) = wrote: > There is more there, but as an average Internet user (not a Tor user) = I still don=92t know what to look out for if presented with a .onion = name (or something that looks like it). That=92s a really good point - is this document fit for the purposes of = people who click on a link, expect it to work, and are surprised when it = does not? An example of this - where I was the author, and so I took steps to = explain what would not happen - is on this page: = https://www.facebook.com/notes/protect-the-graph/making-connections-to-fac= ebook-more-secure/1526085754298237 = For people who don=92t want to load that page, the relevant part is: >> =85To make their experience more consistent with our goals of = accessibility and security, we have begun an experiment which makes = Facebook available directly over Tor network at the following URL: >> https://facebookcorewwwi.onion/ >> [ NOTE: link will only work in Tor-enabled browsers ] =85and there=92s the thing: someone who is not using Tor will click on a = link and nothing will happen, exactly as (for instance) I visit a coffee = shop or my workplace and click on the bookmarked =93http://router.local/ = =93 link which (when I am at home) would give me = access to my DSL router=92s control panel. > I suspect that most average users will just click on something w/out = realizing (ever!) it is a .onion name, and not a =93plain old link=94 to = some other page. Quite. I believe that that is, in fact, rather the design goal. = Interoperability. The onion network space consists of software, exactly like any other = software (LAMP stacks, Wordpress, Facebook, etc) which is just accessed = via a different address space, the latter being similarly to some VPN = software. Equally, my aforementioned router.local link *will* work when my VPN = into my home network is working properly. Similarly (again) - in my browser bar there are any number of links - = or, for that matter, SSH connections - on the Facebook-internal = corporate network which are not accessible from (say) my local = Starbucks, again unless I have my corporate VPN software enabled - at = which point everything magically suddenly "just works". (aside) This is why I have always felt that using a scheme-change = =93onion://=93 would not have been a good design choice for Tor Onion = Names; my work life would be significantly more complex if I had to swap = schemes when accessing a site over a VPN, a-la = htvpntp://non-dns-name.internal/foo.txt Returning to your point: > However, the more I read this thread the more I am convinced not much = can be said/done. Just like the facebookXXX.onion versus = facebookYYY.onion case, average users don=92t pay enough attention to = distinguish between facebook.com and faceboook.com, much less would they = know that .onion (or any other name for that matter) is special. As you = already wrote in the latest version, we can just hope that the = appropriate sw is updated to prevent the average user from doing = something they don=92t even understand that may result in some leakage = of information. Yes indeed, and I believe that the Ballot-144-enabled adoption of EV = Certificates, with their big friendly green labels, will do a lot to = reduce unwanted intermediary risk in Onion space. Also, in passing, I do wish to point out, those =93fooXXX.onion.tld=94 = proxies which I have elsewhere presented as an unwanted risk, also do = have a wanted and important role to play in making the world more open = and connected; the (independent, non-Tor) Tor2web project was co-founded = by the late Aaron Swartz (of whom some of you may have heard / seen = documentaries?) in order to allow sites to publish via Tor to maintain = anonymity, and Tor2web serves as yet one more bridge for the larger = non-Tor world to access Tor/Onion resources. More details on Tor2web are at https://en.wikipedia.org/wiki/Tor2web = - but to recap: there is a = separate, parallel space of information out there, one that has been = available for about a decade, and in order to bring greater trust to it = and ensure that it is on a sound footing requires it to be slotted into = the bigger picture of the internet and web. Hence this draft. It is what we are trying to do. :-) - alec =97 Alec Muffett Security Infrastructure Facebook Engineering London --Apple-Mail=_2CCCE9C8-4129-46A9-A38F-1CD74B811BA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Hi = Alvaro!

On Sep 2, 2015, at 2:47 PM, Alvaro Retana (aretana) <aretana@cisco.com> = wrote:
There is more there, but as an average Internet user (not a = Tor user) I still don=92t know what to look out for if presented with a = .onion name (or something that looks like it). =

That=92s a = really good point - is this document fit for the purposes of people who = click on a link, expect it to work, and are surprised when it does = not?

An example of this - where I = was the author, and so I took steps to explain what would not happen - = is on this page:


For people who don=92t want to load that page, the = relevant part is:

=85To make their experience more = consistent with our goals of accessibility and security, we have begun = an experiment which makes Facebook available directly over Tor network = at the following URL:
[ NOTE: link will only = work in Tor-enabled browsers ]

=85and = there=92s the thing: someone who is not using Tor will click on a link = and nothing will happen, exactly as (for instance) I visit a coffee shop = or my workplace and click on the bookmarked =93http://router.local/=93 = link which (when I am at home) would give me access to my DSL router=92s = control panel.

 I = suspect that most average users will just click on something w/out = realizing (ever!) it is a .onion name, and not a =93plain old link=94 to some = other page.

Quite.  I believe that that is, in fact, = rather the design goal.  Interoperability.  

The onion network space consists of software, = exactly like any other software (LAMP stacks, Wordpress, Facebook, etc) = which is just accessed via a different address space, the latter being = similarly to some VPN software.  

Equally, my aforementioned router.local link = *will* work when my VPN into my home network is working properly. =  

Similarly (again) - in my = browser bar there are any number of links - or, for that matter, SSH = connections - on the Facebook-internal corporate network which are not = accessible from (say) my local Starbucks, again unless I have my = corporate VPN software enabled - at which point everything magically = suddenly "just works".

(aside) This = is why I have always felt that using a scheme-change =93onion://=93 would not have been a = good design choice for Tor Onion Names; my work life would be = significantly more complex if I had to swap schemes when accessing a = site over a VPN, a-la htvpntp://non-dns-name.internal/foo.txt

Returning to your point:

However, the more I read this thread the more I am = convinced not much can be said/done.  Just like the = facebookXXX.onion versus facebookYYY.onion case, average users don=92t = pay enough attention to distinguish between facebook.com and faceboook.com, much less would they know that .onion (or any other name for that matter) is = special.  As you already wrote in the latest version, we can just = hope that the appropriate sw is updated to prevent the average user from = doing something they don=92t even understand that may result in some leakage of information.

Yes indeed, and I believe = that the Ballot-144-enabled adoption of EV Certificates, with their big = friendly green labels, will do a lot to reduce unwanted intermediary = risk in Onion space.

Also, in = passing, I do wish to point out, those =93fooXXX.onion.tld=94 proxies = which I have elsewhere presented as an unwanted risk, also do have a = wanted and important role to play in making the world more open and = connected; the (independent, non-Tor) Tor2web project was co-founded by = the late Aaron Swartz (of whom some of you may have heard / seen = documentaries?) in order to allow sites to publish via Tor to maintain = anonymity, and Tor2web serves as yet one more bridge for the larger = non-Tor world to access Tor/Onion resources.

More details on Tor2web are at https://en.wikipedia.org/wiki/Tor2web - but to = recap: there is a separate, parallel space of information out there, one = that has been available for about a decade, and in order to bring = greater trust to it and ensure that it is on a sound footing requires it = to be slotted into the bigger picture of the internet and = web. 

Hence this draft. =  It is what we are trying to do. :-)

   - alec

=97
Alec = Muffett
Security Infrastructure
Facebook Engineering
London

= --Apple-Mail=_2CCCE9C8-4129-46A9-A38F-1CD74B811BA1-- --Apple-Mail=_9FEAFDDD-3C98-41F8-9527-C8A32F229211 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJV5xElAAoJECldTB9TIAHGOQkP+we+sMkDx8TvYCRtatFSqpnu stbqdxH2Ll4TqovRQh10lo2DSOPuMUIW6qWjQfZy/CDEY0vHHdiVY4h45pneNzWo P13fBbFjWxAkNVeVJm20VjnW+BNLSW/7nv6ZgTUK2qWClJFSSbS0J+xgqMn3UaCU qQcPfcZluH4CsLmXGeQnx+qPWdrVrWXVhngOlsA8R8GUYmoyqVI4QpOHZrCWPH5W 4SdbOHGzEY/ViO7r5e46TtJb9oBYcSkyb9+mcugK5mGWB9wXkVaxYd3CVuO1H1sL 5gvb/yfLpggmY7x4pZrWzEbzsqp/IS/+JJGzXKYWwHCyc9gIUV2gvvrKzc50615T IPz9p2Z6NIOBCwqbjug6eHmDvPEtgxAtS+ivzl90URY1C+s7S/1sGd/wHXaa3zJy Oz2IT5jH97irtESGflNhRz6g2/mQ2iIQAXt040mzragvsni0R6nVE3Ev2ijB+Ghz kcgzKas2seWs4I+X9q7v7AIiaMzg0IBwRDqvt9jz0T2+pLf+x0V4zgZfbkI1qF4p fkkZMpu8+0svEw7KWZdnnfYxd5VWA77fU/ZlnUgxP+lvGNBpfQHNk7/sLfeZBkE2 rgKOocTuuDOsF+2ea5ashrVt1WyPe8UpRVaAWHq4fp9A8dp4IL6GmSCh9MKhUQw9 rIx+p859Uc1h74ErbY98 =uPNy -----END PGP SIGNATURE----- --Apple-Mail=_9FEAFDDD-3C98-41F8-9527-C8A32F229211-- From nobody Wed Sep 2 08:16:11 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34A61B4A92; Wed, 2 Sep 2015 08:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_75=0.6, SPF_PASS=-0.001] autolearn=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 k6zokEKiKxgx; Wed, 2 Sep 2015 08:16:08 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 480E41B4A93; Wed, 2 Sep 2015 08:16:08 -0700 (PDT) Received: by obcts10 with SMTP id ts10so10678920obc.1; Wed, 02 Sep 2015 08:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4/+ez9sfhxV/XjNMmhGisSyD8S9x/aWgzzNtvH7Qnt8=; b=zAY3saksIZ9Q3miaNdoHrtX+kpO45jkK3zhwU5ztQ8RTfPg94Vv7c5ReXwn1Z0MbND X6zyDjImsWMoI5XFIZeDYexmbwukhP5bjDfGGb5O64FVvuGTH76JokeuY9U5ICInQg51 BSTQ/4orgrwy3m4dvb2B0KB9S7vyLx+LMesHxMJi2GFrWL+/zK6mMY8m8a7zxCepE4vu h4SkQqXwEDpNZCEI7Vsq+M2fQVGSVcF3t9T9yvbDw7vTS2BpgZefSA7JfAZzgOSz9PVc UagmVL2Ve5XYLcLtIfW9DzVm6kC9+xHMSvBaa7Z2B0nqMZ297tQZp6pZBMtZBPUr+iNV xiAQ== MIME-Version: 1.0 X-Received: by 10.182.58.105 with SMTP id p9mr20125609obq.11.1441206967690; Wed, 02 Sep 2015 08:16:07 -0700 (PDT) Received: by 10.202.48.13 with HTTP; Wed, 2 Sep 2015 08:16:07 -0700 (PDT) In-Reply-To: References: <007601d0c2c3$7615b610$62412230$@huitema.net> <841F8AF6-D800-4232-A900-7FB3872DE1D7@fb.com> Date: Wed, 2 Sep 2015 11:16:07 -0400 Message-ID: From: Kathleen Moriarty To: Alec Muffett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: secdir , joel jaeggli , Mark Nottingham , "draft-ietf-dnsop-onion-tld.all@tools.ietf.org" , The IESG , Brad Hill Subject: Re: [secdir] Security review of draft-ietf-dnsop-onion-tld-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:16:09 -0000 Thanks to you and Mark for addressing the outstanding questions from the SecDir review and the one on "security properties". What threw me off is that what is described as security properties, I would call security controls. I'm not asking for a fix, but properties would be more like confidentiality, integrity, etc., which the names themselves do not provide. The controls and usage provide additional protection. Thanks, Kathleen On Wed, Sep 2, 2015 at 7:51 AM, Alec Muffett wrote: > > Ah, apologies, I see that I have just been unclear: > > > On Sep 2, 2015, at 12:36 PM, Alec Muffett wrote: > > I think Mark=E2=80=99s revisions nail this with the =E2=80=9Clegacy clien= t=E2=80=9D paragraph. :-) > > > =E2=80=A6nails the =E2=80=9Cblackholing DNS=E2=80=9D matter with the =E2= =80=9Clegacy client=E2=80=9D paragraph. :-) > > > I am quite confident that Mark=E2=80=99s latest diff: > > http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=3Dhttps://www.ietf.org/id/d= raft-ietf-dnsop-onion-tld-00.txt&url2=3Dhttp://mnot.github.io/I-D/dnsop-oni= on-tld/draft-ietf-dnsop-onion-tld-01.txt > > =E2=80=A6covers the =E2=80=9Chuman factors=E2=80=9D element quite well. > > > > The primary risks to users of Onion names are: > > * prefix collision phishing such as facebookXXX.onion versus > facebookYYY.onion > ** best mitigation: SSL, hence this draft > ** documented > > Users must take special precautions to ensure that the .onion name > they are communicating with is the intended one, as attackers may be > able to find keys which produce service names that are visually or > semantically similar to the desired service. This risk is magnified > because .onion names are typically not human-meaningful. It can be > mitigated by generating human meaningful .onion names (at > considerable computing expense), or through users using bookmarks and > other trusted stores when following links. > > > > * tld proxy-phishing facebookXXX.onion (real) versus facebookXXX.onion.tl= d > (proxy) > ** best mitigation: again, SSL, hence this draft > ** documented > > Also, users need to understand the difference between a .onion name > used and accessed directly via Tor-capable software, versus .onion > subdomains of other top-level domain names and providers (e.g., the > difference between example.onion and example.onion.tld). > > > > * leakage (risk to user) > ** best mitigation: use current software. DNS NXDOMAIN will help reduce > risk. > ** documented > > A legacy client may inadvertently attempt to resolve a ".onion" name > through the DNS. This causes a disclosure that the client is using > TOR to reach a specific service. Malicious resolvers could be > engineered to capture and record such leaks, which might have very > adverse consequences for the well-being of the TOR user. This issue > is mitigated if the client's TOR software is updated to not leak such > queries, or if the client's DNS software is updated to drop any > request to the ".onion" TLD. > > > > =E2=80=94 > Alec Muffett > Security Infrastructure > Facebook Engineering > London > --=20 Best regards, Kathleen From nobody Wed Sep 2 08:28:27 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FFC1AD0C8; Wed, 2 Sep 2015 08:28:23 -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 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 J-Vdak0epAmk; Wed, 2 Sep 2015 08:28:17 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1711B2BAC; Wed, 2 Sep 2015 08:28:16 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-6d-55e7158e9901 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6C.7A.17026.E8517E55; Wed, 2 Sep 2015 17:28:15 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.248.2; Wed, 2 Sep 2015 17:28:14 +0200 To: David Mandelberg , "avtext@ietf.org" , , , IESG References: <063cc84fb1eb8fbef30eda11ea7d8199@mail.mandelberg.org> From: Magnus Westerlund Message-ID: <55E7158D.5060304@ericsson.com> Date: Wed, 2 Sep 2015 17:28:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <063cc84fb1eb8fbef30eda11ea7d8199@mail.mandelberg.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+JvjW6/6PNQgyflFh/v3WC1uLHnDrvF io+72C1m/JnIbPFh4UMWB1aPJUt+Mnl8nPiSxePL5c9sAcxRXDYpqTmZZalF+nYJXBm7V75k K7ijUbF+4hH2BsYHCl2MnBwSAiYSy6d8ZYSwxSQu3FvP1sXIxSEkcJRR4sXJJVDOMkaJucve MINUCQs4S9w5/pIFJCEisI1RYmv3QrB2IQEniePHtjGB2GwCFhI3fzSygdi8AtoS25dMBmtm EVCReLbqI1i9qECMRM+vDVA1ghInZz5hAbE5QRZ8vQ42hxlozsz55xkhbHmJ5q2zmSF2aUs0 NHWwTmAUmIWkfRaSlllIWhYwMq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzgg1t+6+5g XP3a8RCjAAejEg9vwoRnoUKsiWXFlbmHGKU5WJTEeVuYHoQKCaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYPTd+0NU+P5NMWkOweW2e26utTu6wedy5Amjb73shSaujhcWiOl3Sex9z81c2n0l 3Kz9466q/ZMqg7LnTf/LPMl8XfM0Qbu7M7Tk7odUPbf12nRae7XT+14XK7mjCdF88Vq61ee7 K6Y/9vCr9ji6NpSP/38UE8t2VZc9C87/N+Kpe3gyjeFIvxJLcUaioRZzUXEiAFyJLhZBAgAA Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-avtext-rtp-stream-pause-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:28:23 -0000 Hi, Adding the WG. Back from vacation. Thanks for the good review. See inline for response. Den 2015-08-11 kl. 06:45, skrev David Mandelberg: > 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. > > I think this draft is Ready with issues, though the two issues are > relatively minor: > > 1. The Security Considerations section talks about protecting against > injection of PAUSE requests: > > The way of protecting the RTP session from these injections is to > perform source authentication combined with message integrity, to > prevent other than intended session participants from sending these > messages. > > I think this paragraph should also mention replay protection, which is > needed if the 16-bit PauseID wraps around and the attacker has access to > old PAUSE requests. Yes, we should mention replay attacks. I note that due to that the current PauseID starts at 0 and increments by one, it takes some time until we wrap. And also then you might have to hold onto a lot of messages to be able to attempt a replay. But, clearly we should recommend replay protection at the outer security layer. I propose that we add the following sentence in the second paragraph prior to the last sentence: The security solution should provide replay protection, otherwise an attacker could for sessions that are long lived enough to wrap the PauseID replay old messages at the appropriate time to influence the media sender state. > > 2. The next paragraph in Security Considerations talks about protecting > the multi-party use case against a single malicious participant by > individually authenticating participants. In addition to per-participant > authentication, I think there also needs to be a requirement for > attempted delivery of PAUSE requests to all participants. Without that > requirement, an attacker could cause the session to cycle through the > Playing, Pausing, and Paused states. To do that, the attacker would send > PAUSE requests only to the stream sender, instead of to the whole group. > Since no other participants receive the PAUSE request, they do not know > to send disapproving RESUMEs until after the stream sender has already > paused the stream. (I should note that I'm not particularly familiar > with multicast network operations. If it's infeasible for one > participant to send a message to another participant without the rest of > the group also receiving the message, then I apologize for bringing up a > non-issue.) Yes, you are correct that getting a malicious PAUSE message sent to multiple participants provides a mitigation in that the other participants can counter it. That I would expect to happen in multicast cases where anyone can send RTCP messages. It will fully depend on the multicast topology if an on-path attacker has any chance of getting its messages delivered to the media stream endpoint and not getting forwarded to other endpoints over the multicast tree. In the cases of the RTP middleboxes providing the multi-party functionality it will depend on the mode of operation of that middlebox. But, assuming the middlebox isn't compromised it will act on behalf of the whole session. It either works as multicast emulator and should forward it to everyone, or it will receive the request, and only forward it if fits the rest of the session state. Proposed text for the end of Paragraph three: An attacker that can send a PAUSE request without it reaching any other participant than the media sender can have its request being unopposed. This is mitigated in multi-party topologies that ensure that requests are seen by all or most of the RTP session participants, enabling these participants to send RESUME. In topologies with middleboxes that consume and process PAUSE requests, the middlebox can also mitigate such behavior as it will commonly not generate or forward a PAUSE message if it knows of another participant having use for the media stream. Comments on this? > > ----- > > I also have a few nits: > > Abstract: The RTCP initialism is used without definition. > > Section 5.4: The SR initialism is used without definition. > > Section 6.4: I'd suggest changing "As for Paused State" to "As with > Paused State". That sentence could also be split up for better readability. > Incorporated. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Sep 3 02:42:53 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DB91B2E7B; Thu, 3 Sep 2015 02:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Gm_uitGloYow; Thu, 3 Sep 2015 02:42:46 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325301B2A7C; Thu, 3 Sep 2015 02:42:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.17,461,1437429600"; d="asc'?scan'208";a="144607388" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Sep 2015 11:42:44 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CFE0695F-ACD9-442A-80A5-7356A4941070"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Vincent Roca In-Reply-To: Date: Thu, 3 Sep 2015 11:42:42 +0200 Message-Id: <6F5CD972-6AC1-490B-ABF7-AC14E7EE422F@inria.fr> References: <7DBFEE57-B11D-4A09-94A5-86C386E77FC2@inria.fr> To: Adam Langley X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IESG , draft-ietf-tls-padding@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-tls-padding-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 09:42:49 -0000 --Apple-Mail=_CFE0695F-ACD9-442A-80A5-7356A4941070 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Adam, > On Mon, Aug 31, 2015 at 9:16 AM, Vincent Roca = wrote: >> That=E2=80=99s perhaps a naive question, but let me ask it. = Shouldn=E2=80=99t a receiver >> check >> that the actual length of the extension_data field is in line with = the value >> of the >> extension_data length field. Since those zero bytes are actually = carried >> over >> the net and present in the reception buffer, there could be several = ways to >> calculate this length=E2=80=A6 (I really don=E2=80=99t know if it=E2=80= =99s the case or not) >=20 > I don't think that we want to pin down the exact length of the padding > and would rather leave it up to the sender. Although, for now, we have > only a single use case for this, some other uses have been > suggested(*) and it would be nice just to have a single padding > extension if we decide that we need them in the future. >=20 > (*) for example, padding a DTLS ClientHello to reduce the > amplification factor of DTLS. There is a misunderstanding here. Let me reformulate. What happens if the sender specifies an extension_data length value that differs (i.e., the value is either smaller or larger) from the = actual padding extension in the packet sent? Well, it depends how it=E2=80=99s implemented at a receiver=E2=80=A6 My point was to suggest the receiver = to check this extension_data length value carefully before processing it. Perhaps this comment is too paranoid? Perhaps the way it works avoids problems? In that case just ignore it. >> Additionally, section 3 says: >>=20 >> The client MUST fill the padding extension completely with zero >> bytes, although the padding extension may be empty. >>=20 >> I think that you mean =C2=AB padding extension_data field =C2=BB and = not =C2=AB padding >> extension =C2=BB: >=20 > Done, thanks. >=20 >> And finally, in the example (figure), instead of: >>=20 >> 16-bit, extension_data length >>=20 >> I=E2=80=99d rather add a =C2=AB _ =C2=BB as in: >>=20 >> 16-bit, extension_data_length >=20 > Although I don't have strong feelings either way, I didn't make this > change. In the TLS 1.2 RFC > (https://tools.ietf.org/html/rfc5246#section-7.4.1.4), extension_data > is a named field, but extension_data_length is not. Rather it's an > implicit part of extension_data. Since this draft isn't defining > anything new about extensions in general, I feel that it shouldn't > name new things here. I understand, no problem. Cheers, Vincent --Apple-Mail=_CFE0695F-ACD9-442A-80A5-7356A4941070 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJV6BYTAAoJEHBYw8t72N4r+0AQAIp0og9iQcbalALYWgVUTkHR 8fLfzOwkiQlf20dDbqxQoDRbODE3hiPnKVOfgYMJy6T9geUvwzuFLOFQbW2OgiV4 0zc/ePSa3Q+EpsPS5Gh4gkWvpLVkdg3S9pUVnmsXjjwJV26SMBmgRMO1301UVLM7 Oh5KabY7J32ArqeXr4huHClUkXKIz8f0t0xVJLMF7E4f555YtCPplxY+Kvo4gneu mE2Vrde5nq2lzbJ+gwgUYN5QoXtxXjnDo3VP1R2jpH6eYasRlqj5TwTvSa27kRHi tCJxQ+PZk8Zxmt3uKrb2bgCiosxr0Kmf+k5/olEqFWlyFbCfK7ky5NCFjQ/m2AmY mndisYE1pc/I2EeC4cgt/NdQUdmxbZuWolokMpriXzaN/Q6ATwD2nE4UlFCtHPPc gM048WlAD/jKcOvix888ZVT2OXDduOc/VT0PLQmOGtnJwp+XSOh1EPcu+lu51kaM VkY2hdkTCowSuGbNHw3ZaQEnNREe7RFyE0P+WiBjh467HZ7hjAniTwz3FtwtddYb L3wtCTq8EnZRqhCsmTjIEA5AX4us86MY+cK92yXSC41UsjIfr61OEFxMjQVJg/7B gwZR0dfw3SeogRgkNHrYaXE+iy6B1xHx6CYqcwXOdnsp5t2rA3a3b9pVT/4g301i D53oQ4BaC5IHSPpW/uoZ =Yj85 -----END PGP SIGNATURE----- --Apple-Mail=_CFE0695F-ACD9-442A-80A5-7356A4941070-- From nobody Thu Sep 3 04:08:26 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4CB1B3308 for ; Thu, 3 Sep 2015 04:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 jxoM_9v1KdCT for ; Thu, 3 Sep 2015 04:08:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 391A31B38B3 for ; Thu, 3 Sep 2015 04:08:20 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t83AoEOe028381 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 3 Sep 2015 13:50:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t83AoEJH014317; Thu, 3 Sep 2015 13:50:14 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21992.9702.118332.165160@fireball.acr.fi> Date: Thu, 3 Sep 2015 13:50:14 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 11:08:25 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Shawn Emery is next in the rotation. For telechat 2015-09-03 Reviewer LC end Draft Dave Cridland T 2015-07-27 draft-bradner-iaoc-terms-04 Russ Mundy T 2015-08-14 draft-ietf-payload-rtp-h265-14 For telechat 2015-09-17 Chris Inacio T 2015-07-29 draft-ietf-homenet-dncp-09 Ben Laurie T 2015-08-11 draft-ietf-dnsop-dns-terminology-04 Yoav Nir TR2015-06-11 draft-ietf-pcp-anycast-07 Hannes Tschofenig TR2015-09-17 draft-wkumari-dhc-capport-16 Carl Wallace T 2015-09-01 draft-ietf-trill-pseudonode-nickname-05 For telechat 2015-10-01 Frank Xialiang T 2015-09-03 draft-ietf-conex-mobile-05 Last calls and special requests: Derek Atkins 2015-09-23 draft-kivinen-ipsecme-oob-pubkey-11 John Bradley 2015-09-03 draft-ietf-mpls-lsp-ping-reply-mode-simple-03 Shaun Cooley 2015-09-08 draft-ietf-mpls-mldp-node-protection-05 Dave Cridland 2015-09-08 draft-ietf-pals-vccv-for-gal-05 Alan DeKok 2015-09-10 draft-ietf-ippm-owamp-registry-02 Donald Eastlake 2015-09-11 draft-ietf-dane-openpgpkey-05 Daniel Kahn Gillmor E None draft-ietf-rtcweb-security-08 Tobias Gondrom E None draft-ietf-rtcweb-security-arch-11 Matt Lepinski 2015-08-11 draft-ietf-dnsop-root-loopback-03 Joe Salowey 2015-09-07 draft-josefsson-scrypt-kdf-03 Hannes Tschofenig 2015-09-15 draft-ietf-grow-bmp-15 Brian Weis 2015-09-23 draft-housley-sow-author-statistics-00 Klaas Wierenga 2015-09-09 draft-ietf-6man-predictable-fragment-id-09 Paul Wouters 2015-09-09 draft-ietf-ccamp-flexigrid-lambda-label-04 Tom Yu 2015-09-08 draft-ietf-dhc-dhcpv4-active-leasequery-05 Dacheng Zhang 2015-09-04 draft-ietf-dice-profile-14 -- kivinen@iki.fi From nobody Sun Sep 6 13:48:33 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6971B2EA8; Sun, 6 Sep 2015 13:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 DhZ5nlMOBlJz; Sun, 6 Sep 2015 13:48:29 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 764E31B2E8D; Sun, 6 Sep 2015 13:48:28 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so69379597wic.0; Sun, 06 Sep 2015 13:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=ooMorlS8OSAEPUAHNTVMpU/CtTd9NnknkPdUuCrZE8k=; b=ns3e5rJVVXUlINqjM6wKs4zOeT6rXVEd2TQwQHaiQRq41epnrRvlK3uUaSJvLo7VCd 1jXbuUWfvte+ch/LSVPg+a/XBfmeYwoYBSYPgkRB9DB0Um7ZZJBQdXNNasytBtkW0caf K3o+QVAESpkiWyVQoTfTAuJkJHbIfdMJDNGSsRSgqJ7uGerV5W97bRAaKmuK49U4L5HZ inHWjR7vjRNXCUBZsRUkTsxzNP9uKywuhtpbDYHZzZ3hVH3TDNlI67fDYf26UOB8DWPv xChIWIgFDLidU1W8Zdp2ulRNEvs81f3QpGpcWyLpcy3L7JmRUamecB+gxJxOaAoes/2z YIDA== X-Received: by 10.194.171.4 with SMTP id aq4mr21981807wjc.114.1441572506925; Sun, 06 Sep 2015 13:48:26 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id pe1sm16785715wic.20.2015.09.06.13.48.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Sep 2015 13:48:25 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_3B8363FD-2891-4519-9DA2-669293E098E3" Message-Id: <7E152A69-3AA8-4F30-B1C1-F8A8E2C2BF06@gmail.com> Date: Sun, 6 Sep 2015 23:48:23 +0300 To: secdir , The IESG , draft-ietf-pcp-anycast.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [secdir] SecDir Review of draft-ietf-pcp-anycast-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 20:48:31 -0000 --Apple-Mail=_3B8363FD-2891-4519-9DA2-669293E098E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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. TL;DR: Ready (with a question) Note that I have already reviewed version -06 of this draft in June. My = review and a response by Christian Huitema are attached below.=20 Verstion -07 addresses Christian=E2=80=99s concern about the lack of = advice about the proper TTL to set on the packets. I=E2=80=99m not sure = it *properly* addresses his concerns, because what they=E2=80=99ve added = is =E2=80=9Cmethods for choosing an appropriate TTL value ... is beyond = the scope of this document" Regards, Yoav > Begin forwarded message: >=20 > From: "Christian Huitema" > Subject: RE: [secdir] SecDir Review of draft-ietf-pcp-anycast-06 > Date: June 10, 2015 at 12:33:30 AM GMT+3 > To: "'Yoav Nir'" , "'secdir'" , = "'The IESG'" , = >=20 >> There are two specific concerns about this method (other than the = usual >> anycast or pcp concerns). The first is that information about the = internal >> network might leak to a PCP service outside the network.=20 >=20 > In fact, it is almost guaranteed to leak outside of the network. In = the initial deployments, first hop routers will not be aware of the = anycast address... >=20 >> ... Whereas a failure of >> a service whose address is given in DHCP will result in black-holed = packets, >> failure of a service with an anycast address will cause the packets = to be >> forwarded to some random PCP server on the Internet. Section 5.1 = discusses >> this and recommends filtering in perimeter gateways and reduced TTL. = I >> believe this addresses that threat adequately. >=20 > I would find the TTL mitigation would be more convincing if the draft = actually specified a recommended TTL value. >=20 > -- Christian Huitema >=20 >=20 >=20 >=20 > Begin forwarded message: >=20 > From: Yoav Nir > Subject: SecDir Review of draft-ietf-pcp-anycast-06 > Date: June 8, 2015 at 6:00:38 PM GMT+3 > To: secdir , The IESG , = draft-ietf-pcp-anycast.all@tools.ietf.org >=20 > Hi. >=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 > TL;DR: Ready (with a question) >=20 > The document describes an alternative method for nodes behind a = middlebox (such as NAT device or firewall) to contact the middlebox in = order to manage port allocation. Existing methods (described in RFC 6887 = and 7291 respectively) are to either assume that the default router is = the device (suitable for small networks) or specify the middlebox = address in a DHCP option (suitable for larger networks). >=20 > This document proposes a third alternative: use of a well-known = anycast address. Sending a request to that anycast address will ensure = delivery to the closest service address (which may or may not be = co-located with the middlebox) by the routing on the network, supported = by either BGP or IGP. >=20 > There are two specific concerns about this method (other than the = usual anycast or pcp concerns). The first is that information about the = internal network might leak to a PCP service outside the network. = Whereas a failure of a service whose address is given in DHCP will = result in black-holed packets, failure of a service with an anycast = address will cause the packets to be forwarded to some random PCP server = on the Internet. Section 5.1 discusses this and recommends filtering in = perimeter gateways and reduced TTL. I believe this addresses that threat = adequately. >=20 > The other specific concern is that a rogue machine would push routes = to advertise itself as a PCP service, hijacking PCP traffic and causing = network outages. Section 5.2 deals with this issue. The section makes = the claim that within the first network segment, the nodes do not use = dynamic routing protocols, so an attack there is equivalent to = impersonating the default router. Outside the first segment, routing = protocols are used, and there is a need for routing security anyway. In = both cases an attacker capable of conducting these attacks can do a lot = worse than impersonating a PCP service. >=20 > I find this argument almost convincing. What is still bothering me is = the question of whether the more damaging attacks would be discovered = immediately, whereas simply advertising a route to the anycast address = can =E2=80=9Cfly under the radar=E2=80=9D so that the attacker can = become the PCP server undetected. I don=E2=80=99t have a firm attack in = mind, just a mild concern. >=20 > Yoav >=20 --Apple-Mail=_3B8363FD-2891-4519-9DA2-669293E098E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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.

TL;DR: Ready (with a question)

Note that I have already = reviewed version -06 of this draft in June. My review and a response by = Christian Huitema are attached below. 

Verstion -07 addresses Christian=E2=80=99= s concern about the lack of advice about the proper TTL to set on the = packets. I=E2=80=99m not sure it *properly* addresses his concerns, = because what they=E2=80=99ve added is =E2=80=9Cmethods for choosing = an appropriate TTL value ... is beyond the scope of this = document"

Regards,

Yoav

Begin forwarded message:

From: = "Christian Huitema" <huitema@huitema.net>
Subject: = RE: [secdir] = SecDir Review of draft-ietf-pcp-anycast-06
Date: = June 10, 2015 at 12:33:30 AM = GMT+3
To: = "'Yoav Nir'" <ynir.ietf@gmail.com>, "'secdir'" <secdir@ietf.org>, = "'The IESG'" <iesg@ietf.org>, <draft-ietf-pcp-anycast.all@tools.ietf.org>

There are two specific concerns about this = method (other than the usual
anycast or pcp concerns). The = first is that information about the internal
network might = leak to a PCP service outside the network.
In fact, it is almost guaranteed to leak outside of the = network. In the initial deployments, first hop routers will not be aware = of the anycast address...

... Whereas a failure of
a = service whose address is given in DHCP will result in black-holed = packets,
failure of a service with an anycast address will = cause the packets to be
forwarded to some random PCP = server on the Internet. Section 5.1 discusses
this and = recommends filtering in perimeter gateways and reduced TTL. I
believe this addresses that threat adequately.

I would find the TTL mitigation = would be more convincing if the draft actually specified a recommended = TTL value.

-- Christian Huitema




Begin forwarded message:

From: = Yoav Nir <ynir.ietf@gmail.com>
Subject: = SecDir Review of = draft-ietf-pcp-anycast-06
Date: = June 8, 2015 at 6:00:38 PM = GMT+3

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.

TL;DR: Ready (with a question)

The document describes an alternative method = for nodes behind a middlebox (such as NAT device or firewall) to contact = the middlebox in order to manage port allocation. Existing methods = (described in RFC 6887 and 7291 respectively) are to either assume that = the default router is the device (suitable for small networks) or = specify the middlebox address in a DHCP option (suitable for larger = networks).

This document proposes a third = alternative: use of a well-known anycast address. Sending a request to = that anycast address will ensure delivery to the closest service address = (which may or may not be co-located with the middlebox) by the routing = on the network, supported by either BGP or IGP.

There are two specific concerns about this method (other than = the usual anycast or pcp concerns). The first is that information about = the internal network might leak to a PCP service outside the network. = Whereas a failure of a service whose address is given in DHCP will = result in black-holed packets, failure of a service with an anycast = address will cause the packets to be forwarded to some random PCP server = on the Internet. Section 5.1 discusses this and recommends filtering in = perimeter gateways and reduced TTL. I believe this addresses that threat = adequately.

The other specific concern is = that a rogue machine would push routes to advertise itself as a PCP = service, hijacking PCP traffic and causing network outages. Section 5.2 = deals with this issue. The section makes the claim that within the first = network segment, the nodes do not use dynamic routing protocols, so an = attack there is equivalent to impersonating the default router. Outside = the first segment, routing protocols are used, and there is a need for = routing security anyway. In both cases an attacker capable of conducting = these attacks can do a lot worse than impersonating a PCP service.

I find this argument almost convincing. What = is still bothering me is the question of whether the more damaging = attacks would be discovered immediately, whereas simply advertising a = route to the anycast address can =E2=80=9Cfly under the radar=E2=80=9D = so that the attacker can become the PCP server undetected. I don=E2=80=99t= have a firm attack in mind, just a mild concern.

Yoav


= --Apple-Mail=_3B8363FD-2891-4519-9DA2-669293E098E3-- From nobody Sun Sep 6 18:23:30 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F9C1B384C; Sun, 6 Sep 2015 18:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4gPMl9wBz1YD; Sun, 6 Sep 2015 18:23:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16721B2E85; Sun, 6 Sep 2015 18:23:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAX15990; Mon, 07 Sep 2015 01:23:22 +0000 (GMT) Received: from SZXEML422-HUB.china.huawei.com (10.82.67.152) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 7 Sep 2015 02:23:21 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.212]) by szxeml422-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.03.0235.001; Mon, 7 Sep 2015 09:23:16 +0800 From: Tina TSOU To: Venkatesan Mahalingam Thread-Topic: Secdir review of draft-ietf-mpls-tp-oam-id-mib-08 Thread-Index: AQHQ5L/gEot3P+eKLk6oIdN2iw08Qp4oF68AgAAvEgCACAZHMA== Date: Mon, 7 Sep 2015 01:23:15 +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: [10.66.87.91] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A818DC324Aszxeml557mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-mpls-tp-oam-id-mib.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-tp-oam-id-mib-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 01:23:28 -0000 --_000_C0E0A32284495243BDE0AC8A066631A818DC324Aszxeml557mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBWZW5rYXQsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBwcm9tcHQgcmVwbHkuDQoNCkkgcmV2 aWV3ZWQgLTA5LCBpdCBzb2x2ZXMgbXkgcHJldmlvdXMgY29tbWVudHMuDQoNCg0KVGhhbmsgeW91 LA0KVGluYQ0KDQpGcm9tOiBWZW5rYXRlc2FuIE1haGFsaW5nYW0gW21haWx0bzp2ZW5rYXQubWFo YWxpbmdhbXNAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDIsIDIwMTUg Mjo0NyBQTQ0KVG86IFRpbmEgVFNPVQ0KQ2M6IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1t cGxzLXRwLW9hbS1pZC1taWIuYWxsQHRvb2xzLmlldGYub3JnOyBUaGUgSUVTRw0KU3ViamVjdDog UmU6IFNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1taWItMDgNCg0K VGluYSwNCg0KV2UgaGF2ZSBwdWJsaXNoZWQgdGhlIG5ldyB2ZXJzaW9uIDA5LCBwbGVhc2UgZ28g dGhyb3VnaCB0aGUgZGlmZiwgaWYgeW91IGhhdmUgYW55IGZ1cnRoZXIgY29tbWVudHMsIHBsZWFz ZSBsZXQgdXMga25vdy4NCg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYi0wOS50eHQNClN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1w bHMtdHAtb2FtLWlkLW1pYi8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1pZC1taWItMDkNCkRpZmY6ICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tcGxzLXRwLW9hbS1p ZC1taWItMDkNCg0KPj5UaGUgdGl0bGUgb2YgdGhpcyBkcmFmdCBpbmRpY2F0ZXMgbWliIGZvciBN UExTLVRQIE9BTSBJRCBidXQgaW4gdGhlIGJvZHkgTVBMUyBpcyB1c2VkIG1vc3RseSBhbmQgc29t ZXRpbWVzIE1QTFMtVFAgYXBwZWFycywgZm9yIGV4YW1wbGUsIGJvdGggTVBMUyB0dW5uZWxzIGFu ZCBNUExTLVRQIHR1bm5lbHMgYXJlIG1lbnRpb25lZC4gSSdtIG5vdCBzdXJlIGlmIHRoZXkgY2Fu IGJlIHVzZWQgPj5pbnRlcmNoYW5nZWFibGUuIEJlc2lkZXMsIEkgbm90aWNlIHRoYXQgdGhlIG5h bWVzIGZvciB0aGUgb2JqZWN0cyBhbGwgc3RhcnQgd2l0aCAibXBsc29hbWlkeHh4Iiwgd2hpY2gg c2VlbXMgdG8gYWRkcmVzcyBtaWIgZm9yIE1QTFMgT0FNIElELiBUaGVuIGl0IGlzIG5vdCBhbGln bmVkIHdpdGggdGhlIHRpdGxlIG9mIHRoaXMgZHJhZnQuIEEgYml0IGNvbmZ1c2VkLiBDb3VsZCB0 aGUgYXV0aG9ycyBwcm92aWRlID4+YW55IGNsYXJpZmljYXRpb24gb24gdGhpcz8gQSBnZW5lcmFs IHN1Z2dlc3Rpb24gaXMgdG8gbWFrZSBhbGlnbm1lbnQgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQs IGluY2x1ZGluZyB0aGUgdGl0bGUgb2YgdGhlIGRyYWZ0Lg0KDQpBcyBMb2Egc3VnZ2VzdGVkLCB3 ZSBoYXZlIGluY2x1ZGVkIE1QTFMtVFAgKGFzIHdlIGRvIHRoaXMgd29yayBhcyBwYXJ0IG9mIE1Q TFMtVFApIGluIHRoZSB0aXRsZSBidXQgdGhpcyBkcmFmdCBhY3R1YWxseSBkZXNjcmliZXMgdGhl IG1hbmFnZWQgb2JqZWN0IGZvciBib3RoIE1QTFMgYW5kIE1QTFMtVFAgdHVubmVsIGlkZW50aWZp ZXJzLg0KDQoNCi1WZW5rYXQuDQoNCk9uIFR1ZSwgU2VwIDEsIDIwMTUgYXQgODo1OCBQTSwgVmVu a2F0ZXNhbiBNYWhhbGluZ2FtIDx2ZW5rYXQubWFoYWxpbmdhbXNAZ21haWwuY29tPG1haWx0bzp2 ZW5rYXQubWFoYWxpbmdhbXNAZ21haWwuY29tPj4gd3JvdGU6DQpUaGFua3MgZm9yIHlvdXIgY29t bWVudHMgVGluYSwgd2lsbCBhZGRyZXNzIGFuZCBwdWJsaXNoIHRoZSBuZXcgdmVyc2lvbiAwOSBz b29uLg0KDQotVmVua2F0LA0KDQpPbiBUdWUsIFNlcCAxLCAyMDE1IGF0IDc6MDkgQU0sIFRpbmEg VFNPVSA8VGluYS5Uc291LlpvdXRpbmdAaHVhd2VpLmNvbTxtYWlsdG86VGluYS5Uc291LlpvdXRp bmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KRGVhciBhbGwsDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlz IGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBl ZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhl IElFU0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5l Zml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQg V0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVy IGxhc3QgY2FsbCBjb21tZW50cy4NClRoZSBkb2N1bWVudCBzZWVtcyByZWFkeSB0byBnby4gSSBv bmx5IGZvdW5kIHRoZXNlIG1pbm9yIG5pdHM6DQoNClRoZSB0aXRsZSBvZiB0aGlzIGRyYWZ0IGlu ZGljYXRlcyBtaWIgZm9yIE1QTFMtVFAgT0FNIElEIGJ1dCBpbiB0aGUgYm9keSBNUExTIGlzIHVz ZWQgbW9zdGx5IGFuZCBzb21ldGltZXMgTVBMUy1UUCBhcHBlYXJzLCBmb3IgZXhhbXBsZSwgYm90 aCBNUExTIHR1bm5lbHMgYW5kIE1QTFMtVFAgdHVubmVscyBhcmUgbWVudGlvbmVkLiBJJ20gbm90 IHN1cmUgaWYgdGhleSBjYW4gYmUgdXNlZCBpbnRlcmNoYW5nZWFibGUuIEJlc2lkZXMsIEkgbm90 aWNlIHRoYXQgdGhlIG5hbWVzIGZvciB0aGUgb2JqZWN0cyBhbGwgc3RhcnQgd2l0aCAibXBsc29h bWlkeHh4Iiwgd2hpY2ggc2VlbXMgdG8gYWRkcmVzcyBtaWIgZm9yIE1QTFMgT0FNIElELiBUaGVu IGl0IGlzIG5vdCBhbGlnbmVkIHdpdGggdGhlIHRpdGxlIG9mIHRoaXMgZHJhZnQuIEEgYml0IGNv bmZ1c2VkLiBDb3VsZCB0aGUgYXV0aG9ycyBwcm92aWRlIGFueSBjbGFyaWZpY2F0aW9uIG9uIHRo aXM/IEEgZ2VuZXJhbCBzdWdnZXN0aW9uIGlzIHRvIG1ha2UgYWxpZ25tZW50IHRocm91Z2hvdXQg dGhlIGRvY3VtZW50LCBpbmNsdWRpbmcgdGhlIHRpdGxlIG9mIHRoZSBkcmFmdC4NCg0KKiBBYnN0 cmFjdDoNCg0KPiBpdCBkZXNjcmliZXMgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24sIGFuZCBN YW5hZ2VtZW50IChPQU0pDQo+IGlkZW50aWZpZXJzIHJlbGF0ZWQgbWFuYWdlZCBvYmplY3RzIGZv ciBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZw0KPiAoTVBMUykgYW5kIE1QTFMgYmFzZWQg VHJhbnNwb3J0IFByb2ZpbGUgKFRQKS4NCg0KSSBmaW5kIHRoaXMgc2VudGVuY2UgaGFyZCB0byBw YXJzZS4gTWF5YmUgcy9yZWxhdGVkIG1hbmFnZWQgb2JqZWN0cy9yZWxhdGVkIHRvIG1hbmFnZWQg b2JqZWN0cy8gPw0KDQoNCiogU2VjdGlvbiAxLCBwYWdlIDM6DQo+IE1QTFMgTFNQKExhYmVsDQoN ClRoZXJlJ3MgYSBtaXNzaW5nIHNwYWNlLg0KDQoNCiogU2VjdGlvbiA1LjEsIHBhZ2UgNDoNCg0K PiBUaGUgbXBsc09hbUlkTWVnVGFibGUgaXMgdXNlZCB0byBtYW5hZ2Ugb25lIG9yIG1vcmUgTWFp bnRlbmFuY2UNCj4gRW50aXRpZXMgKE1FcykgdGhhdCBiZWxvbmdzDQoNCnMvYmVsb25ncy9iZWxv bmcvDQoNCg0KKiBTZWN0aW9uIDYsIGNvcHkmcGFzdGUgbWlzdGFrZQ0KDQotLSBTb3VyY2UgTUVQ IGlkIGlzIGRlcml2ZWQgZnJvbSB0aGUgSVAgY29tcGF0aWJsZSBNUExTIExTUA0KICAgICAgIG1w bHNPYW1JZE1lU2lua01lcEluZGV4ICAgICAgICAgICA9IDAsDQoNClRoZSBkZXNjcmlwdGlvbiBp biB0aGUgbm90ZSBzaG91bGQgYmUgc2luayBNRVAuIFRoZXJlIGlzIGFscmVhZHkgYW5vdGhlciBs aW5lIHRvIGRlc2NyaWJlIHNvdXJjZSBNRVAuDQoNCg0KKiBQYWdlIDE1Og0KDQo+IEJGRA0KDQpU aGlzIGlzIHRoZSBmaXJzdCBhbmQgb25seSBpbnN0YW5jZSBvZiBCRkQuIFBsZWFzZSBleHBhbmQu IChhbmQgbWF5YmUgcmVmZXJlbmNlIFJGQzU4ODApPw0KDQoNCiogUGFnZSAxNzoNCg0KInAycCIg YW5kICJQMlAiIGZpcnN0IHVzZWQgaGVyZS4gc2hvdWxkIHByb2JhYmx5IGJlIGV4cGFuZGVkLg0K DQoNClRoYW5rIHlvdSwNClRpbmENCg0KDQoNCg== --_000_C0E0A32284495243BDE0AC8A066631A818DC324Aszxeml557mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJGcmVlc3R5bGUgU2NyaXB0IjsN CglwYW5vc2UtMTozIDggNCAyIDMgMiA1IDExIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQEFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCBVbmljb2RlIE1TIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlm eTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+RGVhciBWZW5rYXQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6 aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlk ZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGFuayB5b3UgZm9yIHlvdXIgcHJvbXB0IHJlcGx5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4 dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlm eTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SSByZXZpZXdlZCAtMDksIGl0IHNvbHZlcyBteSBwcmV2aW91cyBj b21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246 anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7RnJlZXN0eWxlIFNjcmlw dCZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3Rp Znk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7RnJlZXN0eWxlIFNjcmlwdCZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaW5hPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsIFVuaWNvZGUgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBWZW5rYXRlc2FuIE1haGFsaW5nYW0gW21haWx0bzp2ZW5rYXQubWFoYWxp bmdhbXNAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgU2VwdGVtYmVy IDAyLCAyMDE1IDI6NDcgUE08YnI+DQo8Yj5Ubzo8L2I+IFRpbmEgVFNPVTxicj4NCjxiPkNjOjwv Yj4gc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYi5hbGxAdG9v bHMuaWV0Zi5vcmc7IFRoZSBJRVNHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBTZWNkaXIgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtbXBscy10cC1vYW0taWQtbWliLTA4PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5UaW5hLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPldlIGhhdmUgcHVibGlzaGVkIHRoZSBuZXcgdmVyc2lvbiAwOSwgcGxlYXNlIGdvIHRo cm91Z2ggdGhlIGRpZmYsIGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNvbW1lbnRzLCBwbGVhc2Ug bGV0IHVzIGtub3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5VUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAt b2FtLWlkLW1pYi0wOS50eHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuNXB0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1t cGxzLXRwLW9hbS1pZC1taWItMDkudHh0PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxicj4NClN0YXR1czombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1p Yi8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtdHAtb2FtLWlkLW1pYi88 L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dCI+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1tcGxzLXRwLW9hbS1pZC1taWItMDkiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1t cGxzLXRwLW9hbS1pZC1taWItMDk8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PGJyPg0KRGlmZjombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXBscy10cC1vYW0taWQt bWliLTA5IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbXBscy10cC1vYW0taWQt bWliLTA5PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0O1Ro ZSB0aXRsZSBvZiB0aGlzIGRyYWZ0IGluZGljYXRlcyBtaWIgZm9yIE1QTFMtVFAgT0FNIElEIGJ1 dCBpbiB0aGUgYm9keSBNUExTIGlzIHVzZWQgbW9zdGx5IGFuZCBzb21ldGltZXMgTVBMUy1UUCBh cHBlYXJzLCBmb3IgZXhhbXBsZSwgYm90aA0KIE1QTFMgdHVubmVscyBhbmQgTVBMUy1UUCB0dW5u ZWxzIGFyZSBtZW50aW9uZWQuIEknbSBub3Qgc3VyZSBpZiB0aGV5IGNhbiBiZSB1c2VkICZndDsm Z3Q7aW50ZXJjaGFuZ2VhYmxlLiBCZXNpZGVzLCBJIG5vdGljZSB0aGF0IHRoZSBuYW1lcyBmb3Ig dGhlIG9iamVjdHMgYWxsIHN0YXJ0IHdpdGggJnF1b3Q7bXBsc29hbWlkeHh4JnF1b3Q7LCB3aGlj aCBzZWVtcyB0byBhZGRyZXNzIG1pYiBmb3IgTVBMUyBPQU0gSUQuIFRoZW4gaXQgaXMgbm90IGFs aWduZWQgd2l0aCB0aGUNCiB0aXRsZSBvZiB0aGlzIGRyYWZ0LiBBIGJpdCBjb25mdXNlZC4gQ291 bGQgdGhlIGF1dGhvcnMgcHJvdmlkZSAmZ3Q7Jmd0O2FueSBjbGFyaWZpY2F0aW9uIG9uIHRoaXM/ IEEgZ2VuZXJhbCBzdWdnZXN0aW9uIGlzIHRvIG1ha2UgYWxpZ25tZW50IHRocm91Z2hvdXQgdGhl IGRvY3VtZW50LCBpbmNsdWRpbmcgdGhlIHRpdGxlIG9mIHRoZSBkcmFmdC48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIExvYSBzdWdnZXN0 ZWQsIHdlIGhhdmUgaW5jbHVkZWQgTVBMUy1UUCAoYXMgd2UgZG8gdGhpcyB3b3JrIGFzIHBhcnQg b2YgTVBMUy1UUCkgaW4gdGhlIHRpdGxlIGJ1dCB0aGlzIGRyYWZ0IGFjdHVhbGx5IGRlc2NyaWJl cyB0aGUgbWFuYWdlZCBvYmplY3QNCiBmb3IgYm90aCBNUExTIGFuZCBNUExTLVRQIHR1bm5lbCBp ZGVudGlmaWVycy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pi1WZW5rYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5PbiBUdWUsIFNlcCAxLCAyMDE1IGF0IDg6NTggUE0sIFZlbmthdGVzYW4gTWFoYWxpbmdhbSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnZlbmthdC5tYWhhbGluZ2Ftc0BnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj52ZW5rYXQubWFoYWxpbmdhbXNAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMgVGluYSwgd2lsbCBhZGRyZXNzIGFuZCBw dWJsaXNoIHRoZSBuZXcgdmVyc2lvbiAwOSBzb29uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPi1WZW5rYXQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgU2VwIDEsIDIwMTUgYXQgNzow OSBBTSwgVGluYSBUU09VICZsdDs8YSBocmVmPSJtYWlsdG86VGluYS5Uc291LlpvdXRpbmdAaHVh d2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlRpbmEuVHNvdS5ab3V0aW5nQGh1YXdlaS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5EZWFyIGFsbCw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBo YXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0 b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcNCiBhbGwgSUVURiBkb2N1bWVudHMgYmVp bmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJp bWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERv Y3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMg anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoZSBkb2N1bWVudCBzZWVtcyByZWFkeSB0byBnby4gSSBvbmx5IGZvdW5kIHRoZXNlIG1p bm9yIG5pdHM6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHRpdGxlIG9m IHRoaXMgZHJhZnQgaW5kaWNhdGVzIG1pYiBmb3IgTVBMUy1UUCBPQU0gSUQgYnV0IGluIHRoZSBi b2R5IE1QTFMgaXMgdXNlZA0KIG1vc3RseSBhbmQgc29tZXRpbWVzIE1QTFMtVFAgYXBwZWFycywg Zm9yIGV4YW1wbGUsIGJvdGggTVBMUyB0dW5uZWxzIGFuZCBNUExTLVRQIHR1bm5lbHMgYXJlIG1l bnRpb25lZC4gSSdtIG5vdCBzdXJlIGlmIHRoZXkgY2FuIGJlIHVzZWQgaW50ZXJjaGFuZ2VhYmxl LiBCZXNpZGVzLCBJIG5vdGljZSB0aGF0IHRoZSBuYW1lcyBmb3IgdGhlIG9iamVjdHMgYWxsIHN0 YXJ0IHdpdGggJnF1b3Q7bXBsc29hbWlkeHh4JnF1b3Q7LCB3aGljaCBzZWVtcyB0byBhZGRyZXNz DQogbWliIGZvciBNUExTIE9BTSBJRC4gVGhlbiBpdCBpcyBub3QgYWxpZ25lZCB3aXRoIHRoZSB0 aXRsZSBvZiB0aGlzIGRyYWZ0LiBBIGJpdCBjb25mdXNlZC4gQ291bGQgdGhlIGF1dGhvcnMgcHJv dmlkZSBhbnkgY2xhcmlmaWNhdGlvbiBvbiB0aGlzPyBBIGdlbmVyYWwgc3VnZ2VzdGlvbiBpcyB0 byBtYWtlIGFsaWdubWVudCB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCwgaW5jbHVkaW5nIHRoZSB0 aXRsZSBvZiB0aGUgZHJhZnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KiBB YnN0cmFjdDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7IGl0IGRlc2Ny aWJlcyBPcGVyYXRpb25zLCBBZG1pbmlzdHJhdGlvbiwgYW5kIE1hbmFnZW1lbnQgKE9BTSkNCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZndDsgaWRlbnRpZmllcnMgcmVsYXRlZCBtYW5hZ2VkIG9iamVjdHMgZm9y IE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7IChNUExT KSBhbmQgTVBMUyBiYXNlZCBUcmFuc3BvcnQgUHJvZmlsZSAoVFApLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZmluZCB0aGlzIHNlbnRlbmNlIGhhcmQgdG8gcGFyc2UuIE1h eWJlIHMvcmVsYXRlZCBtYW5hZ2VkIG9iamVjdHMvcmVsYXRlZCB0byBtYW5hZ2VkDQogb2JqZWN0 cy8gPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiogU2VjdGlvbiAxLCBwYWdlIDM6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OyBNUExTIExTUChMYWJl bDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlJ3MgYSBtaXNzaW5nIHNw YWNlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiogU2VjdGlvbiA1LjEsIHBhZ2UgNDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mZ3Q7IFRoZSBtcGxzT2FtSWRNZWdUYWJsZSBpcyB1c2VkIHRvIG1hbmFnZSBvbmUgb3Ig bW9yZSBNYWludGVuYW5jZQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OyBFbnRpdGllcyAoTUVzKSB0aGF0 IGJlbG9uZ3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5zL2JlbG9uZ3MvYmVs b25nLzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiogU2VjdGlvbiA2LCBjb3B5JmFtcDtwYXN0ZSBtaXN0YWtlPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+LS0gU291cmNlIE1FUCBpZCBpcyBkZXJpdmVkIGZyb20gdGhlIElQ IGNvbXBhdGlibGUgTVBMUyBMU1A8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgbXBsc09hbUlkTWVTaW5rTWVwSW5kZXgmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPSAwLDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBkZXNjcmlwdGlvbiBpbiB0aGUgbm90ZSBzaG91 bGQgYmUgc2luayBNRVAuIFRoZXJlIGlzIGFscmVhZHkgYW5vdGhlciBsaW5lIHRvIGRlc2NyaWJl DQogc291cmNlIE1FUC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4qIFBhZ2UgMTU6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jmd0OyBCRkQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGlzIHRo ZSBmaXJzdCBhbmQgb25seSBpbnN0YW5jZSBvZiBCRkQuIFBsZWFzZSBleHBhbmQuIChhbmQgbWF5 YmUgcmVmZXJlbmNlIFJGQzU4ODApPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiogUGFnZSAxNzo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mcXVvdDtwMnAmcXVvdDsgYW5kICZxdW90O1AyUCZxdW90OyBmaXJzdCB1c2Vk IGhlcmUuIHNob3VsZCBwcm9iYWJseSBiZSBleHBhbmRlZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UsPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGluYTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C0E0A32284495243BDE0AC8A066631A818DC324Aszxeml557mbschi_-- From nobody Mon Sep 7 08:40:38 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEF41B56C3; Mon, 7 Sep 2015 08:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 XbyPbCw4o6Ur; Mon, 7 Sep 2015 08:40:34 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF09D1B56C0; Mon, 7 Sep 2015 08:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4214; q=dns/txt; s=iport; t=1441640433; x=1442850033; h=from:to:subject:date:message-id:mime-version; bh=SZq3YGsJvenk6vIJVtGWPoGT9zNSXnI6xDAC1BxuivU=; b=EeyyvnJCHDJHXrEZL7X8DDeNUcDUne4MlCN18JwZEYeWrHrzFhQvhNyK XIWFcge5GpaqnkiyA556HVe4PA/HDYyLFv/LyLz8iw8vSElhCWCYn7aYd 5rAZv1QDpvijB+C0cXFZA6mQaBO8RnPgZ+6Wu4+4V90Ae5iI1hvvpmMUr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BzAgCpr+1V/49dJa1dglZNVG+9XAEJh3ACgTA4FAEBAQEBAQGBCoQlAQQtXgEMHlYmAQQBGogmyRsBAQEBAQEBAQIBAQEBAQEBAQEZhnOJVoNQgRQFjTCIJQGncCaEAIg1gQUBAQE X-IronPort-AV: E=Sophos;i="5.17,485,1437436800"; d="scan'208,217";a="185718427" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 07 Sep 2015 15:40:10 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t87Fe9Jq002288 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Sep 2015 15:40:10 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Sep 2015 10:40:08 -0500 Received: from xhc-aln-x05.cisco.com (173.36.12.79) by xch-aln-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 7 Sep 2015 10:40:08 -0500 Received: from xmb-aln-x10.cisco.com ([169.254.5.237]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0248.002; Mon, 7 Sep 2015 10:40:08 -0500 From: "Shaun Cooley (shcooley)" To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-mpls-mldp-node-protection.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-mpls-mldp-node-protection-05 Thread-Index: AdDpgZmgb/Q2dRS0RiutrIl+jEviAw== Date: Mon, 7 Sep 2015 15:40:07 +0000 Message-ID: <187A7B1DA239514F9146FC78B19AADE37ECA3B4E@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.148.80.94] Content-Type: multipart/alternative; boundary="_000_187A7B1DA239514F9146FC78B19AADE37ECA3B4Exmbalnx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: [secdir] secdir review of draft-ietf-mpls-mldp-node-protection-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 15:40:36 -0000 --_000_187A7B1DA239514F9146FC78B19AADE37ECA3B4Exmbalnx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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. This document introduces a node protection mechanism for point-to-multipoin= t and multipoint-to-multipoint label switched paths that is established via= multipoint label distribution protocol (mLDP). Given that all participati= ng nodes in this scheme must be manually configured to do so, I agree with = the authors' position that this mechanism introduces no additional security= considerations beyond what is already known for the underlying protocol - = which is documented in RFC 5920 and RFC 6388. I consider this document ready for publication. -Shaun --_000_187A7B1DA239514F9146FC78B19AADE37ECA3B4Exmbalnx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

 

This document introduces a node protection mechanism= for point-to-multipoint and multipoint-to-multipoint label switched paths = that is established via multipoint label distribution protocol (mLDP). = ; Given that all participating nodes in this scheme must be manually configured to do so, I agree with the authors= ’ position that this mechanism introduces no additional security cons= iderations beyond what is already known for the underlying protocol –= which is documented in RFC 5920 and RFC 6388.

 

I consider this document ready for publication.=

 

-Shaun

--_000_187A7B1DA239514F9146FC78B19AADE37ECA3B4Exmbalnx10ciscoc_-- From nobody Tue Sep 8 11:57:33 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9001ACDC5; Tue, 8 Sep 2015 11:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=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 t1-dbwd3W4sZ; Tue, 8 Sep 2015 11:57:30 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (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 EE61B1A8A09; Tue, 8 Sep 2015 11:57:29 -0700 (PDT) Received: by obbda8 with SMTP id da8so63287693obb.1; Tue, 08 Sep 2015 11:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=2r4s/zOZZ2JN7puGKaJrBQpepWHL4dmlr080dSd7q7M=; b=B+ftABW+V9062IybS6rmnB4Fy12/lNPSjHs3ztiJR0wy52m9rpLqQeL2NITDYbdtPj zQGKVBPn1rdMM3gEm/Hc9B/EKYlbrfYYipX0A2UW3kBPrPYYKUinK7udkk6rW4zk5Wgl 7wuYdMYUM4Tn0DYH9FYWrUiPGVUMY4wJ7pIED1G7vvFIsfsu3O24tF5Od0NnIdZXl1Pa CqTp4F0kSIYGkbWXrtnLmdjsSMC6FMGOabfEpEtkMcWhNiTILzsGdHoj1NWtBrsCg+jO LezYttuD5A2pgGuSRodUHtk4dDJ2XKY+B6JRIsMYpw/LtKSuKCRg+2cgIi90jt3TGAYr BTeQ== X-Received: by 10.60.50.133 with SMTP id c5mr23535721oeo.24.1441738649193; Tue, 08 Sep 2015 11:57:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.144.65 with HTTP; Tue, 8 Sep 2015 11:57:14 -0700 (PDT) In-Reply-To: <55E36EFC.6000508@gmail.com> References: <55E36EFC.6000508@gmail.com> From: Donald Eastlake Date: Tue, 8 Sep 2015 14:57:14 -0400 Message-ID: To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-trill-channel-tunnel.all@tools.ietf.org, "trill@ietf.org" , IETF Security Directorate Subject: Re: [secdir] Early SecDir review of draft-ietf-trill-channel-tunnel-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 18:57:32 -0000 Hi Yaron, Thanks for the review. On Sun, Aug 30, 2015 at 5:00 PM, Yaron Sheffer wrote: > This is an early security review, written at the request of the > TRILL WG. > > The document defines a way to tunnel arbitrary frames of related > control protocols within the TRILL "channel". Most of the document > (and the focus of this review) is about security this tunnel. Perhaps a bit of history would be useful: TRILL primarily uses IS-IS for its control plane and, of course, whatever native link-technology specific control features are available internal to a link between TRILL switch (RBridge) ports can be used locally, but these have some limitations. So the "RBridge Channel" facility was specified in RFC 7178 to support the extensible specification of unicast or multicast, single or multi-hop typed control messages between TRILL switches and between a TRILL-aware end station and the TRILL switch to which it is attached. (One would expect most end stations to not be TRILL-aware.) The first use of the RBridge Channel facility was to support BFD over TRILL, as specified in RFC 7175. There are three things that might seem like useful additions to the RFC 7178 RBridge Channel facility: (1) Although RFC 7178 handles control messages between TRILL switches or between a TRILL-aware end station and an adjacent TRILL switch, you also might want such messages between a TRILL-aware end station and a non-adjacent TRILL switch or between two TRILL-aware end stations not on the same link. (2) Although RFC 7178 provides for an extensible type for control messages, there may be cases where there is already an Ethertype defined so it would be convenient to have an RBridge Channel message type that says that its payload starts with an Ethertype or, in some cases, a destination MAC address, a source MAC address, and an Ethertype, where that Ethertype tells you what the further payload is. (3) RFC 7178 does not provide for security, something that was noted by the Security Area at the time it went through the IESG but was not considered blocking, perhaps partly because the first application for RBridge Channel was for to carry BFD that has its own security. Early versions of this draft covered all three of these points and had a bunch of somewhat complex material addressing point 1 and less material than the current version addressing point 3. However, there did not seem to be an immediate requirement to address point 1 so, to slim down the draft, that was removed while the amount of material addressing point 3 has grown. > Summary > > I believe the draft is not ready for IETF LC in its current form. I > assume the original intention was to use DTLS, but the use of DTLS > is not well specified and the alternative that's proposed for > multicast comes with inferior security. After studying your review and thinking about it, I agree that the draft is not ready. DTLS is actually a very recent addition to the draft. In early versions, the security provided in the Channel Tunnel draft was very much like IS-IS authentication. The option of using DTLS was added quite recently to provide an option with better key negotiation / management. Although I'm not sure, in this context where the TRILL switches are pretty much trusted entities, that this is much needed. If, for example, a link between TRILL switch ports traverses an insecure environment, then it seems to me that the best answer is link encryption based on the link technology (which is what the TRILL over IP draft is intended to specify for IP links and what the draft-eastlake-trill-link-security early partial draft is intended to specify for other link technologies used between TRILL switch ports). Link security would protect both the TRILL IS-IS control traffic as well as TRILL Data packets (which includes RBridge Channel packets since they are encoded as if they were TRILL Data packets) and sometimes also protects some link-local link technology specific control packets. Channel Tunnel security protects only Channel Tunnel messages although, if they are multi-hop, it can protect them to some extent against intervening TRILL switches. > Details > > =E2=80=A2 In general, I don't understand why it makes sense to define a w= hole new > security protocol, just for control-plane traffic of one specific protoco= l, > important as it may be. At the very least I would expect an analysis of > potential alternatives (IPsec? MACsec?) and why they do not fit this use > case. It seems important to at least be able to provide the same level of authentication as the primary IS-IS control plane. And IPsec, DTLS, and MACsec seems like the big three bell and whistle equipped datagram security schemes, one of which should be optionally available. There is a significant gap between these two levels of security. See the end of this response for my further thoughts on this high level question... (Note that currently the TRILL protocol does not require a TRILL switch to have an IP address or a MAC address associated with it although there would be various ways to overcome this if desired.) > =E2=80=A2 As a result of the home-brew transport protocol, we also don't = get > a standard key management protocol. I'm not completely sure what you are referring to but the "home-brew transport protocol" of RBridge Channel [RFC 7178] is currently implemented and deployed and in use for BFD and, I believe, further control plane messages that have not yet been standardized. > =E2=80=A2 And from a process POV, the TRILL WG may not be the best place,= as > far as participants' expertise, to develop a security protocol. An > early SecDir review certainly helps, but I'm not sure the current > reviewer is capable of detecting every last issue that might be > lurking in the protocol. Well, there are things for which I would say TRILL WG is clearly inappropriate, like designing cryptographic primitives, and things where I think the TRILL WG is appropriate, such as determining, when security is provided, what parts of an RBridge Channel packet of other TRILL PDU should be authenticated and/or encrypted and what parts need to be unauthentication or in plain text because they are mutable or needed by transit devices. > =E2=80=A2 4.1: the A and E bits are not guaranteed to be correct? Then wh= y > are they here? They describe critical security properties, and > therefore someone is bound to use them to make critical policy > decisions. If the bits' semantics are not guaranteed, we'd better > drop them. The E bit was intended to be useful as a hint to diagnostics/debugging software that a payload is encrypted so trying to parse it without keys is not going to get you very far. But I think the bits could be removed. > =E2=80=A2 A bit: I think we are confusing authentication with integrity > protection. With opportunistic security, you usually don't have > authentication, but integrity protection is still worthwhile. Although opportunistic security is mentioned I don't think there is any specification of how to do it in this draft. Do you believe that the Authentication TLV in IS-IS should be renamed the Integrity TLV? > =E2=80=A2 4.2: Coverage - it would be nice if Fig. 2.1 showed the coverag= e > of authentication (integrity protection!) and encryption. Why is an > Ethernet frame's FCS not covered by integrity protection? Is there > any non-malicious reason someone would want to modify the FCS in > transit? Some graphic representation of the coverages, rather than just text, seems like a good idea. I'm not completely certain that Figure 2.1 is the best place -- perhaps there should be a new figure. On coverage of Ethernet FCS: the only case where you can be sure there is an invariant Ethernet FCS between TRILL switch ports would be a single hop RBridge Channel message over Ethernet (TRILL over Ethernet is specified in RFC 6325) between adjacent TRILL switch ports where there are no intervening bridges. Bridged LANs are pretty much transparent to TRILL and, if there are any intervening bridges between TRILL switch ports, those bridges can change the FCS due to inserting/removing various tags etc. RBridge Channel messages can be multihop (multiple TRILL hops) and even if all the hops were point-to-point Ethernet, the Ethernet FCS could change at every TRILL switch along the path due to the presence/absence of tags. The optional outer VLAN tag in TRILL over Ethernet has no relationship to the actual Data Label of the payload but just gives some VLAN ID that is convenient to use to get the TRILL data packet from one TRILL switch to the next TRILL switch in the path. > =E2=80=A2 4.3: "in some cases" - why not simply say, "When SType is 1 or = 3"? Because there might be additional STypes specified that can also use this. But I guess it doesn't matter much since such specification could amend the provisions here. > =E2=80=A2 4.3: why deconstruct HKDF and use HKDF-Expand instead of simply > using the whole thing, including HKDF-Extract? Because the draft follows the advice in RFC 5869 that specifies HKDF: In some applications, the input may already be a good pseudorandom key; in these cases, the "extract" stage is not necessary, and the "expand" part can be used alone. The Channel Tunnel draft assumes that an IS-IS key will be a good key. Explicitly noting that assumption would be a good idea. > =E2=80=A2 I am confused about 4.1 vs. 4.5, and specifically, what does th= e > Size byte cover. I think this is incorrect in 4.5. Maybe I am missing something but they look compatible with me. Section 4.1 is more general, and says that when security information is present it consists of a byte of flags followed by a byte of size information followed by zero to 255 bytes of "More Info". Section 4.5 is more specific and says that for a particular SType, this "More Info" consists of the two byte RFC 5310 Key ID followed by a variable amount of "Authentication Data". > =E2=80=A2 4.6: this section starts with certificates (presumably, both > client and server should authenticate with a cert) and then moves on > to PSK. Are both allowed? If DTLS is supported, then PSK MUST be supported and certificates SHOULD be supported. The wording could be improved to make this clearer if this sort of material stays in this draft. > =E2=80=A2 4.6: TLS is rapidly moving toward perfect-forward secrecy. Why > require a cipher suite that's being deprecated across all of > industry (TLS_RSA_WITH_AES_128_CBC_SHA256)? A mandatory to implement algorithm seemed useful for interoperability if this sort of material remains in this draft but it could be indirectly specified by a reference to another document. > =E2=80=A2 4.6.: I am still unclear on how CT keys are derived from DTLS. > =E2=80=A2 4.6: Why have a TRILL-level key ID with DTLS-PSK has the notion= of > key ID? > =E2=80=A2 4.6: with certificates the frames may be very large. Does the p= rotocol > support such sizes? > =E2=80=A2 4.6: there should be a lot more text about how DTLS is used to = wrap L2 > frames. I tend to agree that there are problems here. Rather than responding on each point above see the end of this note where I propose removing the DTLS material entirely. > =E2=80=A2 4.7: if this mode is assumed for multicast, what is the > assumed/recommended mode for unicast? It depends on what services you want. > =E2=80=A2 Obviously integrity protection where the MAC key is shared with= all peers > is very weak. There are various ways to deal with that, starting with RSA > signatures but including more efficient methods (TESLA comes to mind). Ha= ve > you considered any of them? > =E2=80=A2 4.7.1: if the authentication data is variable length, you must = ensure that > the field that indicates its size is integrity-protected as well. OK. > =E2=80=A2 Actually, I'm not sure where this size is indicated. > =E2=80=A2 It seems to me that a fully random 128-bit nonce would be both > simpler to implement and more secure than the scheme proposed here. Possibly but the generation of good random number can also be considered a burden. > =E2=80=A2 Typo: designed -> designated. Thanks. > =E2=80=A2 5: assuming we will have DTLS handshakes nested within CT, how = are > errors indicated? See note at end of this message. > =E2=80=A2 General: is there any facility for replay protection? If no, wh= y > not? Not in general. There should be. > =E2=80=A2 7: The more normative parts of the Security Considerations woul= d > probably fit nicely into a separate Applicability section. > =E2=80=A2 7: I think the document should be much more clear (normative) > about what message types are allowed within the tunnel, or not. And > possibly about required filtering by address. I disagree. The whole idea is to be a general, extensible messaging facility. I don't think it is possible to anticipate in advance what people might want to use it for and the precise tests they should make. I'm not sure how much more can generally and validly be said other than to be conservative in what you accept. Overall Note ------------ Based on this review and further consideration, I think the attempt in this draft to convolve DTLS with the Channel Tunnel feature, while not inherently impossible, is pretty much a failure and not the best approach. When stronger security, encryption, key negotiation, and the like are desired, a general payload-independent feature running between RBridges that envelopes TRILL Data packets should be used. This could be used to protect RBridge Channel messages since they are encoded a TRILL Data packets and could be specified in a separate document to which this draft could refer. The security in this draft should be simplified to providing authentication and replay protection. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Tue Sep 8 12:09:12 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C487F1B37D3 for ; Tue, 8 Sep 2015 12:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 asQ_YG-5UHQ0 for ; Tue, 8 Sep 2015 12:09:07 -0700 (PDT) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [146.101.78.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9C01A03B3 for ; Tue, 8 Sep 2015 12:09:07 -0700 (PDT) Received: from emea-cam-gw1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-3-NxIXUxaETJGcflKAt8KzWg-1; Tue, 08 Sep 2015 20:09:04 +0100 Received: from EMEA-CAM-GW3.Emea.Arm.com (10.1.106.86) by emea-cam-gw1.Emea.Arm.com (10.1.248.203) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 8 Sep 2015 20:09:04 +0100 Received: from george.Emea.Arm.com ([fe80::4c19:a8f:5c9a:76df]) by EMEA-CAM-GW3.Emea.Arm.com ([::1]) with mapi; Tue, 8 Sep 2015 20:09:04 +0100 From: Hannes Tschofenig To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-grow-bmp.all@tools.ietf.org" Date: Tue, 8 Sep 2015 20:09:03 +0100 Thread-Topic: secdir review of draft-ietf-grow-bmp-15 Thread-Index: AdDqUD9qseDkdNQRSWGnERO0j8rnww== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 X-MC-Unique: NxIXUxaETJGcflKAt8KzWg-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [secdir] secdir review of draft-ietf-grow-bmp-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 19:09:09 -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. I am not an expert in this field and cannot judge whether the designed prot= ocol makes sense. The content did, however, look complete to me. The security consideration section talks about different security threats a= nd focused on confidentiality protection quite a bit (but dismisses it in = the end). I would think that authentication and integrity are probably more= important in this context. I suspect that a monitoring station will react = on information it receives (somehow) and false information could potentiall= y be a problem. How likely is it that an attacker injects false information= that will then the processed by a monitoring station (which could be locat= ed anywhere)? Currently, it appears that no specific security solution is mandatory to im= plement. There are only examples listed, such as IPsec and TCP-AO. (For IPs= ec I guess you would also use IKEv2 as a key management?) Would it be usefu= l to have one security mechanism mandatory to implement? The sentence "Implementations of this protocol SHOULD require manual config= uration of the monitored and monitoring devices." feels a bit out of contex= t in the security consideration section. I would delete it from the securit= y consideration section or, alternatively, what it implies in terms of secu= rity. The term 'transport' for a security protocol appears incorrect. For example= , instead of writing "... users of this protocol should consider using some= type of transport that provides mutual authentication, data integrity, and= transport protection, ... " you could write "... users of this protocol sh= ould consider using a security protocol that provides mutual authentication= , data integrity, and confidentiality protection, ... ". -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From nobody Tue Sep 8 12:15:47 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7F81B5284; Tue, 8 Sep 2015 12:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Ta0r6igWPC6b; Tue, 8 Sep 2015 12:15:41 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C0D1B524C; Tue, 8 Sep 2015 12:15:41 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3n9bmB5syhz3LN; Tue, 8 Sep 2015 21:15:38 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=okQjnemV X-OPENPGPKEY: Message passed unmodified 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 zChG80eEfa5c; Tue, 8 Sep 2015 21:15:36 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 8 Sep 2015 21:15:36 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 00D338009F; Tue, 8 Sep 2015 15:15:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1441739736; bh=48R2AFkl2NF0IHTK1FvdbN43W4RpqDWCNyHWDl5RPgU=; h=Date:From:To:Subject; b=okQjnemV5hNCehnHxEUTS5/l42oXKPjOegh8fLe68Z+I+haO8KPaqLey6NLhr/jnf IHVFpKIOhNat25Fhd/JhIVV4GOMrMIBncBQELgX7MXB129Yf1YdfSDErK2axgBwaN6 rD4S5YYC34XAgJsDEi/LyHjEtyAecHvPkRX1mmsk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t88JFZrA030461; Tue, 8 Sep 2015 15:15:35 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 8 Sep 2015 15:15:35 -0400 (EDT) From: Paul Wouters To: secdir , iesg@ietf.org, draft-ietf-ccamp-flexigrid-lambda-label.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [secdir] secdir review of draft-ietf-ccamp-flexigrid-lambda-label X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 19:15:45 -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 draft is Ready with nits This document defines a new Flexi-Grid value for Lambda Switch Capable (LSC) Label Switching Routers. The specification of this new label references an external (ITU) specification. The security considerations of this document properly refers to other documents, such as RFC3471, RFC3473 and RFC5920. No new security issues are introduced in this document, as it merely defines a new label to use which causes no backwards compatibility issues. nits: -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) Paul From nobody Tue Sep 8 15:01:10 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B791B3313 for ; Tue, 8 Sep 2015 15:01:08 -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=unavailable 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 a-IHhI6QxUXz for ; Tue, 8 Sep 2015 15:01:06 -0700 (PDT) Received: from nm9-vm2.access.bullet.mail.gq1.yahoo.com (nm9-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.37]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4971B3327 for ; Tue, 8 Sep 2015 15:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441749664; bh=GV96YdB47kC3I2jgW3BRIL27nNTRbFv1HBBGxD9A56g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From:Subject; b=GaXuGzoujC7pc/pEa3e4OClHtPCm2nFA9HvWCaaMnngD9VgeukhOn5vA6x9InTojBEI1UCnlo5YiPpKct9691P7whYnjmOCXGM+hVwreD+dT9F8Tj/YYBYML3OCq1qk4XOPQQux/KVj/0BiPYUJy5D54N+77Cx2HIrAolta/rSmqhrG512XdlkSxRSYGc7g0WUCEAKa50ltLAKwgvm/eAJxzJCwpEc69vSnvewwoiXa5SefmN5IkMI69H/5KzWhxncQQ2MRIeMcnrhAdAo+pUS5EMy3EBAD97haUJjqYIrdLtkIHYWsSouyYLNKOAbiVjawP/s1A9jLDYNsg4Brlig== Received: from [216.39.60.175] by nm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 08 Sep 2015 22:01:04 -0000 Received: from [98.138.226.244] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 08 Sep 2015 22:01:04 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 08 Sep 2015 22:01:04 -0000 X-Yahoo-Newman-Id: 358563.59748.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: KRlcfQ0VM1mADaPypu2T5xkOqmaNdFnh7FohrAz7SMgdTld saYkQE..rdd.25aMOYfS6L8bl0wuNz677tc81mSHA6pnEtpBqtgC.aH2OQSt fiWGhVXaS3elOG8abWNoWUqNzOg3jAfsa39As6ZS9Ioa6IolPcv4HGKL5bPO jASi8dk9rOzz_yiZKaVk9Pd.4NsP3Iy408VUBoMK3HL_3180a8G7jlUdCDxI ZqVO5zC.lbcsIFg3KQhKOkylfJoyfrC_xdy5Ila8TF6m2GNyeFo_vFEGK2og 8_JxrBHUbd3OWXJj3yi7LVwsu.24Drh7Vqgg671AbttEvoB9U5K8dJI4terM O5wSOYob9Zq0opLlDkorkWHOqByutQFY4iWPhEn_gTtAAIqvd830yVJ9fym0 Kk8crgliMDnhC.NoltNuAaiADfIoUXJU1LkcJ58GeqfqTHZ3Lr5QDZ7Jsz.O jmeJMFQCW0n.P.z0YfJGnAC2JG6dwAimZt4giHg.rA1gLri0ISX_b9LdoZ5k 6Soy1IhwCRUyOufJLB88ik9w2kCzub.G5nZ2.kA-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id E19FB1C6095; Tue, 8 Sep 2015 18:01:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 08 Sep 2015 18:01:01 -0400 From: David Mandelberg To: Magnus Westerlund In-Reply-To: <55E7158D.5060304@ericsson.com> References: <063cc84fb1eb8fbef30eda11ea7d8199@mail.mandelberg.org> <55E7158D.5060304@ericsson.com> Message-ID: <5500272170d19009fe7d7e58ffaebd50@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Cc: draft-ietf-avtext-rtp-stream-pause.all@tools.ietf.org, avtext@ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-avtext-rtp-stream-pause-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 22:01:08 -0000 On 2015-09-02 11:28, Magnus Westerlund wrote: > Den 2015-08-11 kl. 06:45, skrev David Mandelberg: >> 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. >> >> I think this draft is Ready with issues, though the two issues are >> relatively minor: >> >> 1. The Security Considerations section talks about protecting >> against >> injection of PAUSE requests: >> >> The way of protecting the RTP session from these injections is >> to >> perform source authentication combined with message integrity, >> to >> prevent other than intended session participants from sending >> these >> messages. >> >> I think this paragraph should also mention replay protection, which >> is >> needed if the 16-bit PauseID wraps around and the attacker has >> access to >> old PAUSE requests. > > Yes, we should mention replay attacks. I note that due to that the > current PauseID starts at 0 and increments by one, it takes some time > until we wrap. And also then you might have to hold onto a lot of > messages to be able to attempt a replay. But, clearly we should > recommend replay protection at the outer security layer. > > I propose that we add the following sentence in the second paragraph > prior to the last sentence: > > The security solution should provide replay protection, otherwise an > attacker could for sessions that are long lived enough to wrap the > PauseID replay old messages at the appropriate time to influence the > media sender state. Looks good to me. >> 2. The next paragraph in Security Considerations talks about >> protecting >> the multi-party use case against a single malicious participant by >> individually authenticating participants. In addition to >> per-participant >> authentication, I think there also needs to be a requirement for >> attempted delivery of PAUSE requests to all participants. Without >> that >> requirement, an attacker could cause the session to cycle through >> the >> Playing, Pausing, and Paused states. To do that, the attacker would >> send >> PAUSE requests only to the stream sender, instead of to the whole >> group. >> Since no other participants receive the PAUSE request, they do not >> know >> to send disapproving RESUMEs until after the stream sender has >> already >> paused the stream. (I should note that I'm not particularly familiar >> with multicast network operations. If it's infeasible for one >> participant to send a message to another participant without the >> rest of >> the group also receiving the message, then I apologize for bringing >> up a >> non-issue.) > > Yes, you are correct that getting a malicious PAUSE message sent to > multiple participants provides a mitigation in that the other > participants can counter it. That I would expect to happen in > multicast cases where anyone can send RTCP messages. It will fully > depend on the multicast topology if an on-path attacker has any > chance > of getting its messages delivered to the media stream endpoint and > not > getting forwarded to other endpoints over the multicast tree. > > In the cases of the RTP middleboxes providing the multi-party > functionality it will depend on the mode of operation of that > middlebox. But, assuming the middlebox isn't compromised it will act > on behalf of the whole session. It either works as multicast emulator > and should forward it to everyone, or it will receive the request, > and > only forward it if fits the rest of the session state. > > Proposed text for the end of Paragraph three: > > An attacker that can send a PAUSE request without it reaching any > other participant than the media sender can have its request being > unopposed. This is mitigated in multi-party topologies that ensure > that requests are seen by all or most of the RTP session > participants, > enabling these participants to send RESUME. In topologies with > middleboxes that consume and process PAUSE requests, the middlebox > can > also mitigate such behavior as it will commonly not generate or > forward a PAUSE message if it knows of another participant having use > for the media stream. > > Comments on this? This also looks good to me. Thanks for addressing my concerns! -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Wed Sep 9 03:12:49 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0271D1B3524; Wed, 9 Sep 2015 03:12:46 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 xKCS5Dl69PpJ; Wed, 9 Sep 2015 03:12:45 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915751B3140; Wed, 9 Sep 2015 03:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2534; q=dns/txt; s=iport; t=1441793565; x=1443003165; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fMTb3QHSOa5lrHxDJWkCo0vZHloxGpRYsTqzOD2sis8=; b=DVJ4O8+wfAKdb/ZyZND+/PnQxcgnb+tICScrKfEJZmbnlC/VhfN/evEH UcxyC0/4JicV//kuwXZjtr1bkN5reLOoHrew56BEPirvI9aSWWIVbtg1Z V4Uo1kLGsA054A2m9c5tlx+8RxUxEQ23z/Clo0/79/9q3uY2pfPJWsCLb s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BAAgB9BfBV/5tdJa1UCYMjgUODHroAAQmIDoESOBQBAQEBAQEBgQqEKiMRNyABIgImAgQwFRIEAS2IE7V7lD4BAQEBAQEBAwEBAQEBHYEihVGCD4JshDCDTC+BFAWVVgGMeZp4JoIPHYFUiDWBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,496,1437436800"; d="scan'208";a="186103387" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 09 Sep 2015 10:12:44 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t89ACiUn018351 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Sep 2015 10:12:44 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Sep 2015 05:12:44 -0500 Received: from xhc-aln-x06.cisco.com (173.36.12.80) by xch-rcd-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 9 Sep 2015 05:12:43 -0500 Received: from xmb-aln-x12.cisco.com ([169.254.7.226]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0248.002; Wed, 9 Sep 2015 05:12:43 -0500 From: "Klaas Wierenga (kwiereng)" To: "draft-ietf-6man-predictable-fragment-id.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: review of draft-ietf-6man-predictable-fragment-id-09 Thread-Index: AQHQ6ugR5xYesIJ6aku2acWq+4+kPA== Date: Wed, 9 Sep 2015 10:12:43 +0000 Message-ID: <4F5FD3E9-B5A3-4AAB-A089-61B674B59ECC@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.101.220.141] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [secdir] review of draft-ietf-6man-predictable-fragment-id-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 10:12:47 -0000 SGksDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRlJ3MgDQpvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9j dW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgDQpJRVNHLiAgVGhlc2UgY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIA0Kc2VjdXJpdHkgYXJl YSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0 IA0KdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMu DQoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZiBwcmVk aWN0YWJsZSB2YWx1ZXMgZm9yIHRoZSBpZGVudGlmaWNhdGlvbiBmaWVsZCBpbiBmcmFnbWVudCBo ZWFkZXJzIGZvciBJUHY2Lg0KDQpJIGJlbGlldmUgdGhlIGRvY3VtZW50IGhhcyBzb21lIGlzc3Vl cywgc2VlIGJlbG93Lg0KDQpUaGUgZG9jdW1lbnQgZG9lcyBhbiBhbmFseXNpcyBvZiB0aGUgc2Vj dXJpdHkgaW1wbGljYXRpb25zIG9mIHByZWRpY3RhYmxlIGlkZW50aWZpY2F0aW9uIGZpZWxkcyBh bmQgSSBiZWxpZXZlIChub3QgYmVpbmcgYW4gSVB2NiBleHBlcnQpIHRoYXQgaXQgZG9lcyBhIGdv b2Qgam9iIGF0IHRoYXQuIFRoZSBhbmFseXNpcyBvZiB0aGUgcG90ZW50aWFsIGV4cGxvaXRzIGlz IGNvbnZpbmNpbmcuDQpXaGVyZSBJIGFtIHN0cnVnZ2xpbmcgYSBiaXQgaXMgdGhlIGFsZ29yaXRo bXMgZm9yIHNlbGVjdGluZyBmcmFnbWVudCBpZGVudGlmaWNhdGlvbiB2YWx1ZXMgKDUpLg0KDQpU aGUgaW50cm8gdGV4dCBzdGF0ZXMgdGhhdCB0aGVyZSBhcmUg4oCYYSBudW1iZXIgb2YgYWxnb3Jp dGhtcycsIGJ1dCByZWFsbHkgdGhlcmUgYXJlIG9ubHkgMzoNCjEtIHBlciBkZXN0aW5hdGlvbiBj b3VudGVyIHJhbmRvbSBpbml0aWFsaXNlZA0KMi0gcmFuZG9tIHZhbHVlDQozLSBoYXNoIG92ZXIg c291cmNlLCBkZXN0aW5hdGlvbiwgc2VjcmV0IHdpdGggYSBjb3VudGVyDQoNCjEgYW5kIDMgYXJl IGVzc2VudGlhbGx5IHRoZSBzYW1lLCB0aGUgaGFzaCBmdW5jdGlvbiBpbiAzIHBlcmZvcm1zIHRo ZSBzYW1lIGZ1bmN0aW9uIGFzIHRoZSBwc2V1ZG8gcmFuZG9tIGdlbmVyYXRlZCBpbml0aWFsIHZh bHVlIGluIDEgaWYgSSBhbSBub3QgbWlzdGFrZW4uDQpTbyByZWFsbHkgdGhlIGNob2ljZSBpcyBi ZXR3ZWVuIGEgcmFuZG9tIHZhbHVlIGZvciBldmVyeSBkYXRhZ3JhbSBvciBhIHJhbmRvbSB2YWx1 ZSBhdCBpbml0aWFsaXNhdGlvbiBvZiBhIGNvbm5lY3Rpb24gYW5kIGluY3JlYXNpbmcgYnkgMSBm b3IgZXZlcnkgc3Vic2VxdWVudCBkYXRhZ3JhbS4NCg0KSeKAmWQgcmVhbGx5IGxpa2UgdG8gc2Vl IHNvbWUgcXVhbnRpdGF0aXZlIGFuYWx5c2lzIGFzIHRvIHRoZSBpbXBhY3Qgb2YgYSByYW5kb20g dmFsdWUgcGVyIHBhY2tldCBhcyB3ZWxsIGFzIGJldHdlZW4gMSBhbmQgMy4gTm93LCBhcyBhbiBp bXBsZW1lbnRlciBJIHdpbGwga25vdyBhYm91dCB0aGUgdnVsbmVyYWJpbGl0eSBidXQgY2FuIG5v dCByZWFsbHkgZGV0ZXJtaW5lIHdoYXQgbWVkaWF0aW9uIHJvdXRlIHRvIGZvbGxvdy4NCg0KU28g dG8gc3VtIHVwLCBJIHJlYWxseSBsaWtlZCB0aGUgYW5hbHlzaXMgcGFydCwgYnV0IEkgd291bGQg cHJlZmVyIHNvbWUgd29yayBvbiB0aGUgc29sdXRpb24gdG8gdGhlIHByb2JsZW0gcGFydC4NCg0K S2xhYXMNCg0KLS0NCktsYWFzIFdpZXJlbmdhDQpJZGVudGl0eSBBcmNoaXRlY3QNCkNpc2NvIENs b3VkIFNlcnZpY2VzDQoNCg0KDQoNCg0KDQo= From nobody Wed Sep 9 04:37:32 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8B71A003A; Wed, 9 Sep 2015 04:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 oYJrplACWWrp; Wed, 9 Sep 2015 04:37:30 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (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 722AF1A00BB; Wed, 9 Sep 2015 04:37:30 -0700 (PDT) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZZdfk-0001nf-Ek; Wed, 09 Sep 2015 13:36:16 +0200 To: "Klaas Wierenga (kwiereng)" , "draft-ietf-6man-predictable-fragment-id.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" References: <4F5FD3E9-B5A3-4AAB-A089-61B674B59ECC@cisco.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <55F010E9.2060606@si6networks.com> Date: Wed, 9 Sep 2015 07:58:49 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <4F5FD3E9-B5A3-4AAB-A089-61B674B59ECC@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] review of draft-ietf-6man-predictable-fragment-id-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 11:37:32 -0000 Hi, Klaas, Thanks so much for your feedback! -- Please find my responses in-line... On 09/09/2015 07:12 AM, Klaas Wierenga (kwiereng) wrote: > I believe the document has some issues, see below. > > The document does an analysis of the security implications of > predictable identification fields and I believe (not being an IPv6 > expert) that it does a good job at that. The analysis of the > potential exploits is convincing. Where I am struggling a bit is the > algorithms for selecting fragment identification values (5). > > The intro text states that there are ‘a number of algorithms', but > really there are only 3: 1- per destination counter random > initialised 2- random value 3- hash over source, destination, secret > with a counter FWIW, these are three concrete algorithms, but that doesn't mean they are the only possible ones... > 1 and 3 are essentially the same, the hash function in 3 performs the > same function as the pseudo random generated initial value in 1 if I > am not mistaken. Yes and no. 1 requires state, but 3 doesn't. That means that, e.g., if you have lot's of flows to many different destinations, you may need to remove some entries from the Dest Cache (and then you run the risk of Frag ID collisions). However, this is not the case with algorithm #3. > So really the choice is between a random value for > every datagram or a random value at initialisation of a connection > and increasing by 1 for every subsequent datagram. > > I’d really like to see some quantitative analysis as to the impact of > a random value per packet as well as between 1 and 3. Impact in terms of what? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Sep 9 05:02:48 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDBA1B375B; Wed, 9 Sep 2015 05:02:43 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 8_HnkOfoCg43; Wed, 9 Sep 2015 05:02:42 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556041A8924; Wed, 9 Sep 2015 05:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4208; q=dns/txt; s=iport; t=1441800162; x=1443009762; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IaX2+5yf3y6x6YAN4X4ixbEpB0zm9SfQPKZJMca/RRU=; b=ht6LGRO6ssLiOCFTB365plF6o/FWwFecwNXyqa27WYrm+/Z8+Wus8Hp7 uzCiHfGvZXYOL9IiD+Pno03NKZ3QH2OMiH9sLYDflloXs9oYKG7uTyrDu xWdNFGE53TT40kh/hccvGSFTBCsWw6STg44yp4wxOtMOACXsYTMy8OzY1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8AgBIH/BV/4wNJK1dgyOBPQaDHroAAQmHcAIcgRo4FAEBAQEBAQGBCoQjAQEBAwEjETcOBQsCAQgOCgICJgICAjAVEAIEDgWIJgi1XZQ9AQEBAQEBAQEBAQEBAQEBAQEBARmBIoVRgg+BZ4EFhFkYGweCaS+BFAWVVgGMeYFMhDODH41ug2wmgg8dgVRxh0SBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,496,1437436800"; d="scan'208";a="25526276" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP; 09 Sep 2015 12:02:40 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t89C2dNT028494 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Sep 2015 12:02:39 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Sep 2015 07:02:38 -0500 Received: from xhc-aln-x12.cisco.com (173.36.12.86) by xch-rcd-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 9 Sep 2015 07:02:38 -0500 Received: from xmb-aln-x12.cisco.com ([169.254.7.226]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0248.002; Wed, 9 Sep 2015 07:02:38 -0500 From: "Klaas Wierenga (kwiereng)" To: Fernando Gont Thread-Topic: review of draft-ietf-6man-predictable-fragment-id-09 Thread-Index: AQHQ6ugR9MLjo76fAkCOSBalQ1WSJJ40WwSAgAAR0YA= Date: Wed, 9 Sep 2015 12:02:37 +0000 Message-ID: <9566C08E-D9B5-4C34-888D-F8D77335B5E3@cisco.com> References: <4F5FD3E9-B5A3-4AAB-A089-61B674B59ECC@cisco.com> <55F010E9.2060606@si6networks.com> In-Reply-To: <55F010E9.2060606@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.101.220.141] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-6man-predictable-fragment-id.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-ietf-6man-predictable-fragment-id-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 12:02:43 -0000 SG9sYSBGZXJuYW5kbywNCg0KPiBUaGFua3Mgc28gbXVjaCBmb3IgeW91ciBmZWVkYmFjayEgLS0g UGxlYXNlIGZpbmQgbXkgcmVzcG9uc2VzIGluLWxpbmUuLi4NCj4gDQo+IE9uIDA5LzA5LzIwMTUg MDc6MTIgQU0sIEtsYWFzIFdpZXJlbmdhIChrd2llcmVuZykgd3JvdGU6DQo+PiBJIGJlbGlldmUg dGhlIGRvY3VtZW50IGhhcyBzb21lIGlzc3Vlcywgc2VlIGJlbG93Lg0KPj4gDQo+PiBUaGUgZG9j dW1lbnQgZG9lcyBhbiBhbmFseXNpcyBvZiB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zIG9mDQo+ PiBwcmVkaWN0YWJsZSBpZGVudGlmaWNhdGlvbiBmaWVsZHMgYW5kIEkgYmVsaWV2ZSAobm90IGJl aW5nIGFuIElQdjYNCj4+IGV4cGVydCkgdGhhdCBpdCBkb2VzIGEgZ29vZCBqb2IgYXQgdGhhdC4g VGhlIGFuYWx5c2lzIG9mIHRoZQ0KPj4gcG90ZW50aWFsIGV4cGxvaXRzIGlzIGNvbnZpbmNpbmcu IFdoZXJlIEkgYW0gc3RydWdnbGluZyBhIGJpdCBpcyB0aGUNCj4+IGFsZ29yaXRobXMgZm9yIHNl bGVjdGluZyBmcmFnbWVudCBpZGVudGlmaWNhdGlvbiB2YWx1ZXMgKDUpLg0KPj4gDQo+PiBUaGUg aW50cm8gdGV4dCBzdGF0ZXMgdGhhdCB0aGVyZSBhcmUg4oCYYSBudW1iZXIgb2YgYWxnb3JpdGht cycsIGJ1dA0KPj4gcmVhbGx5IHRoZXJlIGFyZSBvbmx5IDM6IDEtIHBlciBkZXN0aW5hdGlvbiBj b3VudGVyIHJhbmRvbQ0KPj4gaW5pdGlhbGlzZWQgMi0gcmFuZG9tIHZhbHVlIDMtIGhhc2ggb3Zl ciBzb3VyY2UsIGRlc3RpbmF0aW9uLCBzZWNyZXQNCj4+IHdpdGggYSBjb3VudGVyDQo+IA0KPiBG V0lXLCB0aGVzZSBhcmUgdGhyZWUgY29uY3JldGUgYWxnb3JpdGhtcywgYnV0IHRoYXQgZG9lc24n dCBtZWFuIHRoZXkNCj4gYXJlIHRoZSBvbmx5IHBvc3NpYmxlIG9uZXPigKYNCg0KU3VyZSwgSSB1 bmRlcnN0YW5kIHRoYXQuIEl0IGlzIGp1c3Qgd2hlbiBJIHJlYWQgaXQgSSB3YXMgcHJlcGFyaW5n IGZvciBhIGxvbmcgbGlzdCB0byBjb21lLCBzbyBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8g c3RhdGUgc29tZXRoaW5nIGxpa2U6DQoNCk9MRA0KDQpUaGlzIHNlY3Rpb24gc3BlY2lmaWVzIGEg bnVtYmVyIG9mIGFsZ29yaXRobXMgdGhhdCBtYXkgYmUgdXNlZCBmb3INCiAgIHNlbGVjdGluZyBG cmFnbWVudCBJZGVudGlmaWNhdGlvbiB2YWx1ZXMuDQoNCk5FVw0KDQpUaGVyZSBhcmUgYSBudW1i ZXIgb2YgYWxnb3JpdGhtcyB0aGF0IG1heSBiZSB1c2VkIGZvciBzZWxlY3RpbmcgRnJhZ21lbnQg SWRlbnRpZmljYXRpb24gdmFsdWVzLiBUaGlzIHNlY3Rpb24gcHJlc2VudHMgdGhyZWUgb2YgdGhv c2UuDQoNCi0tDQoNCj4gDQo+IA0KPiANCj4+IDEgYW5kIDMgYXJlIGVzc2VudGlhbGx5IHRoZSBz YW1lLCB0aGUgaGFzaCBmdW5jdGlvbiBpbiAzIHBlcmZvcm1zIHRoZQ0KPj4gc2FtZSBmdW5jdGlv biBhcyB0aGUgcHNldWRvIHJhbmRvbSBnZW5lcmF0ZWQgaW5pdGlhbCB2YWx1ZSBpbiAxIGlmIEkN Cj4+IGFtIG5vdCBtaXN0YWtlbi4NCj4gDQo+IFllcyBhbmQgbm8uIDEgcmVxdWlyZXMgc3RhdGUs IGJ1dCAzIGRvZXNuJ3QuIFRoYXQgbWVhbnMgdGhhdCwgZS5nLiwgaWYNCj4geW91IGhhdmUgbG90 J3Mgb2YgZmxvd3MgdG8gbWFueSBkaWZmZXJlbnQgZGVzdGluYXRpb25zLCB5b3UgbWF5IG5lZWQg dG8NCj4gcmVtb3ZlIHNvbWUgZW50cmllcyBmcm9tIHRoZSBEZXN0IENhY2hlIChhbmQgdGhlbiB5 b3UgcnVuIHRoZSByaXNrIG9mDQo+IEZyYWcgSUQgY29sbGlzaW9ucykuIEhvd2V2ZXIsIHRoaXMg aXMgbm90IHRoZSBjYXNlIHdpdGggYWxnb3JpdGhtICMzLg0KDQpnb29kIHBvaW50LCBzbyBpcyB0 aGVyZSBhbnkgY29tcGVsbGluZyByZWFzb24gdG8gc2VsZWN0IDEgb3ZlciAzPw0KDQo+PiBTbyBy ZWFsbHkgdGhlIGNob2ljZSBpcyBiZXR3ZWVuIGEgcmFuZG9tIHZhbHVlIGZvcg0KPj4gZXZlcnkg ZGF0YWdyYW0gb3IgYSByYW5kb20gdmFsdWUgYXQgaW5pdGlhbGlzYXRpb24gb2YgYSBjb25uZWN0 aW9uDQo+PiBhbmQgaW5jcmVhc2luZyBieSAxIGZvciBldmVyeSBzdWJzZXF1ZW50IGRhdGFncmFt Lg0KPj4gDQo+PiBJ4oCZZCByZWFsbHkgbGlrZSB0byBzZWUgc29tZSBxdWFudGl0YXRpdmUgYW5h bHlzaXMgYXMgdG8gdGhlIGltcGFjdCBvZg0KPj4gYSByYW5kb20gdmFsdWUgcGVyIHBhY2tldCBh cyB3ZWxsIGFzIGJldHdlZW4gMSBhbmQgMy4NCj4gDQo+IEltcGFjdCBpbiB0ZXJtcyBvZiB3aGF0 Pw0KDQpXZWxsLCBhcyBhbiBpbXBsZW1lbnRlciBJIHdhbnQgdG8gY2hvb3NlIGJldHdlZW4gb25l IG9mIHRoZSBhbGdvcml0aG1zIHlvdSBwcm9wb3NlLiBCdXQgc2luY2UgSSBoYXZlIG5vIGNsdWUg d2hhdCB0aGUgcGVuYWx0eSBpcyBmb3IgZG9pbmcgcGVyIHBhY2tldCByYW5kb21pc2F0aW9uIGFz IG9wcG9zZWQgdG8gcGVyIGZsb3cgdGhhdCBpcyBoYXJkLiBJZiB0aGUgY29zdCBvZiBhIHBzZXVk b3JhbmRvbSBvcGVyYXRpb24gaXMgb3V0d2VpZ2hlZCBieSBvdGhlciBmYWN0b3JzIGludm9sdmVk IGluIHNlbmRpbmcgYSBwYWNrZXQgSSB3b3VsZCBwcm9iYWJseSBjaG9vc2Ugb3B0aW9uIDIuIE15 IGd1dCBmZWVsaW5nIHNheXMgaG93ZXZlciB0aGF0IGl0IGlzIGEgcHJldHR5IGV4cGVuc2l2ZSBv cGVyYXRpb24gdG8gZG8gb24gYSBwZXIgcGFja2V0IGJhc2lzLCBzbyBJIHdvdWxkIGV4cGVjdCB0 aGUgYWR2aXNlICB0byBiZSDigJx1c2UgMSBvciAz4oCdIHVubGVzc+KApi4uICBBbmQgc2ltaWxh cmx5LCB3aGF0IGlzIHRoZSBjb3N0IG9mIHRoZSBoYXNoIHZlcnN1cyB0aGUgcHJnPyBJZiB0aGV5 IGFyZSBjb21wYXJhYmxlIHdvdWxkIG9wdGlvbiAzIG5vdCBiZSBiZXR0ZXI/DQoNCkRvZXMgdGhh dCBtYWtlIHNlbnNlPw0KDQpLbGFhcw0KDQo+IA0KPiBUaGFua3MhDQo+IA0KPiBCZXN0IHJlZ2Fy ZHMsDQo+IC0tIA0KPiBGZXJuYW5kbyBHb250DQo+IFNJNiBOZXR3b3Jrcw0KPiBlLW1haWw6IGZn b250QHNpNm5ldHdvcmtzLmNvbQ0KPiBQR1AgRmluZ2VycHJpbnQ6IDY2NjYgMzFDNiBENDg0IDYz QjIgOEZCMSBFM0M0IEFFMjUgMEQ1NSAxRDRFIDc0OTINCj4gDQo+IA0KPiANCj4gDQoNCg== From nobody Wed Sep 9 08:50:23 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F681B33A4; Wed, 9 Sep 2015 08:46:13 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 xyIKxptvMm7e; Wed, 9 Sep 2015 08:46:11 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::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 482E21B339E; Wed, 9 Sep 2015 08:46:11 -0700 (PDT) Received: by ykei199 with SMTP id i199so21452986yke.0; Wed, 09 Sep 2015 08:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=H0MvrinFrq1gh7R8gL4scj4nqB5s2Jv6UEfTDS0L2XM=; b=L1C6qNSYAMIL0WFn1jxN2R/MZUZALJnI+cyERB/TssSv445OSI+pcuNXhjpkul315X 3HOIMtH3wZtGLATLecNHxuhFfT70U1NqzEHYqY4KmJLMZOfk33zpH0h4G/H/qxdO20Wh PvaQsV3fBKiSXACFryF8yXSEDRE9wjxcKgOAsJLaN3Pb7a556ngePUbrr/508+NL4Wdd x5+3ZA6vS0s5WIgb5nomSBdc+CwuNciFdL6ELH7QFmWh++8qHYvV4FtG+C1c5AAo34Tz sAumKGBLoezzIMtRF9Zth1g9KqKu7dw6N5VFViukMw+rsxE/P9qKHYC9ZcUx89KUuRNT XGyQ== MIME-Version: 1.0 X-Received: by 10.170.141.215 with SMTP id i206mr36188791ykc.51.1441813570143; Wed, 09 Sep 2015 08:46:10 -0700 (PDT) Received: by 10.13.237.135 with HTTP; Wed, 9 Sep 2015 08:46:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Sep 2015 11:46:10 -0400 Message-ID: From: Christopher Morrow To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 09 Sep 2015 08:50:22 -0700 Cc: "iesg@ietf.org" , "draft-ietf-grow-bmp.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-grow-bmp-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 15:46:13 -0000 On Tue, Sep 8, 2015 at 3:09 PM, Hannes Tschofenig wrote: > I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like = any other last call comments. > > I am not an expert in this field and cannot judge whether the designed pr= otocol makes sense. The content did, however, look complete to me. > > The security consideration section talks about different security threats= and focused on confidentiality protection quite a bit (but dismisses it i= n the end). I would think that authentication and integrity are probably mo= re important in this context. I suspect that a monitoring station will reac= t on information it receives (somehow) and false information could potentia= lly be a problem. How likely is it that an attacker injects false informati= on that will then the processed by a monitoring station (which could be loc= ated anywhere)? > > Currently, it appears that no specific security solution is mandatory to = implement. There are only examples listed, such as IPsec and TCP-AO. (For I= Psec I guess you would also use IKEv2 as a key management?) Would it be use= ful to have one security mechanism mandatory to implement? > The only useful example protocol available on modern routers is ... md5 tcp checksum... which if we add that to the draft we get kicked in the teeth over :( AO isn't even supported on modern unix systems, never mind 'not unix' syste= ms. there's another note about cisco not supporting this on ios/ios-xe/ios-xr ... surprisingly to me Juniper might actually support AO as of junos13 ? oh! it seems it does, so neat. (from a live device) > show version Hostname: rtr Model: mx80-48t Junos: 13.3R6.5 # set neighbor 192.110.255.5 authentication-algorithm ? Possible completions: aes-128-cmac-96 Cipher-based Message Authentication Code (AES128) (96 bits) hmac-sha-1-96 Hash-based Message Authentication Code (SHA1) (96 bi= ts) md5 Message Digest 5 (this area is rife with 'the standards process is a bucket of fail') AO would be nice, if we could actually get support in all the right pieces... Making it a mandatory item though will keep BMP from being deployable, I expect. Here's the WG discussion on this actually: (up and down a few messages is the gist of the discussion) > The sentence "Implementations of this protocol SHOULD require manual conf= iguration of the monitored and monitoring devices." feels a bit out of cont= ext in the security consideration section. I would delete it from the secur= ity consideration section or, alternatively, what it implies in terms of se= curity. > > The term 'transport' for a security protocol appears incorrect. For examp= le, instead of writing "... users of this protocol should consider using so= me type of transport that provides mutual authentication, data integrity, a= nd transport protection, ... " you could write "... users of this protocol = should consider using a security protocol that provides mutual authenticati= on, data integrity, and confidentiality protection, ... ". > This came up in a WG review I believe as well... in fact in the same thread referenced above is the IPSEC bit of discussion. -chris From nobody Wed Sep 9 09:01:19 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6842A1B3CCB; Wed, 9 Sep 2015 09:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.701 X-Spam-Level: X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham 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 8k3bnAPreybU; Wed, 9 Sep 2015 09:01:16 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D094F1B3CC6; Wed, 9 Sep 2015 09:01:15 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t89G1CDB003952; Wed, 9 Sep 2015 17:01:13 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t89G1BWf003931 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 9 Sep 2015 17:01:12 +0100 From: "Adrian Farrel" To: "'Paul Wouters'" , "'secdir'" , , References: In-Reply-To: Date: Wed, 9 Sep 2015 17:01:11 +0100 Message-ID: <032901d0eb18$bfedce80$3fc96b80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHsVJ7hf//oQeXQbFPOd3ymAlmEWZ39h4dQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21804.007 X-TM-AS-Result: No--3.649-10.0-31-10 X-imss-scan-details: No--3.649-10.0-31-10 X-TMASE-MatchedRID: 1GZI+iG+MtenykMun0J1wjCaEJt46PppGNMTWh+TA9taW2Ktn+I8/psf 8iX+9Eb6O+qMYX316PHxTwx4UJIMcqAfsWnLkystlVHM/F6YkvS1k3bRIdXVNLrfxlRjqBJ3Ffu 9xZgL7lcaGJ6hc5LcchQd7vVtOefElyrPeDQDh/LRfDQgu+j+5TmpQ/ih+jaoQGmQpWnG68Z7cQ Y9KMGwGm5y6UcS70rMOyDOOjGOGr4yc9zRj+LBosK7fT3t6J55bUpf52Lnbx3nnSt+j12Clld0o XI4+K7Vap4KvEK4xNYeR21wMUNDRPtbv/3CxyN1XP5rFAucBUFr9+Kgn2XgeLuwJO8uVRhKo8WM kQWv6iV95l0nVeyiuEIhOWyY9/MAC24oEZ6SpSmb4wHqRpnaDojY9D4Hq+u3X8dGQ6iTlxDzl35 7UO8JVxRuo3AmXKEpFziUsCIqUid4+ci7RYQU8pwiL+V0ePCFjluA7zq5/zLww8Tpv9CfFfR5gL DNdb9LuOZoyiCGGN8YgmnfWgSln5vaf0QvfUyeC8XKjsVbJjU= Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-ccamp-flexigrid-lambda-label X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 16:01:18 -0000 Thanks Paul, The idnits pre-5378 warning is caused by the "updates" clause. There is no pre-5378 material in the I-D. Cheers, Adrian > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: 08 September 2015 20:16 > To: secdir; iesg@ietf.org; draft-ietf-ccamp-flexigrid-lambda- > label.all@tools.ietf.org > Subject: secdir review of draft-ietf-ccamp-flexigrid-lambda-label > > > 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 draft is Ready with nits > > This document defines a new Flexi-Grid value for Lambda Switch Capable > (LSC) Label Switching Routers. The specification of this new label > references an external (ITU) specification. > > The security considerations of this document properly refers to other > documents, such as RFC3471, RFC3473 and RFC5920. No new security issues > are introduced in this document, as it merely defines a new label to use > which causes no backwards compatibility issues. > > nits: > > -- The document seems to lack a disclaimer for pre-RFC5378 work, but may > have content which was first submitted before 10 November 2008. If you > have contacted all the original authors and they are all willing to grant > the BCP78 rights to the IETF Trust, then this is fine, and you can ignore > this comment. If not, you may need to add the pre-RFC5378 disclaimer. > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.) > > > Paul From nobody Wed Sep 9 14:13:23 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03C51ACE89; Wed, 9 Sep 2015 14:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3QUxyVwAi5Fr; Wed, 9 Sep 2015 14:13:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8CB51B2C5E; Wed, 9 Sep 2015 14:13:20 -0700 (PDT) Received: from BY2PR0501MB1830.namprd05.prod.outlook.com (10.163.155.148) by BY2PR0501MB1816.namprd05.prod.outlook.com (10.163.155.146) with Microsoft SMTP Server (TLS) id 15.1.262.15; Wed, 9 Sep 2015 21:13:19 +0000 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from [172.29.36.176] (66.129.241.13) by BY2PR0501MB1830.namprd05.prod.outlook.com (10.163.155.148) with Microsoft SMTP Server (TLS) id 15.1.268.17; Wed, 9 Sep 2015 21:13:13 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "John G. Scudder" In-Reply-To: Date: Wed, 9 Sep 2015 17:13:05 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <0DDF8E7D-F322-4488-B4BD-C50004995A6B@juniper.net> References: To: Christopher Morrow X-Mailer: Apple Mail (2.2104) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY1PR10CA0012.namprd10.prod.outlook.com (25.160.197.22) To BY2PR0501MB1830.namprd05.prod.outlook.com (25.163.155.148) X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1830; 2:DmvLVPwu8Xt4JcH9t7aM45cnvqadGDnZBqbA8YN7D+lktBVJwwqmZReTrshewgxvp9/BSWVXgMD431erR3eNnuFX6BSmkd3Cg3KRUMrUQnf34GCaImn0PDozzc83UJOPJsYMxXQJsaquTL0QvjTLbIpsD+Ebp569zOTgaWxKTWk=; 3:GWo0CmnEQVHS2QaPOSkGGds39ul/GX7nXrIzVUN4EYZKr52raD7wp95dhuMqYOQ3HU+HDHqtVI5R7JSe9qOwu5YEKCrm7J0aCHkmWeQS+vTgI2w1vaDwexNeWxrBNLWKBdf3UTLSnB+mqOZb2CDVhQ==; 25:pNx3WCH6jHNtANQB8EfK6v5kU4LkPxcN8BRHoIgu/C2Diwm15OXfZdi9H0a+Au2shjyXYiGjM6NNErfbvpzh9PJY6eFMsKqycmzDMO7Lffsb4fKL4RZtDabTMuCses907GdRXyEPbApiyI4Vi7M4XCgtfMOZigKBFldKvjdgO0ViQxOtZsWqXE/fBgYEMtaDw2CR5dy18TlS25ROTCJV9fMsMGN8pGwhaDaNZVQ97CIxooFJAtKcE5VrzAs1QZc+iMZK4EWedR5wSOm6smuvlA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB1830; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1830; 20:mptQMl4gtw2KXTC7v2matGpG1y3rRJASgbDsMLc7TTbhr7W8HrFIXiWLi+W4Vw0Qc2i8Q9lZKsa8F12UjhZBPA/I3j4BCFGKuFjFXAgDtpVD/HShq6YXE+3mZgszu6/MeJmT2r4TlRvCWRuBGC3zelryLsHrQgTA4yZuwf+akbhKXJ6mTZJ1ZJnoOI+jl5TmeEdZkEQ1+fwOvc+uBo6/CI0BvjH05/0I5Pm/LTd6+7lsac/C7QtL8OOr7krrJcVNCu4alWH1/OGCW+RlLVvtwe+V0Le+rDpz9A2BHC7vSzOMCp94BY/WkNeF+vs/bNhCpj8Rqo6SuRNrkqQrI011Z54JqMnMp6EekmyJe+wGqfhalw1Yugvah7N38cwpmiquuWwEjny1anVUG6qUgM0JPieUDdxxE+xc/8Tdrikh+wvRDoW4LVUcFoaqqToftURvIdVVqPuMOFM+0DnQFv9Tj+9I8JlIjtNN6FrR4aXXSBwJCpl+AxOuHfLbKutdduMb; 4:oiokcOxZJjO9UZ6j4OpVCVzNA8QHVuitbPwn5ptGtaOKDEnnxP6mVj0I/QpHcXihJ/T+s0YsMzGUjHTMEsfYn37MT7tMLOaMjO6x5K8uHYWrxeGvvcn8VYR1VVpB0A2TULRCI2nRniXBw3/+1KMOtAXsGXaD9MEwp9OgKTjIOkTCEZ03at9d75Gj+I27ZrgDHPsPGKJbz2OpNOIYrW1YlXcMKenQEcGGY8z/lDuMBosSlZDLRBIXreM+SX5XgkE1LEFZZWqJFfP1BIzPzTnTlYdJTbq/4AT65pbR/ZfyV0c2YnnCTialhs54aID3WVcQ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BY2PR0501MB1830; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1830; X-Forefront-PRVS: 0694C54398 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(189002)(24454002)(199003)(377454003)(2950100001)(47776003)(62966003)(230783001)(40100003)(77156002)(83716003)(57306001)(64706001)(122386002)(36756003)(92566002)(82746002)(66066001)(23676002)(105586002)(106356001)(50226001)(68736005)(46102003)(101416001)(5001830100001)(42186005)(86362001)(5004730100002)(5007970100001)(87976001)(50466002)(77096005)(19580395003)(19580405001)(110136002)(5001960100002)(189998001)(4001540100001)(33656002)(97736004)(76176999)(5001860100001)(81156007)(50986999)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1830; H:[172.29.36.176]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjA1MDFNQjE4MzA7MjM6amY2a24ybTVQbnhKWHpSVnI5QnAvVG1n?= =?utf-8?B?NEsxMzlQc3l4UG9YTXloeFNhamc1aG5zSUxtNGZJZnNNa0lRUGRCSEdqTVdT?= =?utf-8?B?bFlFQzhLeHhMUlRjWi9TVlcvZFpBREhlMHA2N29MNVFMTjJKQnE3ZDNlOG93?= =?utf-8?B?Rzd3SmhCbUdjVjNkVnRvNW9lSUY5UTlrTmFIQjVocE1sc0trTlUraitSUTRQ?= =?utf-8?B?cGc1ejdBNVowQi9jbHMrVlh0bm83VUtIbDkwQTMzSS90c0Y2U29zYWFyeHUy?= =?utf-8?B?eTJNb1VKRGw5NVpyWDlHLzVwTlNZSGZKaytyQWdjU2RlTkNxWDhIUTR1c1Va?= =?utf-8?B?RXRETVFqaEo3bkdnRWF0cU5QaWtmdmluWE9TRFNoQzdTektOejJYMWtrdHF0?= =?utf-8?B?UVh2UW94U25MM09oMDBKbjh4LzV0aVFoK0pBcVVjNXZ0blM5M21PQjRiMUkw?= =?utf-8?B?SGtITHREeWkwWjZWTmErQ1VPYVFJWWhJSUh2ZUFYMFcyTDdNUXFUbUF5cHpo?= =?utf-8?B?ekdUN0NnS2lTNno1eGcxdkwrTEtiWFRaNXBrY25uYjZGZmx1NWp2RzlBN3Zq?= =?utf-8?B?QTNXNUgrUXh3QXV6M212NXZGSmJaZUVlWVBDanZBRExrZFZ4ZjVyUG1pWFNB?= =?utf-8?B?NkRxK3Z4Sk9sZERYTVVUeVFOc0huME9tTS9idHNETmkzMzRFUFdKQUxaRTYv?= =?utf-8?B?Y3UzN1lzSzIzdTdnRHJWaENlMG0wNmNITjVkdXQ1V0lEUkhUVFdrM21CV0Fn?= =?utf-8?B?elBHQkZHNkN5VHV5U3ROVGJyWHlaVlBUbzJ5VDdTd04rU29MRjc5YWZ3SDdw?= =?utf-8?B?TjZKekR6eGtUc2xRdjZlOWp3anBEd25yVUszOWptK01ZT0pMNjh4T2dMY2h3?= =?utf-8?B?MWlrRzlvb21KRk9yN2hqS1FUT2Z6K1Z3QVR1dHVuL05TNkx1RzE1bWw3dDll?= =?utf-8?B?VWpUdG1FY050ZTJFWTltK0tIZi9OOVA4Q29taVlhMjhwYVRMWHFQYlFERFJO?= =?utf-8?B?b1dFM2J5SzNHaVhZdzZ6SWVaME8xRHZaQ3VSSHFWTy9jN04vSmpVelVVYzly?= =?utf-8?B?YkJ5SXU3WHlic3ZkRC9rWG1VVkNoWkt1K0drd254SE9hTUpPREtIL3RJTkhh?= =?utf-8?B?akt4d2xlYzlIN1BSTDI1bmFSRlQvZDZ3UUhhR0JQUjhRRjI1QXdpQ1ZrZHB1?= =?utf-8?B?ZWFQSTRUaGtBU1lSajlIRGQvYjdjUG9pWjJCLzVaWXpsOHZUOXdqME04ZHRp?= =?utf-8?B?cERySm1RR09kY0FMdGJRdnN2R2tpSmt4NkMybldiZmwzN096SkJzWnc2NUZj?= =?utf-8?B?eHQ1dm5vUk5rU2dsbHpiVmdEUnBIQnl1ckw0Mk9FeUJRNlNYVWFidDROc2Fp?= =?utf-8?B?ZktFRG9BclNaZDRpWjFKa01FbXg0Sk9ZSzgzanllTnFkeDZoU1V2VmE0QXk1?= =?utf-8?B?ODN5amtUR0trMWR0STQ1SVFqN2NZaUYxQzh2YWNwZlJjNS9Gc1ZiOWFiaCsw?= =?utf-8?B?Q2wvTWQwWE5MTEZRRnFKVXlNZUg4Z3VNcXU0MDFDWFQ4Mzl6Vy9VcWk4WWlK?= =?utf-8?B?MlFUSmt1TWdMNjZEWDVCbkpQcmhMVlpZUEdGMlFpaEZ4eGNTREFubzMxNno4?= =?utf-8?B?MmJtajV5VE5pRHVkZjNyUHlNNmpxaWtNQ0dyTmlzSlYrMlpyNG1FQWJjbFZM?= =?utf-8?B?dXhpb05PQlRWSURLTjZjbTVKRXVQQWFXK0txS204djVtRGdsUE1MOGt5TGNL?= =?utf-8?B?eGFyTHZidnFOQzQ3T21pZ0J3PT0=?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1830; 5:BxsXpXMiS/rrcV3ERnWJsCiy6iFKte6EYsHLCHRtmnXAeuYByMLE0Mq+vcSITaPlfqBCrxz2deOGBCqALXoiBvJMTfLPDEGqLHA75gz2UqjL9l1Cn/7BSbq73WRnBIPOzWHujNr1qP06Xl7Qz9bjPg==; 24:6SV4Rk9JUewFcGWe3HFphFy/qfuS8uR1j524r5EYbc5yCwvg4cYuvw3P4Kzal9orLgbV9qc7LVo9P8GZIx89NQHy3GQ/vaRY1DJ8yk1U08c=; 20:9XhJBkmaWowd+gNFO+YMI4iViDkeDGhlm3QjQLXZshkUGgweTiIPu2vdma2lPS5Quc8vkNotY0BC0+O1+4NE7g== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2015 21:13:13.8655 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1830 X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1816; 2:tKGipZxyVGP9EnxUq8vvNQDvGu0ME0kLaZMRUfSDmmXxa9l8/B0/uQT4awIHDivRzcO+6x4KTVu6iOaitT3ILgJs5gzeTvA/n4fT2qpAw5bq/PivIB+NKIu6Ja+tqYYbuCt2TN/c+oAGozIc8rf9AaQYHk6ARqD8NGoO/d4MqY4=; 23:UmVus9MxKOkNZsMe1C3wbOM1HMZ6gYn7H8dW7pCLue4sTxRIBv9yUhIuZM65rtrClV4bgdQRkFccy+k+3LfLpPDmEVHO9JoiASIJp3F3VTj40g9OC8xPX8LQ6E6f1RhfEhVS2dDswZ20XgeOQqIvRjw6neFuyGBTryWxzkggPnmhCIgMxdYnMBbQn2r1feox X-OriginatorOrg: juniper.net Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-grow-bmp.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-grow-bmp-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 21:13:23 -0000 On Sep 9, 2015, at 11:46 AM, Christopher Morrow = wrote: >=20 > ios/ios-xe/ios-xr ... surprisingly to me Juniper might actually > support AO as of junos13 ? This was a surprise to me too, so I checked. Unfortunately, no. What = you're seeing is a "pre-standard" implementation. :-( > (this area is rife with 'the standards process is a bucket of fail') You'll hear no argument from me. =E2=80=93 John= From nobody Wed Sep 9 14:30:51 2015 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 103551AD067; Wed, 9 Sep 2015 14:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1441833822; bh=CV2u6XkbjFY0IdsCntbdk4F+qdWGQ+PxATsHMvnidWc=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Uj/MI6q20MxAkaHBrhzwasjBcYWbHdhLxnPp3ktvl1YQJebB8pycgQfBhTiD4XJmc svzk1lxYm85/pzFXPR6YERVtzpTs78GglIqOhVjDth/GEkV7HyoDYgtHmy5VszR2W6 hHkBAg5q2MLMAcmgcV5zDeTopapR9QK2NIpYnX90= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D886A1A7D84; Wed, 9 Sep 2015 14:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 PZnKIarGwL1M; Wed, 9 Sep 2015 14:23:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AC71A88EC; Wed, 9 Sep 2015 14:23:37 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150909212337.20507.3411.idtracker@ietfa.amsl.com> Date: Wed, 09 Sep 2015 14:23:37 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 09 Sep 2015 14:30:50 -0700 Subject: [secdir] [new-work] WG Review: Interface to Network Security Functions (i2nsf) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 21:23:42 -0000 A new IETF working group has been proposed in the Security 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 at ietf.org) by 2015-09-16. Interface to Network Security Functions (i2nsf) ------------------------------------------------ Current Status: Proposed WG Chairs: TBD Assigned Area Director: Kathleen Moriarty Mailing list Address: i2nsf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/i2nsf Archive: https://mailarchive.ietf.org/arch/browse/i2nsf/ Charter: A Network Security Function (NSF) is a function used to ensure integrity, confidentiality, or availability of network communications, to detect unwanted network activity, or to block or at least mitigate the effects of unwanted activity. NSFs are provided and consumed in increasingly diverse environments. Users could consume network security services enforced by NSFs hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both. Similarly, service providers may offer their customers network security services that are enforced by multiple security products, functions from different vendors, or open source technologies. NSFs may be provided by physical and/or virtualized infrastructure. Without standard interfaces to control and monitor the behavior of NSFs, it has become virtually impossible for providers of security services to automate service offerings that utilize different security functions from multiple vendors. The goal of I2NSF is to define a set of software interfaces and data models for controlling and monitoring aspects of physical and virtual NSFs, enabling clients to specify rulesets. If the working group finds it necessary to work on an information model before the data models, to help provide guidance and derive the data models, it may do so. The working group will decide later whether the information model needs to be published as an RFC. Other aspects of NSFs, such as device or network provisioning and configuration, are out of scope. As there are many different security vendors or open source technologies supporting different features and functions on their devices, I2NSF will focus on flow-based NSFs that provide treatment to packets/flows, such as Intrusion Protection/Detection System (IPS/IDS), web filtering, flow filtering, deep packet inspection, or pattern matching and remediation. Controlling and monitoring aspects of NSFs include the ability to specify rules (by a single controller at the first phase), query, and monitor NSFs by one or more management entities. The initial phase of I2NSF will only consider one single controller that can specify or change rules to NSFs because multi-headed control requires the coordination to avoid potential conflict of rules. The NSFs can be monitored by multiple entities, but the database update and synchronization among multiple management entities are out of scope for I2NSF. I2NSF will specify interfaces at two functional levels for the control and monitoring of network security functions: The I2NSF Capability Layer specifies how to control and monitor NSFs at a functional implementation level. The term "Functional Implementation" is used to emphasize that the rules (for control and monitor) of NSFs have to be implementable by most NSFs. I2NSF will standardize a set of interfaces by which a security controller can invoke, operate, and monitor NSFs. The I2NSF Service Layer defines how clients' security policies may be expressed to a security controller. The controller implements its policies according to the various capabilities provided by the I2NSF Capability Layer. The I2NSF Service Layer also allows the client to monitor the client specific policies. A client may leverage the I2NSF Service Layer interface to express security policies to a security controller, which in turn interacts with one or more NSFs through the I2NSF Capability Layer interface. Alternatively, a client may interact with one or more NSFs directly through the I2NSF Capability Layer interface. Since there could be many depths or types of Service Layer policies, the following bullets further clarify the scope of I2NSF: o Only the simple Service Layer policies that are modeled as closely as possible on the Capability Layer are within the scope. Simple Service Layer policies can be directly translated to capability layer rules with a direct mapping that might include a customer ID to be translated to tags carried by packets, but might not specify the NSF. This flexibility in the simple Service Layer enables a security controller to handle issues like multi-tenancy and the choice between available NSFs for a given policy. o I2NSF will not specify abstract or sophisticated policies from clients. Expressing policies in ways other than the model used by the Capability Layer is out of scope. o The translation mechanism/methods from Service Layer policies to Capability layer commands are out of scope for I2NSF. However, I2NSF will provide a discussion forum for Informational drafts on data models, APIs, etc. that demonstrate how more complex Service Layer policies and formats may be translated to Capability Layer functions. Such documents would be pursued outside the WG. Standard interfaces for monitoring and controlling the behavior of NSFs are essential building blocks for providers of security service to automate the use of different NSFs from multiple vendors. This work will leverage the existing protocols and data models defined by the I2RS, NETCONF, and NETMOD working groups. If extensions to these protocols or data models are needed, requirements will be developed by this WG, and the extensions will be developed in cooperation with the working groups responsible for the protocols. The I2NSF working group's deliverables include: o A single document covering use cases, problem statement, and gap analysis document. This document will initially be produced for reference as a living list to track and record discussions: the working group may decide to not publish this document as an RFC. o A framework document, presenting an overview of the use of NSFs and the purpose of the models developed by the working group. This document will also be a reference text to guide the main work and the working group may decide to not publish this document as an RFC. o If the working group considers it necessary, a single, unified, Information Model to describe the control and monitoring of flow-based NSFs. o YANG data models for the control and monitoring of NSFs. o A vendor-neutral vocabulary to enable the characteristics and behavior of NSFs to be specified without requiring the NSFs themselves to be standardized, so that "security controller" or "manager" have a common base to choose the appropriate NSFs (by different vendors) that can fulfill the requests requested by clients. o An examination of existing secure communication mechanisms to identify the appropriate ones for carrying the controlling and monitoring information between the NSFs and their management entities. This document may also be produced as a working document that is not published as an RFC. The working group may additionally choose to develop documents to describe requirements for extensions (if any) to existing protocols used by the working group, to explain how the data models are used to monitor and control flow-based NSFs, and to describe how to use I2RS and NETCONF to carry the content of the data models. These documents may be published as Informational RFCs or may be working documents that are discarded once they have triggered the necessary work. The working group will work closely with the I2RS, NETCONF, and NETMOD WGs. The working group will communicate with external SDOs like ETSI NFV and will encourage open source code development related to the working group scope in organizations like ONF, OpenStack, ODL, and OPNFV. The working group must have the above deliverables completed within 24 months. The responsible AD will close the working group at that time if they are not completed or close to completion. The working group may be closed earlier if substantial progress is not being made. Milestones: Nov 2015 - Adopt use Cases, problem statement, and gap analysis as WG document Feb 2016 - Adopt framework as WG document Jun 2016 - Adopt requirements for extensions to protocols as WG document Jun 2016 - Adopt examination of existing secure communication mechanisms as WG document Jun 2016 - Adopt info model as WG document (if desired) Jul 2016 - Adopt data models as WG document Aug 2016 - WG decides whether to progress adopted drafts for publication as RFCs (use cases, framework, information model, and examination of existing secure communication mechanisms) Aug 2016 - Adopt applicability statements as WG Document Oct 2016 - Adopt IANA registry consideration as WG document Apr 2017 - All early drafts to IESG for publication (if WG decided to proceed): use cases, problem statement, and gap analysis document; framework document; information model requirements for extensions to protocols document; examination of existing secure communication mechanisms document Apr 2017 - Data Models and Applicability Statements to IESG for publication Oct 2017 - Working group re-charter or close _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Sep 10 04:13:28 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5581B3C1E for ; Thu, 10 Sep 2015 04:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 IOxhobWXQXiM for ; Thu, 10 Sep 2015 04:13:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 2FF121B33A5 for ; Thu, 10 Sep 2015 04:13:20 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t8ABDGjc028087 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 14:13:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t8ABDGPu021187; Thu, 10 Sep 2015 14:13:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22001.26060.378670.968701@fireball.acr.fi> Date: Thu, 10 Sep 2015 14:13:16 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 11:13:23 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Steve Hanna is next in the rotation. For telechat 2015-09-17 Reviewer LC end Draft Dave Cridland T 2015-09-08 draft-ietf-pals-vccv-for-gal-05 Chris Inacio T 2015-07-29 draft-ietf-homenet-dncp-09 Ben Laurie T 2015-08-11 draft-ietf-dnsop-dns-terminology-04 Hannes Tschofenig TR2015-09-17 draft-wkumari-dhc-capport-16 Carl Wallace T 2015-09-01 draft-ietf-trill-pseudonode-nickname-06 For telechat 2015-10-01 Daniel Kahn Gillmor T 2015-09-17 draft-ietf-tzdist-caldav-timezone-ref-04 Matt Lepinski T 2015-08-11 draft-ietf-dnsop-root-loopback-03 Frank Xialiang T 2015-09-03 draft-ietf-conex-mobile-05 Last calls and special requests: Derek Atkins 2015-09-23 draft-kivinen-ipsecme-oob-pubkey-11 John Bradley 2015-09-03 draft-ietf-mpls-lsp-ping-reply-mode-simple-03 Alan DeKok 2015-09-10 draft-ietf-ippm-owamp-registry-02 Donald Eastlake 2015-09-11 draft-ietf-dane-openpgpkey-05 Shawn Emery 2015-09-23 draft-ietf-pwe3-iccp-stp-04 Daniel Kahn Gillmor E None draft-ietf-rtcweb-security-08 Tobias Gondrom E None draft-ietf-rtcweb-security-arch-11 Tobias Gondrom 2015-09-22 draft-ietf-v6ops-siit-dc-02 Olafur Gudmundsson 2015-09-22 draft-ietf-v6ops-siit-dc-2xlat-01 Phillip Hallam-Baker 2015-09-22 draft-ietf-v6ops-siit-eam-01 Joe Salowey 2015-09-07 draft-josefsson-scrypt-kdf-03 Brian Weis 2015-09-23 draft-housley-sow-author-statistics-00 Tom Yu 2015-09-08 draft-ietf-dhc-dhcpv4-active-leasequery-05 Dacheng Zhang 2015-09-04 draft-ietf-dice-profile-16 -- kivinen@iki.fi From nobody Thu Sep 10 17:49:37 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A901B4302; Thu, 10 Sep 2015 17:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ThQudoNYpEVW; Thu, 10 Sep 2015 17:49:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505101B2D58; Thu, 10 Sep 2015 17:49:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXM03819; Fri, 11 Sep 2015 00:49:32 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Sep 2015 01:49:30 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.68]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Fri, 11 Sep 2015 08:49:25 +0800 From: "Xialiang (Frank)" To: secdir , "iesg@ietf.org" , "draft-ietf-conex-mobile.all@ietf.org" Thread-Topic: secdir review of draft-ietf-conex-mobile-05 Thread-Index: AdDsK7I1VyJu7Bl6QJ2ZXX3RKt6srw== Date: Fri, 11 Sep 2015 00:49:24 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AE63401SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [secdir] secdir review of draft-ietf-conex-mobile-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 00:49:37 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12AE63401SZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 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 comment. This memo describes a mobile communications use case for congestion exposur= e (ConEx) with a particular focus on those mobile communication networks th= at are architecturally similar to the 3GPP Evolved Packet System (EPS). I have the following comments: l 1. It should be helpful to consider the communication security between t= he ConEx senders and receivers such as the Confidentiality, data integrity = and peer entity authentication in the security considerations part. Because= in general, the corresponding risks are still possible to exist. l 2. The authentication mechanism among all the elements of ConEx solution= should also be considered to handle the condition of faked messages or inv= alid peer elements. Recommendation: Ready With Issues B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12AE63401SZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 writ= ten primarily for the benefit of the security area directors.  Do= cument editors and WG chairs should treat these comments just like any= other last call comment.

 

This memo describes a mobile communicatio= ns use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally simi= lar to the 3GPP Evolved Packet System (EPS). 

 

I have the following comments:=

l  1. It should be = helpful to consider the communication security between the ConEx senders an= d receivers such as the Confidentiality, data integrity and peer entity authentication in the security considerations part. Becaus= e in general, the corresponding risks are still possible to exist.

l  2. The authentic= ation mechanism among all the elements of ConEx solution should also be con= sidered to handle the condition of faked messages or invalid peer elements.

 

Recommendation:  Ready With Issues

 

B.R.

Frank

 =

--_000_C02846B1344F344EB4FAA6FA7AF481F12AE63401SZXEMA502MBSchi_-- From nobody Fri Sep 11 02:20:42 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851701A0242; Fri, 11 Sep 2015 02:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 p6w_tVEBltGK; Fri, 11 Sep 2015 02:20:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B071A0035; Fri, 11 Sep 2015 02:20:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBD60438; Fri, 11 Sep 2015 09:20:26 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Sep 2015 10:20:24 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.68]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Fri, 11 Sep 2015 17:20:18 +0800 From: "Xialiang (Frank)" To: Dirk Kutscher Thread-Topic: secdir review of draft-ietf-conex-mobile-05 Thread-Index: AdDsK7I1VyJu7Bl6QJ2ZXX3RKt6srwAQblSwAAEGHKA= Date: Fri, 11 Sep 2015 09:20:17 +0000 Message-ID: References: <82AB329A76E2484D934BBCA77E9F52499A07A349@Hydra.office.hd> In-Reply-To: <82AB329A76E2484D934BBCA77E9F52499A07A349@Hydra.office.hd> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AE6349DSZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-conex-mobile.all@ietf.org" , secdir Subject: Re: [secdir] secdir review of draft-ietf-conex-mobile-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 09:20:36 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12AE6349DSZXEMA502MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRGlyaywNClRoYW5rIHlvdSBmb3IgcXVpY2sgcmVzcG9uc2UuDQpJIHJldmlld2VkIHRoZSBk cmFmdHMgeW91IG1lbnRpb25lZCBiZWxvdy4gSSBhZ3JlZSB0aGF0IHRoZXkgYWxyZWFkeSBkaXNj dXNzZWQgdGhlIGdlbmVyYWwgc2VjdXJpdHkgaXNzdWVzIEkgYW0gY29uY2VybmVkLCBlc3BlY2lh bGx5IGluIHRoZSBkcmFmdC1jb25leC1hYnN0cmFjdC1tZWNoLTEzIGFuZCBpdHMgcmVmZXJlbmNl Lg0KDQpTbywgaW4gZ2VuZXJhbCwgbXkgY29uY2VybnMgYXJlIGFkZHJlc3NlZC4gQnV0IEkgc3Rp bGwgaGF2ZSBhIGxpdHRsZSBiaXQgZG91YnRzIGFib3V0IHBvc3NpYmx5IG5ldyBzZWN1cml0eSBp c3N1ZXMgZm9yIHRoZSB1c2UgY2FzZXMgb2YgdXNpbmcgQ29uRXggcHJvdG9jb2wgb3ZlciB0aGUg bW9iaWxlIGNvbW11bmljYXRpb24gbmV0d29ya3MuIEkgYW0gbm90IGFuIGV4cGVydCBpbiB0aGlz IGFyZWEsIGNhbiB5b3UgY2xhcmlmeSBtZT8NCg0KVGhhbmtzIQ0KDQpCLlIuDQpGcmFuaw0KDQq3 orz+yMs6IERpcmsgS3V0c2NoZXIgW21haWx0bzpEaXJrLkt1dHNjaGVyQG5lY2xhYi5ldV0NCrei y83KsbzkOiAyMDE1xOo51MIxMcjVIDE2OjUyDQrK1bz+yMs6IFhpYWxpYW5nIChGcmFuayk7IHNl Y2RpcjsgaWVzZ0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb25leC1tb2JpbGUuYWxsQGlldGYub3Jn DQrW98ziOiBSRTogc2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWNvbmV4LW1vYmlsZS0wNQ0K DQpIaSBGcmFuaywNCg0KdGhhbmtzIGZvciB0aGUgcmV2aWV3Lg0KDQpUaGUgc2VjdXJpdHkgaXNz dWVzIHlvdSBtZW50aW9uZWQgd291bGQgYXBwbHkgdG8gQ29uRXggaW4gZ2VuZXJhbC4gVGhlIGNv cnJlc3BvbmRpbmcgZG9jdW1lbnRzIGFyZSBkaXNjdXNzaW5nIHBvdGVudGlhbCBzZWN1cml0eSBp c3N1ZXM6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvbmV4LWFi c3RyYWN0LW1lY2gtMTMjcGFnZS0yNCAoYWxzbyBzZWUgdGhlIHJlZmVyZW5jZXMpDQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb25leC1kZXN0b3B0LTA5I3BhZ2UtMTAN Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvbmV4LXRjcC1tb2RpZmlj YXRpb25zLTA0I3BhZ2UtMTENCg0KV2Whr2QgdGhlcmVmb3JlIHJhdGhlciBub3QgZHVwbGljYXRl IHRoYXQgZGlzY3Vzc2lvbiBpbiBjb25leC1tb2JpbGUuDQoNClJlZ2FyZGluZyB0aGUgc2VjdXJp dHkgcmlza3MgeW91IG1lbnRpb25lZCwgSaGvZCBzYXkgaXQgaXMgcXVlc3Rpb25hYmxlIHdoZXRo ZXIgQ29uRXggaW50cm9kdWNlcyBhZGRpdGlvbmFsIGlzc3VlcyBmb3IgY29uZmlkZW50aWFsaXR5 IChjb21wYXJlZCB0byBJUCBhbG9uZSkuDQoNClRoYW5rcywNCkRpcmsNCg0KDQoNCkZyb206IFhp YWxpYW5nIChGcmFuaykgW21haWx0bzpmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tXQ0KU2VudDog RnJlaXRhZywgMTEuIFNlcHRlbWJlciAyMDE1IDAyOjQ5DQpUbzogc2VjZGlyOyBpZXNnQGlldGYu b3JnPG1haWx0bzppZXNnQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1jb25leC1tb2JpbGUuYWxsQGll dGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNvbmV4LW1vYmlsZS5hbGxAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29uZXgtbW9iaWxlLTA1DQoNCkhpLA0K SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBw cmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4g IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVu dHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudC4NCg0KVGhpcyBtZW1vIGRl c2NyaWJlcyBhIG1vYmlsZSBjb21tdW5pY2F0aW9ucyB1c2UgY2FzZSBmb3IgY29uZ2VzdGlvbiBl eHBvc3VyZSAoQ29uRXgpIHdpdGggYSBwYXJ0aWN1bGFyIGZvY3VzIG9uIHRob3NlIG1vYmlsZSBj b21tdW5pY2F0aW9uIG5ldHdvcmtzIHRoYXQgYXJlIGFyY2hpdGVjdHVyYWxseSBzaW1pbGFyIHRv IHRoZSAzR1BQIEV2b2x2ZWQgUGFja2V0IFN5c3RlbSAoRVBTKS4NCg0KSSBoYXZlIHRoZSBmb2xs b3dpbmcgY29tbWVudHM6DQoNCmwgIDEuIEl0IHNob3VsZCBiZSBoZWxwZnVsIHRvIGNvbnNpZGVy IHRoZSBjb21tdW5pY2F0aW9uIHNlY3VyaXR5IGJldHdlZW4gdGhlIENvbkV4IHNlbmRlcnMgYW5k IHJlY2VpdmVycyBzdWNoIGFzIHRoZSBDb25maWRlbnRpYWxpdHksIGRhdGEgaW50ZWdyaXR5IGFu ZCBwZWVyIGVudGl0eSBhdXRoZW50aWNhdGlvbiBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgcGFydC4gQmVjYXVzZSBpbiBnZW5lcmFsLCB0aGUgY29ycmVzcG9uZGluZyByaXNrcyBhcmUg c3RpbGwgcG9zc2libGUgdG8gZXhpc3QuDQoNCmwgIDIuIFRoZSBhdXRoZW50aWNhdGlvbiBtZWNo YW5pc20gYW1vbmcgYWxsIHRoZSBlbGVtZW50cyBvZiBDb25FeCBzb2x1dGlvbiBzaG91bGQgYWxz byBiZSBjb25zaWRlcmVkIHRvIGhhbmRsZSB0aGUgY29uZGl0aW9uIG9mIGZha2VkIG1lc3NhZ2Vz IG9yIGludmFsaWQgcGVlciBlbGVtZW50cy4NCg0KUmVjb21tZW5kYXRpb246ICBSZWFkeSBXaXRo IElzc3Vlcw0KDQpCLlIuDQpGcmFuaw0KDQo= --_000_C02846B1344F344EB4FAA6FA7AF481F12AE6349DSZXEMA502MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Dirk,

Thank you = for quick response.

I reviewed= the drafts you mentioned below. I agree that they already discussed the ge= neral security issues I am concerned, especially in the draft-conex-abstrac= t-mech-13 and its reference.

 = ;

So, in gen= eral, my concerns are addressed. But I still have a little bit doubts about= possibly new security issues for the use cases of using ConEx protocol over the mobile communication networks. I am not an expert in thi= s area, can you clarify me?

 = ;

Thanks!

 = ;

B.R.<= /o:p>

Frank=

 = ;

=B7=A2=BC=FE=C8=CB: Dirk Ku= tscher [mailto:Dirk.Kutscher@neclab.eu]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA9=D4=C211=C8=D5 16:52
=CA=D5=BC=FE=C8=CB: Xialiang (Frank); secdir; iesg@ietf.org; draft-ietf-conex-mobile.al= l@ietf.org
=D6=F7=CC=E2: RE: secdir review of draft-ietf-conex-mobile-05
<= /p>

 

Hi Frank,<= o:p>

 = ;

thanks for= the review.

 = ;

The securi= ty issues you mentioned would apply to ConEx in general. The corresponding = documents are discussing potential security issues:

 = ;

htt= ps://tools.ietf.org/html/draft-ietf-conex-abstract-mech-13#page-24 (also see the references)

https://t= ools.ietf.org/html/draft-ietf-conex-destopt-09#page-10

https://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-04#page-11<= /a>

 = ;

We=A1=AFd = therefore rather not duplicate that discussion in conex-mobile.<= /span>

 = ;

Regarding = the security risks you mentioned, I=A1=AFd say it is questionable whether C= onEx introduces additional issues for confidentiality (compared to IP alone).

 = ;

Thanks,

Dirk<= /o:p>

 = ;

 = ;

 

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Freitag, 11. September 2015 02:49
To: secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
Subject: secdir review of draft-ietf-conex-mobile-05

 

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 writ= ten primarily for the benefit of the security area directors.  Do= cument editors and WG chairs should treat these comments just like any= other last call comment.

 

This memo describes a mobile communicatio= ns use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally simi= lar to the 3GPP Evolved Packet System (EPS). 

 

I have the following comments:=

l  1. It should be = helpful to consider the communication security between the ConEx senders an= d receivers such as the Confidentiality, data integrity and peer entity authentication in the security considerations part. Becaus= e in general, the corresponding risks are still possible to exist.

l  2. The authentic= ation mechanism among all the elements of ConEx solution should also be con= sidered to handle the condition of faked messages or invalid peer elements.

 

Recommendation:  Ready With Issues

 

B.R.

Frank

 =

--_000_C02846B1344F344EB4FAA6FA7AF481F12AE6349DSZXEMA502MBSchi_-- From nobody Fri Sep 11 04:05:18 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4E91B3FF4; Fri, 11 Sep 2015 01:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EjPeuyI4V116; Fri, 11 Sep 2015 01:52:03 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3B51B3F70; Fri, 11 Sep 2015 01:51:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D26B910A888; Fri, 11 Sep 2015 10:51:56 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsA3OMzqnvIx; Fri, 11 Sep 2015 10:51:56 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id AF40510A0A2; Fri, 11 Sep 2015 10:51:48 +0200 (CEST) Received: from HYDRA.office.hd ([169.254.4.236]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Fri, 11 Sep 2015 10:51:48 +0200 From: Dirk Kutscher To: "Xialiang (Frank)" , secdir , "iesg@ietf.org" , "draft-ietf-conex-mobile.all@ietf.org" Thread-Topic: secdir review of draft-ietf-conex-mobile-05 Thread-Index: AdDsK7I1VyJu7Bl6QJ2ZXX3RKt6srwAQblSw Date: Fri, 11 Sep 2015 08:51:48 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F52499A07A349@Hydra.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.102] Content-Type: multipart/alternative; boundary="_000_82AB329A76E2484D934BBCA77E9F52499A07A349Hydraofficehd_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 11 Sep 2015 04:05:12 -0700 Subject: Re: [secdir] secdir review of draft-ietf-conex-mobile-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 08:52:07 -0000 --_000_82AB329A76E2484D934BBCA77E9F52499A07A349Hydraofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Frank, thanks for the review. The security issues you mentioned would apply to ConEx in general. The corr= esponding documents are discussing potential security issues: https://tools.ietf.org/html/draft-ietf-conex-abstract-mech-13#page-24 (also= see the references) https://tools.ietf.org/html/draft-ietf-conex-destopt-09#page-10 https://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-04#page-11 We'd therefore rather not duplicate that discussion in conex-mobile. Regarding the security risks you mentioned, I'd say it is questionable whet= her ConEx introduces additional issues for confidentiality (compared to IP = alone). Thanks, Dirk From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com] Sent: Freitag, 11. September 2015 02:49 To: secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org Subject: secdir review of draft-ietf-conex-mobile-05 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 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 comment. This memo describes a mobile communications use case for congestion exposur= e (ConEx) with a particular focus on those mobile communication networks th= at are architecturally similar to the 3GPP Evolved Packet System (EPS). I have the following comments: l 1. It should be helpful to consider the communication security between t= he ConEx senders and receivers such as the Confidentiality, data integrity = and peer entity authentication in the security considerations part. Because= in general, the corresponding risks are still possible to exist. l 2. The authentication mechanism among all the elements of ConEx solution= should also be considered to handle the condition of faked messages or inv= alid peer elements. Recommendation: Ready With Issues B.R. Frank --_000_82AB329A76E2484D934BBCA77E9F52499A07A349Hydraofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Frank,<= o:p>

 = ;

thanks for= the review.

 = ;

The securi= ty issues you mentioned would apply to ConEx in general. The corresponding = documents are discussing potential security issues:

 = ;

htt= ps://tools.ietf.org/html/draft-ietf-conex-abstract-mech-13#page-24 (also see the references)

https://t= ools.ietf.org/html/draft-ietf-conex-destopt-09#page-10

https://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-04#page-11<= /a>

 = ;

We’d= therefore rather not duplicate that discussion in conex-mobile.=

 = ;

Regarding = the security risks you mentioned, I’d say it is questionable whether = ConEx introduces additional issues for confidentiality (compared to IP alone).

 = ;

Thanks,

Dirk<= /o:p>

 = ;

 = ;

 

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Freitag, 11. September 2015 02:49
To: secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
Subject: secdir review of draft-ietf-conex-mobile-05

 

Hi,

I have reviewed this document as part of th= e security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primar= ily for the benefit of the security area directors.  Document edi= tors and WG chairs should treat these comments just like any other las= t call comment.

 

This memo describes a mobile communications= use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally simi= lar to the 3GPP Evolved Packet System (EPS). 

 

I have the following comments:

= l  1. It should be helpful to consider the communication security b= etween the ConEx senders and receivers such as the Confidentiality, data integrity and peer entity authentication in the security consideratio= ns part. Because in general, the corresponding risks are still possible to = exist.

= l  2. The authentication mechanism among all the elements of ConEx = solution should also be considered to handle the condition of faked messages or invalid peer elements.

 

Recommendation:  Ready With Issues

 

B.R.

Frank

 

--_000_82AB329A76E2484D934BBCA77E9F52499A07A349Hydraofficehd_-- From nobody Fri Sep 11 04:05:19 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3061A90D5; Fri, 11 Sep 2015 02:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 T6aFul9Vk3ph; Fri, 11 Sep 2015 02:49:00 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D991A9172; Fri, 11 Sep 2015 02:48:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 51EDF10A89F; Fri, 11 Sep 2015 11:48:58 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbQkP3jRJ7eg; Fri, 11 Sep 2015 11:48:58 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 2DF1810A87C; Fri, 11 Sep 2015 11:48:50 +0200 (CEST) Received: from HYDRA.office.hd ([169.254.4.236]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Fri, 11 Sep 2015 11:48:50 +0200 From: Dirk Kutscher To: "Xialiang (Frank)" Thread-Topic: secdir review of draft-ietf-conex-mobile-05 Thread-Index: AdDsK7I1VyJu7Bl6QJ2ZXX3RKt6srwAQblSwAAEGHKAAAMkDEA== Date: Fri, 11 Sep 2015 09:48:49 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F52499A07B50E@Hydra.office.hd> References: <82AB329A76E2484D934BBCA77E9F52499A07A349@Hydra.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.102] Content-Type: multipart/alternative; boundary="_000_82AB329A76E2484D934BBCA77E9F52499A07B50EHydraofficehd_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 11 Sep 2015 04:05:13 -0700 Cc: "iesg@ietf.org" , "draft-ietf-conex-mobile.all@ietf.org" , secdir Subject: Re: [secdir] secdir review of draft-ietf-conex-mobile-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 09:49:02 -0000 --_000_82AB329A76E2484D934BBCA77E9F52499A07B50EHydraofficehd_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRnJhbmssDQoNCkluIGdlbmVyYWwsIHRoZSBDb25FeC1yZWxhdGVkIHJpc2tzIHJlZ2FyZGlu ZyBtYW5pcHVsYXRpbmcgY29uZ2VzdGlvbiBub3RpZmljYXRpb24vZXhwb3N1cmUgY2FuIGFwcGx5 IHRvIG1vYmlsZSBuZXR3b3JrcywgdG9vLg0KDQpXaGF0IGNvdWxkIHBlcmhhcHMgYmUgc2FpZCBp cyB0aGF0IG1vYmlsZSBuZXR3b3JrcyAoVU1UUywgTFRFKSBlbXBsb3kgYSB2aXJ0dWFsLWNpcmN1 aXQtbGlrZSBiZWFyZXIgbW9kZWwgZm9yIHRoZSBhY2Nlc3MsIGkuZS4sIHVzZXJzIGluIGEgY2Vs bCBjYW4gZ2VuZXJhbGx5IG5vdCBzZWUgb3RoZXIgdXNlcnOhryB0cmFmZmljIKhDIHNvIHRoYXQg d291bGQgcnVsZSBvdXQgc29tZSB0aHJlYXRzLiBBbHNvLCBhdXRoZW50aWNhdGlvbiBpcyBwYXJ0 IG9mIHRoZSBiZWFyZXIgZXN0YWJsaXNobWVudCwgc28gdGhlIG5ldHdvcmsgZ2VuZXJhbGx5IGtu b3dzIHRoZSB1c2VyIGFuZCBkZXZpY2UgaWRlbnRpdHkuDQoNCk5vdywgYXNzdW1pbmcgdGhhdCBt b2JpbGUgbmV0d29ya3MgY2FuIGJlIHN1YmplY3QgdG8gcGFzc2l2ZSBtb25pdG9yaW5nLCBvbmUg Y291bGQgY2xhaW0gdGhhdCB0aGlzIHdvdWxkIGVuYWJsZSBhdHRhY2tlcnMgdG8gY29sbGVjdCBp bmZvcm1hdGlvbiBhYm91dCBhIHVzZXKhr3MgY29uZ2VzdGlvbiBjb250cmlidXRpb24gKGFsc28g b3ZlciB0aW1lKSwgYnV0IHRoYXQgdGhyZWF0IHNlZW1zIGxlc3MgY3JpdGljYWwgKGNvbXBhcmVk IHRvIGV4cG9zaW5nIHRoZSBwYXlsb2FkIGl0c2VsZikuDQoNCkJlc3QgcmVnYXJkcywNCkRpcmsN Cg0KDQpGcm9tOiBYaWFsaWFuZyAoRnJhbmspIFttYWlsdG86ZnJhbmsueGlhbGlhbmdAaHVhd2Vp LmNvbV0NClNlbnQ6IEZyZWl0YWcsIDExLiBTZXB0ZW1iZXIgMjAxNSAxMToyMA0KVG86IERpcmsg S3V0c2NoZXINCkNjOiBzZWNkaXI7IGllc2dAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY29uZXgtbW9i aWxlLmFsbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IHNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0 Zi1jb25leC1tb2JpbGUtMDUNCg0KSGkgRGlyaywNClRoYW5rIHlvdSBmb3IgcXVpY2sgcmVzcG9u c2UuDQpJIHJldmlld2VkIHRoZSBkcmFmdHMgeW91IG1lbnRpb25lZCBiZWxvdy4gSSBhZ3JlZSB0 aGF0IHRoZXkgYWxyZWFkeSBkaXNjdXNzZWQgdGhlIGdlbmVyYWwgc2VjdXJpdHkgaXNzdWVzIEkg YW0gY29uY2VybmVkLCBlc3BlY2lhbGx5IGluIHRoZSBkcmFmdC1jb25leC1hYnN0cmFjdC1tZWNo LTEzIGFuZCBpdHMgcmVmZXJlbmNlLg0KDQpTbywgaW4gZ2VuZXJhbCwgbXkgY29uY2VybnMgYXJl IGFkZHJlc3NlZC4gQnV0IEkgc3RpbGwgaGF2ZSBhIGxpdHRsZSBiaXQgZG91YnRzIGFib3V0IHBv c3NpYmx5IG5ldyBzZWN1cml0eSBpc3N1ZXMgZm9yIHRoZSB1c2UgY2FzZXMgb2YgdXNpbmcgQ29u RXggcHJvdG9jb2wgb3ZlciB0aGUgbW9iaWxlIGNvbW11bmljYXRpb24gbmV0d29ya3MuIEkgYW0g bm90IGFuIGV4cGVydCBpbiB0aGlzIGFyZWEsIGNhbiB5b3UgY2xhcmlmeSBtZT8NCg0KVGhhbmtz IQ0KDQpCLlIuDQpGcmFuaw0KDQq3orz+yMs6IERpcmsgS3V0c2NoZXIgW21haWx0bzpEaXJrLkt1 dHNjaGVyQG5lY2xhYi5ldV0NCreiy83KsbzkOiAyMDE1xOo51MIxMcjVIDE2OjUyDQrK1bz+yMs6 IFhpYWxpYW5nIChGcmFuayk7IHNlY2RpcjsgaWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRm Lm9yZz47IGRyYWZ0LWlldGYtY29uZXgtbW9iaWxlLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQt aWV0Zi1jb25leC1tb2JpbGUuYWxsQGlldGYub3JnPg0K1vfM4jogUkU6IHNlY2RpciByZXZpZXcg b2YgZHJhZnQtaWV0Zi1jb25leC1tb2JpbGUtMDUNCg0KSGkgRnJhbmssDQoNCnRoYW5rcyBmb3Ig dGhlIHJldmlldy4NCg0KVGhlIHNlY3VyaXR5IGlzc3VlcyB5b3UgbWVudGlvbmVkIHdvdWxkIGFw cGx5IHRvIENvbkV4IGluIGdlbmVyYWwuIFRoZSBjb3JyZXNwb25kaW5nIGRvY3VtZW50cyBhcmUg ZGlzY3Vzc2luZyBwb3RlbnRpYWwgc2VjdXJpdHkgaXNzdWVzOg0KDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb25leC1hYnN0cmFjdC1tZWNoLTEzI3BhZ2UtMjQgKGFs c28gc2VlIHRoZSByZWZlcmVuY2VzKQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtY29uZXgtZGVzdG9wdC0wOSNwYWdlLTEwDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1jb25leC10Y3AtbW9kaWZpY2F0aW9ucy0wNCNwYWdlLTExDQoNCldloa9k IHRoZXJlZm9yZSByYXRoZXIgbm90IGR1cGxpY2F0ZSB0aGF0IGRpc2N1c3Npb24gaW4gY29uZXgt bW9iaWxlLg0KDQpSZWdhcmRpbmcgdGhlIHNlY3VyaXR5IHJpc2tzIHlvdSBtZW50aW9uZWQsIEmh r2Qgc2F5IGl0IGlzIHF1ZXN0aW9uYWJsZSB3aGV0aGVyIENvbkV4IGludHJvZHVjZXMgYWRkaXRp b25hbCBpc3N1ZXMgZm9yIGNvbmZpZGVudGlhbGl0eSAoY29tcGFyZWQgdG8gSVAgYWxvbmUpLg0K DQpUaGFua3MsDQpEaXJrDQoNCg0KDQpGcm9tOiBYaWFsaWFuZyAoRnJhbmspIFttYWlsdG86ZnJh bmsueGlhbGlhbmdAaHVhd2VpLmNvbV0NClNlbnQ6IEZyZWl0YWcsIDExLiBTZXB0ZW1iZXIgMjAx NSAwMjo0OQ0KVG86IHNlY2RpcjsgaWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz47 IGRyYWZ0LWlldGYtY29uZXgtbW9iaWxlLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1j b25leC1tb2JpbGUuYWxsQGlldGYub3JnPg0KU3ViamVjdDogc2VjZGlyIHJldmlldyBvZiBkcmFm dC1pZXRmLWNvbmV4LW1vYmlsZS0wNQ0KDQpIaSwNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3Vt ZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQg dG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cu ICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBv ZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBj aGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFz dCBjYWxsIGNvbW1lbnQuDQoNClRoaXMgbWVtbyBkZXNjcmliZXMgYSBtb2JpbGUgY29tbXVuaWNh dGlvbnMgdXNlIGNhc2UgZm9yIGNvbmdlc3Rpb24gZXhwb3N1cmUgKENvbkV4KSB3aXRoIGEgcGFy dGljdWxhciBmb2N1cyBvbiB0aG9zZSBtb2JpbGUgY29tbXVuaWNhdGlvbiBuZXR3b3JrcyB0aGF0 IGFyZSBhcmNoaXRlY3R1cmFsbHkgc2ltaWxhciB0byB0aGUgM0dQUCBFdm9sdmVkIFBhY2tldCBT eXN0ZW0gKEVQUykuDQoNCkkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0KDQpsICAxLiBJ dCBzaG91bGQgYmUgaGVscGZ1bCB0byBjb25zaWRlciB0aGUgY29tbXVuaWNhdGlvbiBzZWN1cml0 eSBiZXR3ZWVuIHRoZSBDb25FeCBzZW5kZXJzIGFuZCByZWNlaXZlcnMgc3VjaCBhcyB0aGUgQ29u ZmlkZW50aWFsaXR5LCBkYXRhIGludGVncml0eSBhbmQgcGVlciBlbnRpdHkgYXV0aGVudGljYXRp b24gaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHBhcnQuIEJlY2F1c2UgaW4gZ2VuZXJh bCwgdGhlIGNvcnJlc3BvbmRpbmcgcmlza3MgYXJlIHN0aWxsIHBvc3NpYmxlIHRvIGV4aXN0Lg0K DQpsICAyLiBUaGUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGFtb25nIGFsbCB0aGUgZWxlbWVu dHMgb2YgQ29uRXggc29sdXRpb24gc2hvdWxkIGFsc28gYmUgY29uc2lkZXJlZCB0byBoYW5kbGUg dGhlIGNvbmRpdGlvbiBvZiBmYWtlZCBtZXNzYWdlcyBvciBpbnZhbGlkIHBlZXIgZWxlbWVudHMu DQoNClJlY29tbWVuZGF0aW9uOiAgUmVhZHkgV2l0aCBJc3N1ZXMNCg0KQi5SLg0KRnJhbmsNCg0K --_000_82AB329A76E2484D934BBCA77E9F52499A07B50EHydraofficehd_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Frank,

 <= /p>

In general= , the ConEx-related risks regarding manipulating congestion notification/ex= posure can apply to mobile networks, too.

 = ;

What could= perhaps be said is that mobile networks (UMTS, LTE) employ a virtual-circu= it-like bearer model for the access, i.e., users in a cell can generally not see other users=A1=AF traffic =A8C so that would rule ou= t some threats. Also, authentication is part of the bearer establishment, s= o the network generally knows the user and device identity.

 = ;

Now, assum= ing that mobile networks can be subject to passive monitoring, one could cl= aim that this would enable attackers to collect information about a user=A1=AFs congestion contribution (also over time), but that thr= eat seems less critical (compared to exposing the payload itself).

 = ;

Best regar= ds,

Dirk<= /o:p>

 = ;

 

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Freitag, 11. September 2015 11:20
To: Dirk Kutscher
Cc: secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
Subject: Re: secdir review of draft-ietf-conex-mobile-05<= /span>

 

Hi Dirk,

Thank you = for quick response.

I reviewed= the drafts you mentioned below. I agree that they already discussed the ge= neral security issues I am concerned, especially in the draft-conex-abstrac= t-mech-13 and its reference.

 = ;

So, in gen= eral, my concerns are addressed. But I still have a little bit doubts about= possibly new security issues for the use cases of using ConEx protocol over the mobile communication networks. I am not an expert in thi= s area, can you clarify me?

 = ;

Thanks!

 = ;

B.R.<= /o:p>

Frank=

 = ;

=B7=A2=BC=FE=C8=CB: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu= ]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA9=D4=C211=C8=D5 16:52
=CA=D5=BC=FE=C8=CB: Xialiang (Frank); secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
=D6=F7=CC=E2: RE: secdir review of draft-ietf-conex-mobile-05

 

Hi Frank,<= o:p>

 = ;

thanks for= the review.

 = ;

The securi= ty issues you mentioned would apply to ConEx in general. The corresponding = documents are discussing potential security issues:

 = ;

htt= ps://tools.ietf.org/html/draft-ietf-conex-abstract-mech-13#page-24 (also see the references)

https://t= ools.ietf.org/html/draft-ietf-conex-destopt-09#page-10

https://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-04#page-11<= /a>

 = ;

We=A1=AFd = therefore rather not duplicate that discussion in conex-mobile.<= /span>

 = ;

Regarding = the security risks you mentioned, I=A1=AFd say it is questionable whether C= onEx introduces additional issues for confidentiality (compared to IP alone).

 = ;

Thanks,

Dirk<= /o:p>

 = ;

 = ;

 = ;

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Freitag, 11. September 2015 02:49
To: secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
Subject: secdir review of draft-ietf-conex-mobile-05

 

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 writ= ten primarily for the benefit of the security area directors.  Do= cument editors and WG chairs should treat these comments just like any= other last call comment.

 

This memo describes a mobile communicatio= ns use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally simi= lar to the 3GPP Evolved Packet System (EPS). 

 

I have the following comments:=

l  1. It should be = helpful to consider the communication security between the ConEx senders an= d receivers such as the Confidentiality, data integrity and peer entity authentication in the security considerations part. Becaus= e in general, the corresponding risks are still possible to exist.

l  2. The authentic= ation mechanism among all the elements of ConEx solution should also be con= sidered to handle the condition of faked messages or invalid peer elements.

 

Recommendation:  Ready With Issues

 

B.R.

Frank

 =

--_000_82AB329A76E2484D934BBCA77E9F52499A07B50EHydraofficehd_-- From nobody Sat Sep 12 12:59:58 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4B01B4B8A for ; Sat, 12 Sep 2015 12:59:55 -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, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 rMtI8M0iZZgs for ; Sat, 12 Sep 2015 12:59:53 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (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 814F21B4B83 for ; Sat, 12 Sep 2015 12:59:53 -0700 (PDT) Received: by qgez77 with SMTP id z77so88337606qge.1 for ; Sat, 12 Sep 2015 12:59:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=6+huL74/FqUxQw8oBn8snGm0W2OfRarP5rO/CGAiNMs=; b=dklU1l3EsYkA2RmF2iXTD0vW8gaPfPwfTxRT3OB9bVukZYoImXnu0ofPjlUefaCxvc jCEfBNyDAc2/4/e47b1qflkibE0/tzt7AZ8tdyVBNwH5YKf8c1Zjmok02ZCwHLntCkVj CJ0hkK6PDtoeJLPPPwf4rMtjeO0tlFP/ci+iB+w4HaAt4TEw2OPK2Pm1N04E9M0GEuMY R3nMp3C2HRIrmVh0r/1CfrbFhwyQE/0CpTURXxvToGRHo3WVvPUzH3hlx5+cLx+6bAv4 G+jy/yE8hGAwKJAl2NI9ScRKQ7JsL1o4yryJJ4n3RcBbYOzY1EXd7f4dfS7VvEKZ7nXT SLeg== X-Gm-Message-State: ALoCoQkeczLE6P22CczSKQxsx5d2rlGbtgtDxYPakckzLXfQL8HTGX2SXki7AkZTJreisnVqc8VD X-Received: by 10.140.218.133 with SMTP id o127mr9379285qhb.4.1442087992689; Sat, 12 Sep 2015 12:59:52 -0700 (PDT) Received: from [192.168.2.27] (pool-173-66-90-83.washdc.fios.verizon.net. [173.66.90.83]) by smtp.gmail.com with ESMTPSA id v34sm2613730qge.47.2015.09.12.12.59.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 12 Sep 2015 12:59:51 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.5.4.150722 Date: Sat, 12 Sep 2015 15:59:48 -0400 From: Carl Wallace To: Message-ID: Thread-Topic: draft-ietf-trill-pseudonode-nickname-06 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] draft-ietf-trill-pseudonode-nickname-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2015 19:59:55 -0000 I have reviewed this document as part of the security directorate=E2=80=99s 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. This document describes use of pseudo-nicknames for RBridges in an Active-Active Edge RBridge group. I am not familiar with TRILL but found the document to be well written and easy to follow. I did have one question, which may just be due to my lack of familiarity with relevant normative specs. The second paragraph of section 8 states the following: "However, for multi-destination TRILL Data packets, since they can reach all member RBridges of the new RBv and be egressed to CE1 by either RB2 or RB3 (i.e., the new DF for the traffic's Inner.VLAN or the VLAN the packet's Inner.Label maps to in the new RBv), special actions to protect against downlink failure for such multi-destination packets is not needed." =20 Why is there no race condition between the arrival of multi=E2=80=94destination traffic and the creation of a new RBv following the failure of RB1 that enables the traffic to be forwarded? Generally, mentioning failure of the DF for the virtual RBridge seemed like it might warrant mention in the security considerations section, since that is new relative to the specs noted in the current security considerations. From nobody Sun Sep 13 16:36:34 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA941B3BB7 for ; Sun, 13 Sep 2015 16:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 ryyJt84Yy-oR for ; Sun, 13 Sep 2015 16:36:31 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 20D741B3A80 for ; Sun, 13 Sep 2015 16:36:31 -0700 (PDT) Received: by lanb10 with SMTP id b10so76456562lan.3 for ; Sun, 13 Sep 2015 16:36:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=sdXX26OhtXuY7R3GKYQWyedEa6bZxL1lBAVNWTvpyek=; b=lHyHhBFte4bx277ek0Ah1Y9AXmbtfXy/8edZQn9ucH2LCQiilY9Gr0VoKTaAWNdAlN sPoLwRVY+WJG9wDfVPr2DOatNnJzAB6RN3bqLDzTwGckLwDjXQgYxhVTwPSQO/Ofyp0O lrlYd4gmBZk+2wdzef0LR2o5rI+DXU19tgFQmsBxoyFIaaBhWX7JqSBkjZG9lTt41aqH EDFTGX5JPa87fv6owH5lVZFxx9Fi4k3dWhhiNkppAJWTmP0ZGCs0hX1kPCvM8nBOaYNq e+oAxqFASDYvtpYHN5Lxi6Ded1JLrMauSTnhnYk7u2cYdeBdxh9aakS2QbaJnHHQ5QfC T0OA== X-Gm-Message-State: ALoCoQltSjCicYYzf5RTRCRSC1WoD5iJy9noRHsCEMk2hH3L0fdZ1BH82lMnc4u2YaFqlBvlPZ2Q MIME-Version: 1.0 X-Received: by 10.112.138.170 with SMTP id qr10mr10649334lbb.14.1442187389202; Sun, 13 Sep 2015 16:36:29 -0700 (PDT) Received: by 10.112.168.233 with HTTP; Sun, 13 Sep 2015 16:36:29 -0700 (PDT) Date: Sun, 13 Sep 2015 16:36:29 -0700 Message-ID: From: Joseph Salowey To: draft-josefsson-scrypt-kdf.all@tools.ietf.org, secdir , The IESG Content-Type: multipart/alternative; boundary=089e011610300888c8051fa96bd9 Archived-At: Subject: [secdir] Sector review of draft-josefsson-scrypt-kdf-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 23:36:33 -0000 --089e011610300888c8051fa96bd9 Content-Type: text/plain; charset=UTF-8 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 and document authors. I think this document is ready with issues. The document describes a password to key function, scrypt, based on memory hard functions to make it more expensive and difficult to develop specialized hardware to obtain the password from a recovered key. I'd like to see this document published. A few issues are listed below. First, I think Paul Kyzivat's GenArt review. http://mailarchive.ietf.org/arch/msg/gen-art/fToZiioHo-6x5ZRQWNcTr-aUYVk , raised some points that could help the readability of the document. Second, the script algorithm has several parameters, but the document has very little discussion on how to choose those parameters or what they affect (this is also pointed out in Paul's message). It would be good to have some discussion or guidance for parameter selection in the security considerations. Cheers, Joe --089e011610300888c8051fa96bd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dire= ctorate's ongoing effort to review all IETF documents being processed b= y the IESG.=C2=A0 These comments were written primarily for the benefit of = the security area directors and document authors.

I thin= k this document is ready with issues. =C2=A0 The document describes a passw= ord to key function, scrypt, based on memory hard functions to make it more= expensive and difficult to develop specialized hardware to obtain the pass= word from a recovered key.=C2=A0 I'd like to see this document publishe= d.=C2=A0 A few issues are listed below.=C2=A0

First, I = think Paul Kyzivat's GenArt review.=C2=A0http://mailarchive.= ietf.org/arch/msg/gen-art/fToZiioHo-6x5ZRQWNcTr-aUYVk,=C2=A0raised some= points that could help the readability of the document. =C2=A0

Second, the script algorithm has several parameters, but the docume= nt has very little discussion on how to choose those parameters or what the= y affect (this is also pointed out in Paul's message).=C2=A0 It would b= e good to have some discussion or guidance for parameter selection in the s= ecurity considerations. =C2=A0

Cheers,
<= br>
Joe
--089e011610300888c8051fa96bd9-- From nobody Sun Sep 13 17:08:07 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1A91B41E8; Sun, 13 Sep 2015 17:08:05 -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, SPF_PASS=-0.001] autolearn=ham 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 f1_9acn4_FaE; Sun, 13 Sep 2015 17:08:04 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 0A2D81B42A5; Sun, 13 Sep 2015 17:08:04 -0700 (PDT) Received: by obbbh8 with SMTP id bh8so96725049obb.0; Sun, 13 Sep 2015 17:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=nDaeZG1f4qEKH0W8VuBhL1nMA5zjDUiPgcI1KHMdFHQ=; b=gTXJJANsaktWFpkMcY6V+nkRdZcAShB3Yi4wjI4amS+gukAG79hNmMhXs+m7Zay3Gn TuBURr6W2prG8LWUT8vNDpDtaDgPYFy+CQHbKDuukjuaECKe9jUa+fsIp28CaYHpVw/K XCU6wtEM7hrDIQf2ddJ26ZN5k34VlDA5A3hPz7mN8siuVNgIDEKDlNNkFlkgKDPwnJU0 7bAIcSNKxaYR8JJFGjWdKoPY6cMnPw0VsCS32yQ3DYi2Wc+BoavvgMGqaz4xy7atSWnE rXPdP8Yeb77EMq+Bro8P4ArA5gdiChOCtilkZoJ1r3qhcBp+gPFX9L+wdqkWwLHPdYZ/ AoFg== MIME-Version: 1.0 X-Received: by 10.182.29.73 with SMTP id i9mr8612330obh.59.1442189283423; Sun, 13 Sep 2015 17:08:03 -0700 (PDT) Received: by 10.202.198.22 with HTTP; Sun, 13 Sep 2015 17:08:03 -0700 (PDT) Date: Sun, 13 Sep 2015 20:08:03 -0400 Message-ID: From: Matthew Lepinski To: "secdir@ietf.org" , "iesg@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2989eeffbcb051fa9db6a Archived-At: Cc: draft-ietf-dnsop-root-loopback.all@tools.ietf.org Subject: [secdir] SECDIR review of draft-ietf-dnsop-root-loopback-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 00:08:06 -0000 --001a11c2989eeffbcb051fa9db6a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate=E2=80=99s 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. This draft is essentially ready for publication (with minor comments below)= . This is an Informational document that specifies how the operator of a recursive resolver could run a copy of the root zone on a loopback interface. The purpose of this mechanism are two-fold: (1) to speed response time in the case of a negative response from the root zone; (2) to hide queries to the root zone from malicious observers. The security story for this mechanism is essentially: A) Since this mechanism must be run on a loopback interface, there is no possibility that the mechanism will negatively impact other entities. (I.e., it would be bad if a recursive resolver started giving authoritative answers for the root zone to anyone other than itself.) B) DNSSEC is used to ensure that the answers provided by this mechanism are valid. The security considerations section for this document is somewhat terse and I believe the document could be improved by expanding that section. In particular, I believe that point (A) above should be stated explicitly in the security considerations section. (That is, it is stated elsewhere in the document that using a loopback mechanism is essential. However, I think that repeating that in the security considerations section would be helpful -- I think that point is an important part of the story for why this mechanism doesn't break things.) Additionally, in the security considerations section, the authors are somewhat brief in describing the need for DNSSEC. I think that is fine, but given the brevity, I think it would be helpful to have a citation to another document that describes why DNSSEC is needed. (Is RFC 4033 the best reference regarding what DNSSEC protects against? Or is there a better document now?) - Matt Lepinski --001a11c2989eeffbcb051fa9db6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this docu= ment as part of the security directorate=E2=80=99s
ongoing effort to review all = IETF documents being processed by the IESG.
These comments were written primaril= y 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.

This draft is essentially ready for publication (wit= h minor comments below).
=
This is an Informati= onal document that specifies how the operator of a recursive resolver could= run a copy of the root zone on a loopback interface. The purpose of this m= echanism are two-fold: (1) to speed response time in the case of a negative= response from the root zone; (2) to hide queries to the root zone from mal= icious observers.=C2=A0
<= br>
The security story fo= r this mechanism is essentially:
A) Since this mechanism must be run on a loopback interface, there = is no=C2=A0possibility=C2=A0that the mechanism will negatively impact other= entities. (I.e., it would be bad if a recursive resolver started giving au= thoritative answers for the root zone to anyone other than itself.)<= /div>
B) DNSSEC is used to ensure that= the answers provided by this mechanism are valid.

The security considerations section for this document is somewhat ter= se and I believe the document could be improved by expanding that section. = In particular, I believe that point (A) above should be stated explicitly i= n the security considerations section. (That is, it is stated elsewhere in = the document that using a loopback mechanism is essential. However, I think= that repeating that in the security considerations section would be helpfu= l -- I think that point is an important part of the story for why this mech= anism doesn't break things.)

Additionally= , in the security considerations section, the authors are somewhat brief in= describing the need for DNSSEC. I think that is fine, but given the brevit= y, I think it would be helpful to have a citation to another document that = describes why DNSSEC is needed. (Is RFC 4033 the best reference regarding w= hat DNSSEC protects against? Or is there a better document now?)

- Matt Lepinski
--001a11c2989eeffbcb051fa9db6a-- From nobody Sun Sep 13 18:26:59 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA721B4EA7; Sun, 13 Sep 2015 18:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wludJRDoj8Df; Sun, 13 Sep 2015 18:26:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EBCD1B4DEB; Sun, 13 Sep 2015 18:26:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXO38302; Mon, 14 Sep 2015 01:26:47 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Sep 2015 02:26:45 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.77]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Mon, 14 Sep 2015 09:26:39 +0800 From: "Xialiang (Frank)" To: Dirk Kutscher Thread-Topic: secdir review of draft-ietf-conex-mobile-05 Thread-Index: AdDsK7I1VyJu7Bl6QJ2ZXX3RKt6srwAQblSwAAEGHKAAAMkDEACF6owQ Date: Mon, 14 Sep 2015 01:26:38 +0000 Message-ID: References: <82AB329A76E2484D934BBCA77E9F52499A07A349@Hydra.office.hd> <82AB329A76E2484D934BBCA77E9F52499A07B50E@Hydra.office.hd> In-Reply-To: <82AB329A76E2484D934BBCA77E9F52499A07B50E@Hydra.office.hd> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AE6C028SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-conex-mobile.all@ietf.org" , secdir Subject: Re: [secdir] secdir review of draft-ietf-conex-mobile-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 01:26:55 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12AE6C028SZXEMA502MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRGlyaywNCkkgc2VlLiBUaGFua3MgZm9yIHlvdXIgZGV0YWlsZWQgY2xhcmlmaWNhdGlvbi4N Cg0KQi5SLg0KRnJhbmsNCg0Kt6K8/sjLOiBEaXJrIEt1dHNjaGVyIFttYWlsdG86RGlyay5LdXRz Y2hlckBuZWNsYWIuZXVdDQq3osvNyrG85DogMjAxNcTqOdTCMTHI1SAxNzo0OQ0KytW8/sjLOiBY aWFsaWFuZyAoRnJhbmspDQqzrcvNOiBzZWNkaXI7IGllc2dAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt Y29uZXgtbW9iaWxlLmFsbEBpZXRmLm9yZw0K1vfM4jogUkU6IHNlY2RpciByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1jb25leC1tb2JpbGUtMDUNCg0KSGkgRnJhbmssDQoNCkluIGdlbmVyYWwsIHRoZSBD b25FeC1yZWxhdGVkIHJpc2tzIHJlZ2FyZGluZyBtYW5pcHVsYXRpbmcgY29uZ2VzdGlvbiBub3Rp ZmljYXRpb24vZXhwb3N1cmUgY2FuIGFwcGx5IHRvIG1vYmlsZSBuZXR3b3JrcywgdG9vLg0KDQpX aGF0IGNvdWxkIHBlcmhhcHMgYmUgc2FpZCBpcyB0aGF0IG1vYmlsZSBuZXR3b3JrcyAoVU1UUywg TFRFKSBlbXBsb3kgYSB2aXJ0dWFsLWNpcmN1aXQtbGlrZSBiZWFyZXIgbW9kZWwgZm9yIHRoZSBh Y2Nlc3MsIGkuZS4sIHVzZXJzIGluIGEgY2VsbCBjYW4gZ2VuZXJhbGx5IG5vdCBzZWUgb3RoZXIg dXNlcnOhryB0cmFmZmljIKhDIHNvIHRoYXQgd291bGQgcnVsZSBvdXQgc29tZSB0aHJlYXRzLiBB bHNvLCBhdXRoZW50aWNhdGlvbiBpcyBwYXJ0IG9mIHRoZSBiZWFyZXIgZXN0YWJsaXNobWVudCwg c28gdGhlIG5ldHdvcmsgZ2VuZXJhbGx5IGtub3dzIHRoZSB1c2VyIGFuZCBkZXZpY2UgaWRlbnRp dHkuDQoNCk5vdywgYXNzdW1pbmcgdGhhdCBtb2JpbGUgbmV0d29ya3MgY2FuIGJlIHN1YmplY3Qg dG8gcGFzc2l2ZSBtb25pdG9yaW5nLCBvbmUgY291bGQgY2xhaW0gdGhhdCB0aGlzIHdvdWxkIGVu YWJsZSBhdHRhY2tlcnMgdG8gY29sbGVjdCBpbmZvcm1hdGlvbiBhYm91dCBhIHVzZXKhr3MgY29u Z2VzdGlvbiBjb250cmlidXRpb24gKGFsc28gb3ZlciB0aW1lKSwgYnV0IHRoYXQgdGhyZWF0IHNl ZW1zIGxlc3MgY3JpdGljYWwgKGNvbXBhcmVkIHRvIGV4cG9zaW5nIHRoZSBwYXlsb2FkIGl0c2Vs ZikuDQoNCkJlc3QgcmVnYXJkcywNCkRpcmsNCg0KDQpGcm9tOiBYaWFsaWFuZyAoRnJhbmspIFtt YWlsdG86ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbV0NClNlbnQ6IEZyZWl0YWcsIDExLiBTZXB0 ZW1iZXIgMjAxNSAxMToyMA0KVG86IERpcmsgS3V0c2NoZXINCkNjOiBzZWNkaXI7IGllc2dAaWV0 Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWNvbmV4LW1vYmlsZS5hbGxA aWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY29uZXgtbW9iaWxlLmFsbEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29uZXgtbW9iaWxlLTA1DQoN CkhpIERpcmssDQpUaGFuayB5b3UgZm9yIHF1aWNrIHJlc3BvbnNlLg0KSSByZXZpZXdlZCB0aGUg ZHJhZnRzIHlvdSBtZW50aW9uZWQgYmVsb3cuIEkgYWdyZWUgdGhhdCB0aGV5IGFscmVhZHkgZGlz Y3Vzc2VkIHRoZSBnZW5lcmFsIHNlY3VyaXR5IGlzc3VlcyBJIGFtIGNvbmNlcm5lZCwgZXNwZWNp YWxseSBpbiB0aGUgZHJhZnQtY29uZXgtYWJzdHJhY3QtbWVjaC0xMyBhbmQgaXRzIHJlZmVyZW5j ZS4NCg0KU28sIGluIGdlbmVyYWwsIG15IGNvbmNlcm5zIGFyZSBhZGRyZXNzZWQuIEJ1dCBJIHN0 aWxsIGhhdmUgYSBsaXR0bGUgYml0IGRvdWJ0cyBhYm91dCBwb3NzaWJseSBuZXcgc2VjdXJpdHkg aXNzdWVzIGZvciB0aGUgdXNlIGNhc2VzIG9mIHVzaW5nIENvbkV4IHByb3RvY29sIG92ZXIgdGhl IG1vYmlsZSBjb21tdW5pY2F0aW9uIG5ldHdvcmtzLiBJIGFtIG5vdCBhbiBleHBlcnQgaW4gdGhp cyBhcmVhLCBjYW4geW91IGNsYXJpZnkgbWU/DQoNClRoYW5rcyENCg0KQi5SLg0KRnJhbmsNCg0K t6K8/sjLOiBEaXJrIEt1dHNjaGVyIFttYWlsdG86RGlyay5LdXRzY2hlckBuZWNsYWIuZXVdDQq3 osvNyrG85DogMjAxNcTqOdTCMTHI1SAxNjo1Mg0KytW8/sjLOiBYaWFsaWFuZyAoRnJhbmspOyBz ZWNkaXI7IGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWNv bmV4LW1vYmlsZS5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY29uZXgtbW9iaWxlLmFs bEBpZXRmLm9yZz4NCtb3zOI6IFJFOiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29uZXgt bW9iaWxlLTA1DQoNCkhpIEZyYW5rLA0KDQp0aGFua3MgZm9yIHRoZSByZXZpZXcuDQoNClRoZSBz ZWN1cml0eSBpc3N1ZXMgeW91IG1lbnRpb25lZCB3b3VsZCBhcHBseSB0byBDb25FeCBpbiBnZW5l cmFsLiBUaGUgY29ycmVzcG9uZGluZyBkb2N1bWVudHMgYXJlIGRpc2N1c3NpbmcgcG90ZW50aWFs IHNlY3VyaXR5IGlzc3VlczoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtY29uZXgtYWJzdHJhY3QtbWVjaC0xMyNwYWdlLTI0IChhbHNvIHNlZSB0aGUgcmVmZXJlbmNl cykNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvbmV4LWRlc3RvcHQt MDkjcGFnZS0xMA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29uZXgt dGNwLW1vZGlmaWNhdGlvbnMtMDQjcGFnZS0xMQ0KDQpXZaGvZCB0aGVyZWZvcmUgcmF0aGVyIG5v dCBkdXBsaWNhdGUgdGhhdCBkaXNjdXNzaW9uIGluIGNvbmV4LW1vYmlsZS4NCg0KUmVnYXJkaW5n IHRoZSBzZWN1cml0eSByaXNrcyB5b3UgbWVudGlvbmVkLCBJoa9kIHNheSBpdCBpcyBxdWVzdGlv bmFibGUgd2hldGhlciBDb25FeCBpbnRyb2R1Y2VzIGFkZGl0aW9uYWwgaXNzdWVzIGZvciBjb25m aWRlbnRpYWxpdHkgKGNvbXBhcmVkIHRvIElQIGFsb25lKS4NCg0KVGhhbmtzLA0KRGlyaw0KDQoN Cg0KRnJvbTogWGlhbGlhbmcgKEZyYW5rKSBbbWFpbHRvOmZyYW5rLnhpYWxpYW5nQGh1YXdlaS5j b21dDQpTZW50OiBGcmVpdGFnLCAxMS4gU2VwdGVtYmVyIDIwMTUgMDI6NDkNClRvOiBzZWNkaXI7 IGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWNvbmV4LW1v YmlsZS5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY29uZXgtbW9iaWxlLmFsbEBpZXRm Lm9yZz4NClN1YmplY3Q6IHNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb25leC1tb2JpbGUt MDUNCg0KSGksDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBz ZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBk b2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEg ZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0 aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50Lg0KDQpU aGlzIG1lbW8gZGVzY3JpYmVzIGEgbW9iaWxlIGNvbW11bmljYXRpb25zIHVzZSBjYXNlIGZvciBj b25nZXN0aW9uIGV4cG9zdXJlIChDb25FeCkgd2l0aCBhIHBhcnRpY3VsYXIgZm9jdXMgb24gdGhv c2UgbW9iaWxlIGNvbW11bmljYXRpb24gbmV0d29ya3MgdGhhdCBhcmUgYXJjaGl0ZWN0dXJhbGx5 IHNpbWlsYXIgdG8gdGhlIDNHUFAgRXZvbHZlZCBQYWNrZXQgU3lzdGVtIChFUFMpLg0KDQpJIGhh dmUgdGhlIGZvbGxvd2luZyBjb21tZW50czoNCg0KbCAgMS4gSXQgc2hvdWxkIGJlIGhlbHBmdWwg dG8gY29uc2lkZXIgdGhlIGNvbW11bmljYXRpb24gc2VjdXJpdHkgYmV0d2VlbiB0aGUgQ29uRXgg c2VuZGVycyBhbmQgcmVjZWl2ZXJzIHN1Y2ggYXMgdGhlIENvbmZpZGVudGlhbGl0eSwgZGF0YSBp bnRlZ3JpdHkgYW5kIHBlZXIgZW50aXR5IGF1dGhlbnRpY2F0aW9uIGluIHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBwYXJ0LiBCZWNhdXNlIGluIGdlbmVyYWwsIHRoZSBjb3JyZXNwb25kaW5n IHJpc2tzIGFyZSBzdGlsbCBwb3NzaWJsZSB0byBleGlzdC4NCg0KbCAgMi4gVGhlIGF1dGhlbnRp Y2F0aW9uIG1lY2hhbmlzbSBhbW9uZyBhbGwgdGhlIGVsZW1lbnRzIG9mIENvbkV4IHNvbHV0aW9u IHNob3VsZCBhbHNvIGJlIGNvbnNpZGVyZWQgdG8gaGFuZGxlIHRoZSBjb25kaXRpb24gb2YgZmFr ZWQgbWVzc2FnZXMgb3IgaW52YWxpZCBwZWVyIGVsZW1lbnRzLg0KDQpSZWNvbW1lbmRhdGlvbjog IFJlYWR5IFdpdGggSXNzdWVzDQoNCkIuUi4NCkZyYW5rDQoNCg== --_000_C02846B1344F344EB4FAA6FA7AF481F12AE6C028SZXEMA502MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Dirk,

I see. Tha= nks for your detailed clarification.

 = ;

B.R.<= /o:p>

Frank=

 = ;

=B7=A2=BC=FE=C8=CB: Dirk Ku= tscher [mailto:Dirk.Kutscher@neclab.eu]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA9=D4=C211=C8=D5 17:49
=CA=D5=BC=FE=C8=CB: Xialiang (Frank)
=B3=AD=CB=CD: secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
=D6=F7=CC=E2: RE: secdir review of draft-ietf-conex-mobile-05
<= /p>

 

Hi Frank,

 

In general= , the ConEx-related risks regarding manipulating congestion notification/ex= posure can apply to mobile networks, too.

 = ;

What could= perhaps be said is that mobile networks (UMTS, LTE) employ a virtual-circu= it-like bearer model for the access, i.e., users in a cell can generally not see other users=A1=AF traffic =A8C so that would rule ou= t some threats. Also, authentication is part of the bearer establishment, s= o the network generally knows the user and device identity.

 = ;

Now, assum= ing that mobile networks can be subject to passive monitoring, one could cl= aim that this would enable attackers to collect information about a user=A1=AFs congestion contribution (also over time), but that thr= eat seems less critical (compared to exposing the payload itself).

 = ;

Best regar= ds,

Dirk<= /o:p>

 = ;

 

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Freitag, 11. September 2015 11:20
To: Dirk Kutscher
Cc: secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
Subject: Re: secdir review of draft-ietf-conex-mobile-05<= /span>

 

Hi Dirk,

Thank you = for quick response.

I reviewed= the drafts you mentioned below. I agree that they already discussed the ge= neral security issues I am concerned, especially in the draft-conex-abstrac= t-mech-13 and its reference.

 = ;

So, in gen= eral, my concerns are addressed. But I still have a little bit doubts about= possibly new security issues for the use cases of using ConEx protocol over the mobile communication networks. I am not an expert in thi= s area, can you clarify me?

 = ;

Thanks!

 = ;

B.R.<= /o:p>

Frank=

 = ;

=B7=A2=BC=FE=C8=CB: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA9=D4=C211=C8=D5 16:52
=CA=D5= =BC=FE=C8=CB: Xialiang (Frank); secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
=D6=F7= =CC=E2: RE: secdir review of draft-ietf-conex-mobile-0= 5

 

Hi Frank,<= o:p>

 = ;

thanks for= the review.

 = ;

The securi= ty issues you mentioned would apply to ConEx in general. The corresponding = documents are discussing potential security issues:

 = ;

htt= ps://tools.ietf.org/html/draft-ietf-conex-abstract-mech-13#page-24 (also see the references)

https://t= ools.ietf.org/html/draft-ietf-conex-destopt-09#page-10

https://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-04#page-11<= /a>

 = ;

We=A1=AFd = therefore rather not duplicate that discussion in conex-mobile.<= /span>

 = ;

Regarding = the security risks you mentioned, I=A1=AFd say it is questionable whether C= onEx introduces additional issues for confidentiality (compared to IP alone).

 = ;

Thanks,

Dirk<= /o:p>

 = ;

 = ;

 = ;

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Freitag, 11. September 2015 02:49
To: secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
Subject: secdir review of draft-ietf-conex-mobile-05

 

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 writ= ten primarily for the benefit of the security area directors.  Do= cument editors and WG chairs should treat these comments just like any= other last call comment.

 

This memo describes a mobile communicatio= ns use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally simi= lar to the 3GPP Evolved Packet System (EPS). 

 

I have the following comments:=

l  1. It should be = helpful to consider the communication security between the ConEx senders an= d receivers such as the Confidentiality, data integrity and peer entity authentication in the security considerations part. Becaus= e in general, the corresponding risks are still possible to exist.

l  2. The authentic= ation mechanism among all the elements of ConEx solution should also be con= sidered to handle the condition of faked messages or invalid peer elements.

 

Recommendation:  Ready With Issues

 

B.R.

Frank

 =

--_000_C02846B1344F344EB4FAA6FA7AF481F12AE6C028SZXEMA502MBSchi_-- From nobody Mon Sep 14 03:19:32 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E061B53F8 for ; Mon, 14 Sep 2015 03:19:31 -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, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 GKeFm-efWx_y for ; Mon, 14 Sep 2015 03:19:30 -0700 (PDT) Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) (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 09D2E1B545F for ; Mon, 14 Sep 2015 03:19:29 -0700 (PDT) Received: by qkcf65 with SMTP id f65so55866773qkc.3 for ; Mon, 14 Sep 2015 03:19:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=T6/Dwf11bOSBwh6QP54xCNkf+Tw32gSCtw+D8QPP0hM=; b=Dk8xfgu4xGfmUKRcbokyqCK5aVHDCWunYk6OdPJFzRJF1a2OrCqEasdZsQPQRITMkd nJZYqiXCMddMGoYX4xHzCtWC+vPB35xAql0mAWt7iLUaYHcu/hgWAXSPxzzz1lBx84MZ xPKNWPURecdKv6RMazE0g5kEiZkav+GBGWdSkAzvOcNm+SCX1k/uR4mEBUbskdzsHlMV cTSCZUcgVpjaSe0pvgTCQCcZDk2Kx/c4FLxf6q1868RV2zapQy3Ia2/p45TB+1ynsDAQ 2sOobqSMOB5cyk9U98hJG6P9uw6Ff2BmJxUZQBuxUUtoV8dU/O3Mfo8/qwSlgqX02IPK UTdw== X-Gm-Message-State: ALoCoQkhzcBvHXW1YWmKdZK1IoT6Rf6H1c6gSnvBqVewirkFuS8y9ev50gwqFcYTGxlpTKr5eHz/ X-Received: by 10.55.221.8 with SMTP id n8mr20533267qki.85.1442225968170; Mon, 14 Sep 2015 03:19:28 -0700 (PDT) Received: from [192.168.2.27] (pool-173-66-90-83.washdc.fios.verizon.net. [173.66.90.83]) by smtp.gmail.com with ESMTPSA id 88sm5614103qkr.5.2015.09.14.03.19.20 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 14 Sep 2015 03:19:27 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.5.4.150722 Date: Mon, 14 Sep 2015 06:19:14 -0400 From: Carl Wallace To: Mingui Zhang , "draft-ietf-trill-pseudonode-nickname.all@tools.ietf.org" Message-ID: Thread-Topic: draft-ietf-trill-pseudonode-nickname-06 References: <4552F0907735844E9204A62BBDD325E7871BB1E4@nkgeml512-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E7871BB1E4@nkgeml512-mbx.china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-trill-pseudonode-nickname-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 10:19:31 -0000 On 9/13/15, 11:51 PM, "Mingui Zhang" wrote: >Hi Carl, > >Thanks for the comment. > >If the DF fails, the failure will be noted by other member RBridge >through LSDB sync. Then the DF election algorithm defined in Section 5.2 >will be locally used to determine who is the new DF. >In the transient condition when LSDB has not been sync-ed, there might be >packet lost but there is no racing Sorry, =E2=80=98race condition=E2=80=99 may not have been the best term to use here. >: suppose, RB1 is the old DF before the failure while RB2 is the new DF >after RB1 fails according to the election algorithm. If RB2 has been >sync-ed while RB3 is not, then RB2 will begin to do forwarding; If RB3 is >sync-ed while RB2 is not, then no member RBridge will do the forwarding. That there could be a lost packet (or traffic disruption as mentioned elsewhere) was what I was getting at. The language in the first paragraph of section 8 indicated unicast could have trouble but as I read it the second paragraph intimated that multicast could not. It wasn=E2=80=99t clear to m= e that was true and it sounds like it isn=E2=80=99t true for all cases (but is true after a new DF has been elected). Re-reading it now it is clear the point is that no =E2=80=98special actions=E2=80=99 ar= e required not that there can be no lost packet. It might be more clear if it stated acknowledged the hang time between failure and full establishment of the new RBv following the failure. >=20 > >Thanks, >Mingui > >> -----Original Message----- >> From: Carl Wallace [mailto:carl@redhoundsoftware.com] >> Sent: Sunday, September 13, 2015 4:00 AM >> To: draft-ietf-trill-pseudonode-nickname.all@tools.ietf.org >> Cc: iesg@ietf.org; secdir@ietf.org >> Subject: draft-ietf-trill-pseudonode-nickname-06 >>=20 >> I have reviewed this document as part of the security directorate=E2=80=99s >>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 >> This document describes use of pseudo-nicknames for RBridges in an >> Active-Active Edge RBridge group. I am not familiar with TRILL but >>found the >> document to be well written and easy to follow. I did have one >>question, which >> may just be due to my lack of familiarity with relevant normative >>specs. The >> second paragraph of section 8 states the following: >>=20 >> "However, for multi-destination TRILL Data packets, since they can >>reach >> all member RBridges of the new RBv and be egressed to CE1 by either RB2 >>or >> RB3 (i.e., the new DF for the traffic's Inner.VLAN or the VLAN the >>packet's >> Inner.Label maps to in the new RBv), special actions to protect against >> downlink failure for such multi-destination packets is not >> needed." >>=20 >> Why is there no race condition between the arrival of multi=E2=80=94destinatio= n >>traffic >> and the creation of a new RBv following the failure of RB1 that enables >>the >> traffic to be forwarded? Generally, mentioning failure of the DF for >>the virtual >> RBridge seemed like it might warrant mention in the security >>considerations >> section, since that is new relative to the specs noted in the current >>security >> considerations. >>=20 > From nobody Mon Sep 14 08:03:53 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E516F1B5A8F; Sun, 13 Sep 2015 20:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 NHAOVBrtpsKa; Sun, 13 Sep 2015 20:52:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1763D1B5A85; Sun, 13 Sep 2015 20:52:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXO46959; Mon, 14 Sep 2015 03:52:07 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Sep 2015 04:52:04 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.166]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Mon, 14 Sep 2015 11:51:59 +0800 From: Mingui Zhang To: Carl Wallace , "draft-ietf-trill-pseudonode-nickname.all@tools.ietf.org" Thread-Topic: draft-ietf-trill-pseudonode-nickname-06 Thread-Index: AQHQ7ZWmwM2br1fzd0eZlb8TxXO1+547X/TQ Date: Mon, 14 Sep 2015 03:51:58 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7871BB1E4@nkgeml512-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Mon, 14 Sep 2015 08:03:52 -0700 Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-trill-pseudonode-nickname-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 03:52:13 -0000 SGkgQ2FybCwNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudC4NCg0KSWYgdGhlIERGIGZhaWxzLCB0 aGUgZmFpbHVyZSB3aWxsIGJlIG5vdGVkIGJ5IG90aGVyIG1lbWJlciBSQnJpZGdlIHRocm91Z2gg TFNEQiBzeW5jLiBUaGVuIHRoZSBERiBlbGVjdGlvbiBhbGdvcml0aG0gZGVmaW5lZCBpbiBTZWN0 aW9uIDUuMiB3aWxsIGJlIGxvY2FsbHkgdXNlZCB0byBkZXRlcm1pbmUgd2hvIGlzIHRoZSBuZXcg REYuIA0KSW4gdGhlIHRyYW5zaWVudCBjb25kaXRpb24gd2hlbiBMU0RCIGhhcyBub3QgYmVlbiBz eW5jLWVkLCB0aGVyZSBtaWdodCBiZSBwYWNrZXQgbG9zdCBidXQgdGhlcmUgaXMgbm8gcmFjaW5n OiBzdXBwb3NlLCBSQjEgaXMgdGhlIG9sZCBERiBiZWZvcmUgdGhlIGZhaWx1cmUgd2hpbGUgUkIy IGlzIHRoZSBuZXcgREYgYWZ0ZXIgUkIxIGZhaWxzIGFjY29yZGluZyB0byB0aGUgZWxlY3Rpb24g YWxnb3JpdGhtLiBJZiBSQjIgaGFzIGJlZW4gc3luYy1lZCB3aGlsZSBSQjMgaXMgbm90LCB0aGVu IFJCMiB3aWxsIGJlZ2luIHRvIGRvIGZvcndhcmRpbmc7IElmIFJCMyBpcyBzeW5jLWVkIHdoaWxl IFJCMiBpcyBub3QsIHRoZW4gbm8gbWVtYmVyIFJCcmlkZ2Ugd2lsbCBkbyB0aGUgZm9yd2FyZGlu Zy4gDQoNClRoYW5rcywNCk1pbmd1aQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IENhcmwgV2FsbGFjZSBbbWFpbHRvOmNhcmxAcmVkaG91bmRzb2Z0d2FyZS5jb21dDQo+ IFNlbnQ6IFN1bmRheSwgU2VwdGVtYmVyIDEzLCAyMDE1IDQ6MDAgQU0NCj4gVG86IGRyYWZ0LWll dGYtdHJpbGwtcHNldWRvbm9kZS1uaWNrbmFtZS5hbGxAdG9vbHMuaWV0Zi5vcmcNCj4gQ2M6IGll c2dAaWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9yZw0KPiBTdWJqZWN0OiBkcmFmdC1pZXRmLXRyaWxs LXBzZXVkb25vZGUtbmlja25hbWUtMDYNCj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3Vt ZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRl4oCZcyBvbmdvaW5nDQo+IGVm Zm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUg SUVTRy4NCj4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJl bmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWENCj4gZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9y cyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cw0KPiBqdXN0IGxpa2Ug YW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gDQo+IFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHVzZSBvZiBwc2V1ZG8tbmlja25hbWVzIGZvciBSQnJpZGdlcyBpbiBhbg0KPiBBY3RpdmUt QWN0aXZlIEVkZ2UgUkJyaWRnZSBncm91cC4gSSBhbSBub3QgZmFtaWxpYXIgd2l0aCBUUklMTCBi dXQgZm91bmQgdGhlDQo+IGRvY3VtZW50IHRvIGJlIHdlbGwgd3JpdHRlbiBhbmQgZWFzeSB0byBm b2xsb3cuIEkgZGlkIGhhdmUgb25lIHF1ZXN0aW9uLCB3aGljaA0KPiBtYXkganVzdCBiZSBkdWUg dG8gbXkgbGFjayBvZiBmYW1pbGlhcml0eSB3aXRoIHJlbGV2YW50IG5vcm1hdGl2ZSBzcGVjcy4g VGhlDQo+IHNlY29uZCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA4IHN0YXRlcyB0aGUgZm9sbG93aW5n Og0KPiANCj4gCSJIb3dldmVyLCBmb3IgbXVsdGktZGVzdGluYXRpb24gVFJJTEwgRGF0YSBwYWNr ZXRzLCBzaW5jZSB0aGV5IGNhbiByZWFjaA0KPiBhbGwgbWVtYmVyIFJCcmlkZ2VzIG9mIHRoZSBu ZXcgUkJ2IGFuZCBiZSBlZ3Jlc3NlZCB0byBDRTEgYnkgZWl0aGVyIFJCMiBvcg0KPiBSQjMgKGku ZS4sIHRoZSBuZXcgREYgZm9yIHRoZSB0cmFmZmljJ3MgSW5uZXIuVkxBTiBvciB0aGUgVkxBTiB0 aGUgcGFja2V0J3MNCj4gSW5uZXIuTGFiZWwgbWFwcyB0byBpbiB0aGUgbmV3IFJCdiksIHNwZWNp YWwgYWN0aW9ucyB0byBwcm90ZWN0IGFnYWluc3QNCj4gZG93bmxpbmsgZmFpbHVyZSBmb3Igc3Vj aCBtdWx0aS1kZXN0aW5hdGlvbiBwYWNrZXRzIGlzIG5vdA0KPiBuZWVkZWQuIg0KPiANCj4gV2h5 IGlzIHRoZXJlIG5vIHJhY2UgY29uZGl0aW9uIGJldHdlZW4gdGhlIGFycml2YWwgb2YgbXVsdGni gJRkZXN0aW5hdGlvbiB0cmFmZmljDQo+IGFuZCB0aGUgY3JlYXRpb24gb2YgYSBuZXcgUkJ2IGZv bGxvd2luZyB0aGUgZmFpbHVyZSBvZiBSQjEgdGhhdCBlbmFibGVzIHRoZQ0KPiB0cmFmZmljIHRv IGJlIGZvcndhcmRlZD8gR2VuZXJhbGx5LCBtZW50aW9uaW5nIGZhaWx1cmUgb2YgdGhlIERGIGZv ciB0aGUgdmlydHVhbA0KPiBSQnJpZGdlIHNlZW1lZCBsaWtlIGl0IG1pZ2h0IHdhcnJhbnQgbWVu dGlvbiBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCj4gc2VjdGlvbiwgc2luY2UgdGhh dCBpcyBuZXcgcmVsYXRpdmUgdG8gdGhlIHNwZWNzIG5vdGVkIGluIHRoZSBjdXJyZW50IHNlY3Vy aXR5DQo+IGNvbnNpZGVyYXRpb25zLg0KPiANCg0K From nobody Mon Sep 14 08:18:02 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8732C1B54BB; Mon, 14 Sep 2015 08:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553] autolearn=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 b3Fq8h_PSU-G; Mon, 14 Sep 2015 08:17:59 -0700 (PDT) Received: from hoffman.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 B59541B4358; Mon, 14 Sep 2015 08:17:59 -0700 (PDT) Received: from [10.32.60.144] (142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8EFHv8w079126 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2015 08:17:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123] claimed to be [10.32.60.144] From: "Paul Hoffman" To: "Matthew Lepinski" Date: Mon, 14 Sep 2015 08:17:56 -0700 Message-ID: <138F09FC-109C-410E-ACA7-2DADF3D4460D@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: draft-ietf-dnsop-root-loopback.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-dnsop-root-loopback-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 15:18:00 -0000 Thanks! We have made these changes in the pre-draft of -04. If the ADs want us to publish this before the IESG review, we can; otherwise, we'll wait until after the IESG review to release them. --Paul Hoffman A system that does not follow the DNSSEC-related requirements given in can be fooled into giving bad responses in the same way as any recursive resolver that does not do DNSSEC validation on responses from a remote root server. Anyone deploying the method described in this document should be familiar with the operational benefits and costs of deploying DNSSEC . As stated in , this design explicitly only allows the new root zone server to be run on a loopback address, in order to prevent the server from serving authoritative answers to any system other than the recursive resolver. This has the security property of limiting damage to any other system that might try to rely on the copy of the root in case that copy becomes altered. From nobody Mon Sep 14 09:55:00 2015 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 DF9201B2A1C; Mon, 14 Sep 2015 09:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1442249010; bh=Wfi1ILYDpD9ZF2b8ydFiKTv7WkL1yonIdOhcE/MAEH4=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=JcXVUMWO4EXmaapkXJ4iqf6L7u6b5B82rZRonrIZpy7nXk99BpyFrISkUVBazu5v+ yjxNKE2warylcuIOn9vXjg+m5LHnoGeEcUmb3uxcb/7t22Kx9Eu/2WrujuZbxZe7u8 9hZHNoJ6PTqyYGCc8F/Rdwpr2dLU3vOYsMcFRGzo= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91ED1B2A1C; Mon, 14 Sep 2015 09:43:29 -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 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 F0MNdlDrn3L0; Mon, 14 Sep 2015 09:43:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E90931B2A6B; Mon, 14 Sep 2015 09:43:23 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150914164323.31029.94918.idtracker@ietfa.amsl.com> Date: Mon, 14 Sep 2015 09:43:23 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Sep 2015 09:55:00 -0700 Subject: [secdir] [new-work] WG Review: Geographic JSON (geojson) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 16:43:31 -0000 A new IETF working group has been proposed in the Applications and Real-Time 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 at ietf.org) by 2015-09-24. Geographic JSON (geojson) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Alissa Cooper Charter: GeoJSON is a format for encoding data about geographic features using JavaScript Object Notation (JSON) [RFC7159]. Geographic features need not be physical things; any thing with properties that are bounded in space may be considered a feature. GeoJSON provides a means of representing both the properties and spatial extent of features. The GeoJSON format specification was published at http://geojson.org in 2008. GeoJSON today plays an important and growing role in many spatial databases, web APIs, and open data platforms. Consequently the implementers increasingly demand formal standardization, improvements in the specification, guidance on extensibility, and the means to utilize larger GeoJSON datasets. This WG will work on a GeoJSON Format RFC that specifies the format more precisely, serves as a better guide for implementers, and improves extensibility of the format. The work will start from an Internet-Draft written by the original GeoJSON authors: draft-butler-geojson [1]. This WG will work on GeoJSON mappings of 'geo' URIs, reinforcing the use of RFC 5870. This WG will work on a format for a streamable sequence of GeoJSON texts based on RFC 7464 to address the difficulties in serializing very large sequences of features or feature sequences of indeterminate length. GeoJSON objects represent geographic features only and do not specify associations between geographic features and particular devices, users, or facilities. Any association with a particular device, user, or facility requires another protocol. When a GeoJSON object is used in a context where it identifies the location of a device, user, or facility, it becomes subject to the architectural, security, and privacy considerations in RFC 6280. The application of those considerations is specific to protocols that make use of GeoJSON objects and is out of scope for the GeoJSON WG. Although the WG is chartered to improve the extensibility of the format, extensions that would allow GeoJSON objects to specify associations between geographic features and particular devices, users, or facilities are not expected to be defined in the WG. Should that be needed, re-chartering will be required. Deliverables: * A GeoJSON format specification document including mappings of 'geo' URIs * A document describing a format for a streamable sequence of GeoJSON texts [1] https://tools.ietf.org/html/draft-butler-geojson Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Sep 14 10:44:58 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36211B2EC5; Mon, 14 Sep 2015 10:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jt2qx5q9UGvS; Mon, 14 Sep 2015 10:44:56 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 8CF981B3A90; Mon, 14 Sep 2015 10:44:56 -0700 (PDT) Received: from mb.local ([156.39.136.139]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t8EHiqKv058169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Sep 2015 17:44:53 GMT (envelope-from joelja@bogus.com) To: Paul Hoffman , Matthew Lepinski References: <138F09FC-109C-410E-ACA7-2DADF3D4460D@vpnc.org> From: joel jaeggli Message-ID: <55F7078E.2070802@bogus.com> Date: Mon, 14 Sep 2015 10:44:46 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: <138F09FC-109C-410E-ACA7-2DADF3D4460D@vpnc.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OtT1oKHMOlSUPLsiCNVxbwbe8B7HB02nT" Archived-At: Cc: draft-ietf-dnsop-root-loopback.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-dnsop-root-loopback-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 17:44:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OtT1oKHMOlSUPLsiCNVxbwbe8B7HB02nT Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/14/15 8:17 AM, Paul Hoffman wrote: > Thanks! We have made these changes in the pre-draft of -04. If the ADs > want us to publish this before the IESG review, we can; otherwise, we'l= l > wait until after the IESG review to release them. It's fine by me if you do that. no reason not to be dicsussing the latest version so long as we have a few days between the update and the review call. thanks joel > --Paul Hoffman >=20 > A system that does not follow the DNSSEC-related requirements > given > in can be fooled into giving bad response= s > in the > same way as any recursive resolver that does not do DNSSEC > validation on > responses from a remote root server. Anyone deploying the method > described in this document should be familiar with the operationa= l > benefits > and costs of deploying DNSSEC . >=20 > As stated in , this design explicitly > only allows > the new root zone server to be run on a loopback address, in orde= r to > prevent the server from serving authoritative answers to any > system other > than the recursive resolver. This has the security property of > limiting > damage to any other system that might try to rely on the copy of > the root > in case that copy becomes altered. >=20 --OtT1oKHMOlSUPLsiCNVxbwbe8B7HB02nT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlX3B48ACgkQ8AA1q7Z/VrJr+ACfbX3ccdFwIHNxGSaudUDRZBgy Y0gAn2+wOrzKrT1+gdiZlu8w3+OhMZie =gvUC -----END PGP SIGNATURE----- --OtT1oKHMOlSUPLsiCNVxbwbe8B7HB02nT-- From nobody Mon Sep 14 10:46:25 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F721B3D0A; Mon, 14 Sep 2015 10:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 JrfDdHAMcaSa; Mon, 14 Sep 2015 10:46:20 -0700 (PDT) Received: from hoffman.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 9B9C51B3BF8; Mon, 14 Sep 2015 10:46:20 -0700 (PDT) Received: from [10.32.60.144] (142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8EHkDnt088134 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2015 10:46:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123] claimed to be [10.32.60.144] From: "Paul Hoffman" To: "joel jaeggli" Date: Mon, 14 Sep 2015 10:46:13 -0700 Message-ID: In-Reply-To: <55F7078E.2070802@bogus.com> References: <138F09FC-109C-410E-ACA7-2DADF3D4460D@vpnc.org> <55F7078E.2070802@bogus.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "iesg@ietf.org" , draft-ietf-dnsop-root-loopback.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-dnsop-root-loopback-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 17:46:21 -0000 On 14 Sep 2015, at 10:44, joel jaeggli wrote: > On 9/14/15 8:17 AM, Paul Hoffman wrote: >> Thanks! We have made these changes in the pre-draft of -04. If the ADs >> want us to publish this before the IESG review, we can; otherwise, we'll >> wait until after the IESG review to release them. > > > It's fine by me if you do that. no reason not to be dicsussing the > latest version so long as we have a few days between the update and the > review call. OK, we'll do a new rev soon then. --Paul Hoffman From nobody Mon Sep 14 15:23:03 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551E51A87A6 for ; Mon, 14 Sep 2015 15:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 WL408SlWygQr for ; Mon, 14 Sep 2015 15:22:58 -0700 (PDT) Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) (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 B0DED1B2E45 for ; Mon, 14 Sep 2015 15:22:56 -0700 (PDT) Received: by ykdg206 with SMTP id g206so167437701ykd.1 for ; Mon, 14 Sep 2015 15:22:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cv/PysJo2CME3tlo2w/aM9hJEsTsXnwnTSb/9ijeH8g=; b=EUyCrlxEmaSgoh75PNYw8/bJpDG5G1YSddhnjKaLZsLvkE04HYQ4UluHBcarGWnK/0 JinOjczEmtRJ6D2umz+gAYPjjmkzRN8g/JHLnpyUUFWJAzxHb06gBiYWWFiXhp1UTN+T QEwlJi0+ABH82GWs7E7rJZ34Ki0sDMRUVNObSQ4pRzMR91onPbOKRGNhVr6sHuV9INuz GuNgGNxebozJjq49aYPYoatr7BV+Z8C2J3CY1DTq2E1s41csUbCM7RIiftF+zCkUXkIe EZ6FARCPO8xoM2cUIhKDasIzHZk7RxVDAWfTjMOhzujQk5QOhc7eByimZZgvTqN80ZDt 65hw== X-Gm-Message-State: ALoCoQldx/CD1isGGcoSg5TsADAYYwlwUMCi/aWmSx9hwCgY2w9CiKPhjLlqd62gaE1bJA9SOcHD MIME-Version: 1.0 X-Received: by 10.129.124.8 with SMTP id x8mr17111642ywc.44.1442269375888; Mon, 14 Sep 2015 15:22:55 -0700 (PDT) Received: by 10.37.52.135 with HTTP; Mon, 14 Sep 2015 15:22:55 -0700 (PDT) In-Reply-To: References: <138F09FC-109C-410E-ACA7-2DADF3D4460D@vpnc.org> <55F7078E.2070802@bogus.com> Date: Mon, 14 Sep 2015 18:22:55 -0400 Message-ID: From: Warren Kumari To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11493a2cd23677051fbc81cf Archived-At: Cc: joel jaeggli , "draft-ietf-dnsop-root-loopback.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-dnsop-root-loopback-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 22:22:59 -0000 --001a11493a2cd23677051fbc81cf Content-Type: text/plain; charset=UTF-8 Thank you Paul for taking care of this... W On Monday, September 14, 2015, Paul Hoffman wrote: > On 14 Sep 2015, at 10:44, joel jaeggli wrote: > > > On 9/14/15 8:17 AM, Paul Hoffman wrote: > >> Thanks! We have made these changes in the pre-draft of -04. If the ADs > >> want us to publish this before the IESG review, we can; otherwise, we'll > >> wait until after the IESG review to release them. > > > > > > It's fine by me if you do that. no reason not to be dicsussing the > > latest version so long as we have a few days between the update and the > > review call. > > OK, we'll do a new rev soon then. > > --Paul Hoffman > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --001a11493a2cd23677051fbc81cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you Paul for taking care of this...

W=

On Monday, September 14, 2015, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 14 Sep 2015, at 10:44, joel jaeggli wrote:

> On 9/14/15 8:17 AM, Paul Hoffman wrote:
>> Thanks! We have made these changes in the pre-draft of -04. If the= ADs
>> want us to publish this before the IESG review, we can; otherwise,= we'll
>> wait until after the IESG review to release them.
>
>
> It's fine by me if you do that. no reason not to be dicsussing the=
> latest version so long as we have a few days between the update and th= e
> review call.

OK, we'll do a new rev soon then.

--Paul Hoffman

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


--
I don't think the execution is releva= nt when it was obviously a bad idea in the first place.
This is like put= ting rabid weasels in your pants, and later expressing regret at having cho= sen those particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0= ---maf
--001a11493a2cd23677051fbc81cf-- From nobody Mon Sep 14 18:15:39 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FE01ACE04; Mon, 14 Sep 2015 18:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 effumwVwip3G; Mon, 14 Sep 2015 18:15:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22AEE1A86F6; Mon, 14 Sep 2015 18:15:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBG92308; Tue, 15 Sep 2015 01:15:27 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 15 Sep 2015 02:15:24 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.166]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Tue, 15 Sep 2015 09:15:20 +0800 From: Mingui Zhang To: Carl Wallace , "draft-ietf-trill-pseudonode-nickname.all@tools.ietf.org" Thread-Topic: draft-ietf-trill-pseudonode-nickname-06 Thread-Index: AQHQ7ZWmwM2br1fzd0eZlb8TxXO1+547X/TQ///sYACAAX0hQA== Date: Tue, 15 Sep 2015 01:15:19 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7871CA6AF@nkgeml512-mbx.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E7871BB1E4@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-trill-pseudonode-nickname-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 01:15:35 -0000 SGkgQ2FybCwNCg0KSSBhZ3JlZSB0aGF0IGl0IGlzIG1vcmUgY2xlYXIgaWYgdGhlIHRyYW5zaWVu dCBjb25kaXRpb24gaXMgZXhwbGljaXRseSBzdGF0ZSBpbiB0aGUgdGV4dCBvZiBwYXJhZ3JhcGgg Mi4gVGhhdCB3aWxsIGJlIGRvbmUgYmVmb3JlIGl0IGlzIHB1Ymxpc2hlZC4NCg0KVGhhbmtzLA0K TWluZ3VpDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ2FybCBXYWxs YWNlIFttYWlsdG86Y2FybEByZWRob3VuZHNvZnR3YXJlLmNvbV0NCj4gU2VudDogTW9uZGF5LCBT ZXB0ZW1iZXIgMTQsIDIwMTUgNjoxOSBQTQ0KPiBUbzogTWluZ3VpIFpoYW5nOyBkcmFmdC1pZXRm LXRyaWxsLXBzZXVkb25vZGUtbmlja25hbWUuYWxsQHRvb2xzLmlldGYub3JnDQo+IENjOiBpZXNn QGlldGYub3JnOyBzZWNkaXJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IGRyYWZ0LWlldGYtdHJp bGwtcHNldWRvbm9kZS1uaWNrbmFtZS0wNg0KPiANCj4gDQo+IA0KPiBPbiA5LzEzLzE1LCAxMTo1 MSBQTSwgIk1pbmd1aSBaaGFuZyIgPHpoYW5nbWluZ3VpQGh1YXdlaS5jb20+IHdyb3RlOg0KPiAN Cj4gPkhpIENhcmwsDQo+ID4NCj4gPlRoYW5rcyBmb3IgdGhlIGNvbW1lbnQuDQo+ID4NCj4gPklm IHRoZSBERiBmYWlscywgdGhlIGZhaWx1cmUgd2lsbCBiZSBub3RlZCBieSBvdGhlciBtZW1iZXIg UkJyaWRnZQ0KPiA+dGhyb3VnaCBMU0RCIHN5bmMuIFRoZW4gdGhlIERGIGVsZWN0aW9uIGFsZ29y aXRobSBkZWZpbmVkIGluIFNlY3Rpb24NCj4gPjUuMiB3aWxsIGJlIGxvY2FsbHkgdXNlZCB0byBk ZXRlcm1pbmUgd2hvIGlzIHRoZSBuZXcgREYuDQo+ID5JbiB0aGUgdHJhbnNpZW50IGNvbmRpdGlv biB3aGVuIExTREIgaGFzIG5vdCBiZWVuIHN5bmMtZWQsIHRoZXJlIG1pZ2h0DQo+ID5iZSBwYWNr ZXQgbG9zdCBidXQgdGhlcmUgaXMgbm8gcmFjaW5nDQo+IA0KPiBTb3JyeSwg4oCYcmFjZSBjb25k aXRpb27igJkgbWF5IG5vdCBoYXZlIGJlZW4gdGhlIGJlc3QgdGVybSB0byB1c2UgaGVyZS4NCj4g DQo+ID46IHN1cHBvc2UsIFJCMSBpcyB0aGUgb2xkIERGIGJlZm9yZSB0aGUgZmFpbHVyZSB3aGls ZSBSQjIgaXMgdGhlIG5ldyBERg0KPiA+YWZ0ZXIgUkIxIGZhaWxzIGFjY29yZGluZyB0byB0aGUg ZWxlY3Rpb24gYWxnb3JpdGhtLiBJZiBSQjIgaGFzIGJlZW4NCj4gPnN5bmMtZWQgd2hpbGUgUkIz IGlzIG5vdCwgdGhlbiBSQjIgd2lsbCBiZWdpbiB0byBkbyBmb3J3YXJkaW5nOyBJZiBSQjMNCj4g PmlzIHN5bmMtZWQgd2hpbGUgUkIyIGlzIG5vdCwgdGhlbiBubyBtZW1iZXIgUkJyaWRnZSB3aWxs IGRvIHRoZSBmb3J3YXJkaW5nLg0KPiANCj4gVGhhdCB0aGVyZSBjb3VsZCBiZSBhIGxvc3QgcGFj a2V0IChvciB0cmFmZmljIGRpc3J1cHRpb24gYXMgbWVudGlvbmVkDQo+IGVsc2V3aGVyZSkgd2Fz IHdoYXQgSSB3YXMgZ2V0dGluZyBhdC4gVGhlIGxhbmd1YWdlIGluIHRoZSBmaXJzdCBwYXJhZ3Jh cGggb2YNCj4gc2VjdGlvbiA4IGluZGljYXRlZCB1bmljYXN0IGNvdWxkIGhhdmUgdHJvdWJsZSBi dXQgYXMgSSByZWFkIGl0IHRoZSBzZWNvbmQNCj4gcGFyYWdyYXBoIGludGltYXRlZCB0aGF0IG11 bHRpY2FzdCBjb3VsZCBub3QuIEl0IHdhc27igJl0IGNsZWFyIHRvIG1lIHRoYXQgd2FzDQo+IHRy dWUgYW5kIGl0IHNvdW5kcyBsaWtlIGl0IGlzbuKAmXQgdHJ1ZSBmb3IgYWxsIGNhc2VzIChidXQg aXMgdHJ1ZSBhZnRlciBhIG5ldyBERiBoYXMNCj4gYmVlbiBlbGVjdGVkKS4NCj4gDQo+IFJlLXJl YWRpbmcgaXQgbm93IGl0IGlzIGNsZWFyIHRoZSBwb2ludCBpcyB0aGF0IG5vIOKAmHNwZWNpYWwg YWN0aW9uc+KAmSBhcmUgcmVxdWlyZWQNCj4gbm90IHRoYXQgdGhlcmUgY2FuIGJlIG5vIGxvc3Qg cGFja2V0LiBJdCBtaWdodCBiZSBtb3JlIGNsZWFyIGlmIGl0IHN0YXRlZA0KPiBhY2tub3dsZWRn ZWQgdGhlIGhhbmcgdGltZSBiZXR3ZWVuIGZhaWx1cmUgYW5kIGZ1bGwgZXN0YWJsaXNobWVudCBv ZiB0aGUgbmV3DQo+IFJCdiBmb2xsb3dpbmcgdGhlIGZhaWx1cmUuDQo+IA0KPiANCj4gDQo+ID4N Cj4gPg0KPiA+VGhhbmtzLA0KPiA+TWluZ3VpDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4gRnJvbTogQ2FybCBXYWxsYWNlIFttYWlsdG86Y2FybEByZWRob3VuZHNv ZnR3YXJlLmNvbV0NCj4gPj4gU2VudDogU3VuZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTUgNDowMCBB TQ0KPiA+PiBUbzogZHJhZnQtaWV0Zi10cmlsbC1wc2V1ZG9ub2RlLW5pY2tuYW1lLmFsbEB0b29s cy5pZXRmLm9yZw0KPiA+PiBDYzogaWVzZ0BpZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnDQo+ID4+ IFN1YmplY3Q6IGRyYWZ0LWlldGYtdHJpbGwtcHNldWRvbm9kZS1uaWNrbmFtZS0wNg0KPiA+Pg0K PiA+PiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0 eSBkaXJlY3RvcmF0ZeKAmXMNCj4gPj5vbmdvaW5nICBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRG IGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+ID4+SUVTRy4NCj4gPj4gVGhlc2Ug Y29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNl Y3VyaXR5DQo+ID4+YXJlYSAgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hh aXJzIHNob3VsZCB0cmVhdCB0aGVzZQ0KPiA+PmNvbW1lbnRzICBqdXN0IGxpa2UgYW55IG90aGVy IGxhc3QgY2FsbCBjb21tZW50cy4NCj4gPj4NCj4gPj4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg dXNlIG9mIHBzZXVkby1uaWNrbmFtZXMgZm9yIFJCcmlkZ2VzIGluIGFuDQo+ID4+QWN0aXZlLUFj dGl2ZSBFZGdlIFJCcmlkZ2UgZ3JvdXAuIEkgYW0gbm90IGZhbWlsaWFyIHdpdGggVFJJTEwgYnV0 DQo+ID4+Zm91bmQgdGhlICBkb2N1bWVudCB0byBiZSB3ZWxsIHdyaXR0ZW4gYW5kIGVhc3kgdG8g Zm9sbG93LiBJIGRpZCBoYXZlDQo+ID4+b25lIHF1ZXN0aW9uLCB3aGljaCAgbWF5IGp1c3QgYmUg ZHVlIHRvIG15IGxhY2sgb2YgZmFtaWxpYXJpdHkgd2l0aA0KPiA+PnJlbGV2YW50IG5vcm1hdGl2 ZSBzcGVjcy4gVGhlICBzZWNvbmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gOCBzdGF0ZXMNCj4gPj50 aGUgZm9sbG93aW5nOg0KPiA+Pg0KPiA+PiAJIkhvd2V2ZXIsIGZvciBtdWx0aS1kZXN0aW5hdGlv biBUUklMTCBEYXRhIHBhY2tldHMsIHNpbmNlIHRoZXkgY2FuDQo+ID4+cmVhY2ggIGFsbCBtZW1i ZXIgUkJyaWRnZXMgb2YgdGhlIG5ldyBSQnYgYW5kIGJlIGVncmVzc2VkIHRvIENFMSBieQ0KPiA+ PmVpdGhlciBSQjIgb3INCj4gPj4gUkIzIChpLmUuLCB0aGUgbmV3IERGIGZvciB0aGUgdHJhZmZp YydzIElubmVyLlZMQU4gb3IgdGhlIFZMQU4gdGhlDQo+ID4+cGFja2V0J3MgIElubmVyLkxhYmVs IG1hcHMgdG8gaW4gdGhlIG5ldyBSQnYpLCBzcGVjaWFsIGFjdGlvbnMgdG8NCj4gPj5wcm90ZWN0 IGFnYWluc3QgIGRvd25saW5rIGZhaWx1cmUgZm9yIHN1Y2ggbXVsdGktZGVzdGluYXRpb24gcGFj a2V0cw0KPiA+PmlzIG5vdCAgbmVlZGVkLiINCj4gPj4NCj4gPj4gV2h5IGlzIHRoZXJlIG5vIHJh Y2UgY29uZGl0aW9uIGJldHdlZW4gdGhlIGFycml2YWwgb2YNCj4gPj5tdWx0aeKAlGRlc3RpbmF0 aW9uIHRyYWZmaWMgIGFuZCB0aGUgY3JlYXRpb24gb2YgYSBuZXcgUkJ2IGZvbGxvd2luZyB0aGUN Cj4gPj5mYWlsdXJlIG9mIFJCMSB0aGF0IGVuYWJsZXMgdGhlICB0cmFmZmljIHRvIGJlIGZvcndh cmRlZD8gR2VuZXJhbGx5LA0KPiA+Pm1lbnRpb25pbmcgZmFpbHVyZSBvZiB0aGUgREYgZm9yIHRo ZSB2aXJ0dWFsICBSQnJpZGdlIHNlZW1lZCBsaWtlIGl0DQo+ID4+bWlnaHQgd2FycmFudCBtZW50 aW9uIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyAgc2VjdGlvbiwgc2luY2UNCj4gPj50 aGF0IGlzIG5ldyByZWxhdGl2ZSB0byB0aGUgc3BlY3Mgbm90ZWQgaW4gdGhlIGN1cnJlbnQgc2Vj dXJpdHkNCj4gPj5jb25zaWRlcmF0aW9ucy4NCj4gPj4NCj4gPg0KPiANCg0K From nobody Tue Sep 15 18:02:13 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39561B2FFE for ; Tue, 15 Sep 2015 17:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.311 X-Spam-Level: X-Spam-Status: No, score=-5.311 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 JiF-Q1N31hyX for ; Tue, 15 Sep 2015 17:58:43 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9545F1B2FFA for ; Tue, 15 Sep 2015 17:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442365123; x=1473901123; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=jTBOPuJxK3AeyUleWaGHpN5psbuCQDJGkRPinsNMmwk=; b=Qihao/3yedU19QJkCEefiVnI27GiIpBX1G0TPOuWa2NbSkwiGcVr0KNZ sdta1Sj3Fjo8jZKWPNXxmAC8TQ6187Cnrh3yxozstXwKeLMdA5lLNxK0C jOrDO5uO1RQdOIccp6C60oBXYm2Y8LGgRFr9kE2hpa8ylZW4tXdIovC67 k=; X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="138779972" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2015 17:58:43 -0700 X-IronPort-AV: E=Sophos;i="5.17,537,1437462000"; d="scan'208";a="1055554162" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Sep 2015 17:58:42 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 15 Sep 2015 17:58:41 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Tue, 15 Sep 2015 17:58:39 -0700 To: Magnus =?iso-8859-1?Q?Nystr=F6m?= , "secdir@ietf.org" , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: X-Mailman-Approved-At: Tue, 15 Sep 2015 18:02:12 -0700 Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 00:58:45 -0000 Hi Magnus, Thank you for your review and comments. Please see in-line. At 9:26 PM -0700 8/31/15, Magnus Nystr=F6m wrote: > I have reviewed this document as part of the=20 > security directorate's ongoing effort to review=20 > all IETF documents being processed by the IESG.=20 > These comments were written primarily for the=20 > benefit of the security area directors.=20 > Document editors and WG chairs should treat=20 > these comments just like any other last call=20 > comments. > > This memo provides fundamental data structure=20 > definitions and procedural rules for providing=20 > auxiliary information to public service=20 > answering points (PSAPs) when emergency calls=20 > are being made. > > > This reads as an important memo and has been at=20 > least five years in the making. I don't find=20 > the Security (and Privacy) Considerations=20 > section lacking per se, but do have these=20 > questions: > > - Why require HTTPS for the reference case but=20 > not the value case (I can understand why you=20 > don't require it for the value case, but=20 > couldn't it be a choice for the PSAP also in=20 > the reference case? This would also seem to=20 > simplify during an introductory phase when a=20 > wide-spread PKI solution is not yet in place.)? I'm very surprised that a security area person is=20 asking why we don't make TLS optional! It's a=20 valid question, of course, just surprising in=20 this context. Because of the limited scope of=20 the document, specifically emergency services,=20 and given that the dereferencing entities will be=20 PSAPs and other responders that have upgraded to=20 support next-generation, we felt that it was=20 reasonable to require the use of TLS and=20 client-side certificates for dereferencing. > - When HTTPS is required, I assume the PSAP=20 > needs a client certificate - i.e., that the=20 > mutual auth option of TLS is being used,=20 > perhaps this needs to be clarified? Yes, good point. I added clarifying text in response to Ben's comments. > - Was there any discussion around any MTI TLS cipher suites? No, this was never discussed as far as I can recall. > - I assume there's not only a privacy issue but=20 > also a potential spoofing issue - the PSAPs=20 > don't want to be overly susceptible to spoofed=20 > calls (although they rather err on the side of=20 > safety, of course. Thus, should integrity of=20 > infomation in the direct case be considered?=20 > I.e., by n/w or service providers in the path=20 > to the PSAP vouching for the information? You're absolutely correct that PSAPs are=20 concerned about spoofed (and other false) calls=20 but will generally err by taking a call and=20 asking the caller for information. In general,=20 PSAPs prefer information that comes from known=20 and trusted providers (the major carriers). Are=20 you suggesting a mechanism by which providers=20 verify the information provided by the device?=20 =46or location information, there are discussions=20 in other SDOs about sanity-checking=20 device-provided information (location or Wi-Fi=20 APs) against network-known information (macro=20 cell to which the device is associated). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- In a sense, when we started Virgin Atlantic, I was trying to create an airline for myself. If you try to build the perfect airline for yourself, it will be appreciated by others. --Richard Branson, 1996. From nobody Tue Sep 15 18:39:58 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69501B2FC1 for ; Tue, 15 Sep 2015 18:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 XqXyaQkyvLfM for ; Tue, 15 Sep 2015 18:39:55 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 73B0C1B2F08 for ; Tue, 15 Sep 2015 18:39:54 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so51949556wic.1 for ; Tue, 15 Sep 2015 18:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GJHVE5cVBOTcBIIQLxmXjZ3myzItkUuMsozvQgV8/xM=; b=KuQLnkoMR+1yFqJ3HJAGnOJwqsPJBIAW5EXLw1ulATzfvbIc1xqsBgfq48ycjVX2dY yAwzZhV1UGpenCaMZT9QWZJccOQUEDHbu4fazTEbAWWEUWptW0G/LiAS21UZaZtHZqmU kC6S7vvY4KU2dov1NRxSHRIgumxalWqF/ZniL1s6/iDy/RtM33RqhKea+EPCeU+AcUUT syWn89o1waf4yqAMN1LWfp0Q6neYBYLMU0ta6QYB5SVqLXq0pG6ZcfDuKlhv7Ar8XVp8 ZKwLBFHdwPLrN3p+syscs2BMvo8Ju1dT5UcNyxs/Idmey4MculUNZpSCPBaHWtzFO7l8 82SQ== MIME-Version: 1.0 X-Received: by 10.180.23.162 with SMTP id n2mr13031210wif.8.1442367593071; Tue, 15 Sep 2015 18:39:53 -0700 (PDT) Received: by 10.27.130.200 with HTTP; Tue, 15 Sep 2015 18:39:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Sep 2015 18:39:53 -0700 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: Randall Gellens Content-Type: multipart/alternative; boundary=e89a8f838a9705485f051fd36086 Archived-At: Cc: draft-ietf-ecrit-additional-data@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 01:39:56 -0000 --e89a8f838a9705485f051fd36086 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Randall, Yes, I guess it may be surprising ... but I was thinking more about getting this effort implemented in an expedited fashion rather than potentially delaying due to the potential issues (also pointed out in the draft) around getting the necessary trust anchors in place between PSAPs and service providers enabling the mutual authentication. It may be good to say something about MTI suites - I would suggest mandating support for a set of suites that offers PFS and avoids CBC, e.g., something like: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 I would also suggest mandating TLS 1.2 (or later) for a new application like this. On the last point, yes, if the service provider is in a possession to vouch for or sanity-check then that could help introduce reliability. Best, On Tue, Sep 15, 2015 at 5:58 PM, Randall Gellens wrote: > Hi Magnus, > > Thank you for your review and comments. Please see in-line. > > At 9:26 PM -0700 8/31/15, Magnus Nystr=C3=B6m 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 ar= ea >> directors. Document editors and WG chairs should treat these comments ju= st >> like any other last call comments. >> >> This memo provides fundamental data structure definitions and procedura= l >> rules for providing auxiliary information to public service answering >> points (PSAPs) when emergency calls are being made. >> >> >> This reads as an important memo and has been at least five years in the >> making. I don't find the Security (and Privacy) Considerations section >> lacking per se, but do have these questions: >> >> - Why require HTTPS for the reference case but not the value case (I ca= n >> understand why you don't require it for the value case, but couldn't it = be >> a choice for the PSAP also in the reference case? This would also seem t= o >> simplify during an introductory phase when a wide-spread PKI solution is >> not yet in place.)? >> > > I'm very surprised that a security area person is asking why we don't mak= e > TLS optional! It's a valid question, of course, just surprising in this > context. Because of the limited scope of the document, specifically > emergency services, and given that the dereferencing entities will be PSA= Ps > and other responders that have upgraded to support next-generation, we fe= lt > that it was reasonable to require the use of TLS and client-side > certificates for dereferencing. > > - When HTTPS is required, I assume the PSAP needs a client certificate - >> i.e., that the mutual auth option of TLS is being used, perhaps this nee= ds >> to be clarified? >> > > Yes, good point. I added clarifying text in response to Ben's comments. > > - Was there any discussion around any MTI TLS cipher suites? >> > > No, this was never discussed as far as I can recall. > > - I assume there's not only a privacy issue but also a potential spoofin= g >> issue - the PSAPs don't want to be overly susceptible to spoofed calls >> (although they rather err on the side of safety, of course. Thus, should >> integrity of infomation in the direct case be considered? I.e., by n/w o= r >> service providers in the path to the PSAP vouching for the information? >> > > You're absolutely correct that PSAPs are concerned about spoofed (and > other false) calls but will generally err by taking a call and asking the > caller for information. In general, PSAPs prefer information that comes > from known and trusted providers (the major carriers). Are you suggestin= g > a mechanism by which providers verify the information provided by the > device? For location information, there are discussions in other SDOs abo= ut > sanity-checking device-provided information (location or Wi-Fi APs) again= st > network-known information (macro cell to which the device is associated). > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > In a sense, when we started Virgin Atlantic, I was trying to create > an airline for myself. If you try to build the perfect airline for > yourself, it will be appreciated by others. --Richard Branson, 1996. > --=20 -- Magnus --e89a8f838a9705485f051fd36086 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Randall,
Yes, I guess it may be surprisi= ng ... but I was thinking more about getting this effort implemented in an = expedited fashion rather than potentially delaying due to the potential iss= ues (also pointed out in the draft) around getting the necessary trust anch= ors in place between PSAPs and service providers enabling the mutual authen= tication.

It may be good to say something about MT= I suites - I would suggest mandating support for a set of suites that offer= s PFS and avoids CBC, e.g., something like:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_S= HA384

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_S= HA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA= 384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA= 256

TLS_DHE_RSA_WITH_AES_256_GCM_SHA38= 4

TLS_DHE_RSA_WITH_AES_128_GCM_SHA25= 6


I would also suggest mandating TLS 1.2 (or later) for a new applicat= ion like this.
On the last point, yes, if the service provider is in a po= ssession to vouch for or sanity-check then that could help introduce reliab= ility.

Best,


On Tue, Sep 15, 2015 at 5:58 PM, Rand= all Gellens <randy@qti.qualcomm.com> wrote:
Hi Magnus,

Thank you for your review and comments.=C2=A0 Please see in-line.

At 9:26 PM -0700 8/31/15, Magnus Nystr=C3=B6m wrote:

=C2=A0I 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.

=C2=A0This memo provides fundamental data structure definitions and procedu= ral rules for providing auxiliary information to public service answering p= oints (PSAPs) when emergency calls are being made.


=C2=A0This reads as an important memo and has been at least five years in t= he making. I don't find the Security (and Privacy) Considerations secti= on lacking per se, but do have these questions:

=C2=A0- Why require HTTPS for the reference case but not the value case (I = can understand why you don't require it for the value case, but couldn&= #39;t it be a choice for the PSAP also in the reference case? This would al= so seem to simplify during an introductory phase when a wide-spread PKI sol= ution is not yet in place.)?

I'm very surprised that a security area person is asking why we don'= ;t make TLS optional!=C2=A0 It's a valid question, of course, just surp= rising in this context.=C2=A0 Because of the limited scope of the document,= specifically emergency services, and given that the dereferencing entities= will be PSAPs and other responders that have upgraded to support next-gene= ration, we felt that it was reasonable to require the use of TLS and client= -side certificates for dereferencing.

=C2=A0- When HTTPS is required, I assume the PSAP needs a client certificat= e - i.e., that the mutual auth option of TLS is being used, perhaps this ne= eds to be clarified?

Yes, good point.=C2=A0 I added clarifying text in response to Ben's com= ments.

=C2=A0- Was there any discussion around any MTI TLS cipher suites?

No, this was never discussed as far as I can recall.

=C2=A0- I assume there's not only a privacy issue but also a potential = spoofing issue - the PSAPs don't want to be overly susceptible to spoof= ed calls (although they rather err on the side of safety, of course. Thus, = should integrity of infomation in the direct case be considered? I.e., by n= /w or service providers in the path to the PSAP vouching for the informatio= n?

You're absolutely correct that PSAPs are concerned about spoofed (and o= ther false) calls but will generally err by taking a call and asking the ca= ller for information.=C2=A0 In general, PSAPs prefer information that comes= from known and trusted providers (the major carriers).=C2=A0 Are you sugge= sting a mechanism by which providers verify the information provided by the= device? For location information, there are discussions in other SDOs abou= t sanity-checking device-provided information (location or Wi-Fi APs) again= st network-known information (macro cell to which the device is associated)= .

--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
In a sense, when we started Virgin Atlantic, I was trying to create
an airline for myself. If you try to build the perfect airline for
yourself, it will be appreciated by others. --Richard Branson, 1996.



--
-- Magnus
--e89a8f838a9705485f051fd36086-- From nobody Tue Sep 15 19:07:03 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1A71ACD03 for ; Tue, 15 Sep 2015 19:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.711 X-Spam-Level: X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7R5ml097IdtZ for ; Tue, 15 Sep 2015 19:07:00 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904FB1AC3D9 for ; Tue, 15 Sep 2015 19:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442369220; x=1473905220; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=5nhDzqSWZrYVklLOGhRonodsDhIe08XMLJolefz7zZc=; b=A4ujBRHaOuhrt9FzyqyHO39meanMl4UyM92QUHum+CVxAF74M+h/9Ox6 QkC1l8hX+CHymZ7oQYIYexWXWSZaC8h+Bhhh5tj5Nu4Nv4vvCAl8tx7vR JmeHeIipfzAoZYMBvhlm5mhqxoLZM+xTb2WPOyNDFLwyHr2oaUWbh5MoS o=; X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="97928829" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 15 Sep 2015 19:07:00 -0700 X-IronPort-AV: E=Sophos;i="5.17,537,1437462000"; d="scan'208";a="33674514" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Sep 2015 19:06:59 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 15 Sep 2015 19:06:58 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Tue, 15 Sep 2015 19:06:49 -0700 To: Magnus =?iso-8859-1?Q?Nystr=F6m?= From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 02:07:02 -0000 Hi Magnus, I think we can mandate TLS 1.2 or later without=20 any problem, and I can add that to the text that=20 mandates HTTPS. I don't think I can add MTI=20 cypher suites at this stage, but I think it would=20 be OK to add text such as "it is RECOMMENDED to=20 use only suites that offer Perfect Forward=20 Secrecy (PFS) and avoid Cipher Block Chaining=20 (CBC)", with your list of suites as an example.=20 What do you think? If we go this way, I'd=20 probably need to also add an informational=20 reference or two; what do you suggest? At 6:39 PM -0700 9/15/15, Magnus Nystr=F6m wrote: > Hi Randall, > Yes, I guess it may be surprising ... but I was=20 > thinking more about getting this effort=20 > implemented in an expedited fashion rather than=20 > potentially delaying due to the potential=20 > issues (also pointed out in the draft) around=20 > getting the necessary trust anchors in place=20 > between PSAPs and service providers enabling=20 > the mutual authentication. > > It may be good to say something about MTI=20 > suites - I would suggest mandating support for=20 > a set of suites that offers PFS and avoids CBC,=20 > e.g., something like: > > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 > > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > > > I would also suggest mandating TLS 1.2 (or=20 > later) for a new application like this. > On the last point, yes, if the service provider=20 > is in a possession to vouch for or sanity-check=20 > then that could help introduce reliability. > > Best, > > > On Tue, Sep 15, 2015 at 5:58 PM, Randall=20 > Gellens=20 > <randy@qti.qualcomm.com>=20 > wrote: > > Hi Magnus, > > Thank you for your review and comments. Please see in-line. > > At 9:26 PM -0700 8/31/15, Magnus Nystr=F6m wrote: > > I have reviewed this document as part of the=20 > security directorate's ongoing effort to review=20 > all IETF documents being processed by the IESG.=20 > These comments were written primarily for the=20 > benefit of the security area directors.=20 > Document editors and WG chairs should treat=20 > these comments just like any other last call=20 > comments. > > This memo provides fundamental data structure=20 > definitions and procedural rules for providing=20 > auxiliary information to public service=20 > answering points (PSAPs) when emergency calls=20 > are being made. > > > This reads as an important memo and has been=20 > at least five years in the making. I don't find=20 > the Security (and Privacy) Considerations=20 > section lacking per se, but do have these=20 > questions: > > - Why require HTTPS for the reference case but=20 > not the value case (I can understand why you=20 > don't require it for the value case, but=20 > couldn't it be a choice for the PSAP also in=20 > the reference case? This would also seem to=20 > simplify during an introductory phase when a=20 > wide-spread PKI solution is not yet in place.)? > > > I'm very surprised that a security area person=20 > is asking why we don't make TLS optional! It's=20 > a valid question, of course, just surprising in=20 > this context. Because of the limited scope of=20 > the document, specifically emergency services,=20 > and given that the dereferencing entities will=20 > be PSAPs and other responders that have=20 > upgraded to support next-generation, we felt=20 > that it was reasonable to require the use of=20 > TLS and client-side certificates for=20 > dereferencing. > > - When HTTPS is required, I assume the PSAP=20 > needs a client certificate - i.e., that the=20 > mutual auth option of TLS is being used,=20 > perhaps this needs to be clarified? > > > Yes, good point. I added clarifying text in response to Ben's comments. > > - Was there any discussion around any MTI TLS cipher suites? > > > No, this was never discussed as far as I can recall. > > - I assume there's not only a privacy issue=20 > but also a potential spoofing issue - the PSAPs=20 > don't want to be overly susceptible to spoofed=20 > calls (although they rather err on the side of=20 > safety, of course. Thus, should integrity of=20 > infomation in the direct case be considered?=20 > I.e., by n/w or service providers in the path=20 > to the PSAP vouching for the information? > > > You're absolutely correct that PSAPs are=20 > concerned about spoofed (and other false) calls=20 > but will generally err by taking a call and=20 > asking the caller for information. In general,=20 > PSAPs prefer information that comes from known=20 > and trusted providers (the major carriers).=20 > Are you suggesting a mechanism by which=20 > providers verify the information provided by=20 > the device? For location information, there are=20 > discussions in other SDOs about sanity-checking=20 > device-provided information (location or Wi-Fi=20 > APs) against network-known information (macro=20 > cell to which the device is associated). > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > In a sense, when we started Virgin Atlantic, I was trying to create > an airline for myself. If you try to build the perfect airline for > yourself, it will be appreciated by others. --Richard Branson, 1996. > > > > > -- > > -- Magnus -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- All we're seeing is the negative side of nuclear war. --Barry Goldwater From nobody Tue Sep 15 20:09:09 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BEE1B322B for ; Tue, 15 Sep 2015 20:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 gfG6yQPfL6BB for ; Tue, 15 Sep 2015 20:09:05 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::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 4C65A1B321F for ; Tue, 15 Sep 2015 20:09:05 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so54133794wic.1 for ; Tue, 15 Sep 2015 20:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FKgV9mpwu6R/dXuAv8kZ/tbzCxJYMB48d3AuxTSjx48=; b=Z5Sl/KZklllCqeBU4dSd45Neotngxra2vwketIxocsntdw/EZy0um5ehLFevzUFy2t +ISpYp4lDZM3ZvgpQRW+hPzWzQCAHhMkUNO1Hpns6mgwKGgoMIzo6QUEGVr+ErFp2mg7 o4tq5xH33Z2euoeT9HkxIP4ed4yz7PqbwHFa6US72z8hkJYZfxfBSZu1inbgwFXhgkg9 JFGblTfY37ms0rAQhw7lLL1KCDWTRQEtg4UiMEMXXA/6vyn9UdDZO/7TflZDKa1pRtTN seRu7vCGzxn+7XFxijJ+W9/4eIbBVUhpgXyknIioT6WCovqw/l/nkSoY//4297wmnzmT KiLg== MIME-Version: 1.0 X-Received: by 10.194.203.99 with SMTP id kp3mr11766074wjc.157.1442372943861; Tue, 15 Sep 2015 20:09:03 -0700 (PDT) Received: by 10.27.130.200 with HTTP; Tue, 15 Sep 2015 20:09:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Sep 2015 20:09:03 -0700 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: Randall Gellens Content-Type: multipart/alternative; boundary=047d7bd91af2f3de88051fd49e49 Archived-At: Cc: draft-ietf-ecrit-additional-data@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 03:09:08 -0000 --047d7bd91af2f3de88051fd49e49 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, at least mandating TLS 1.2 or higher and recommending as per above seems reasonable. The references for the GCM suites would be RFC 5288 and RFC 5289. Thanks! On Tue, Sep 15, 2015 at 7:06 PM, Randall Gellens wrote: > Hi Magnus, > > I think we can mandate TLS 1.2 or later without any problem, and I can ad= d > that to the text that mandates HTTPS. I don't think I can add MTI cypher > suites at this stage, but I think it would be OK to add text such as "it = is > RECOMMENDED to use only suites that offer Perfect Forward Secrecy (PFS) a= nd > avoid Cipher Block Chaining (CBC)", with your list of suites as an exampl= e. > What do you think? If we go this way, I'd probably need to also add an > informational reference or two; what do you suggest? > > At 6:39 PM -0700 9/15/15, Magnus Nystr=C3=B6m wrote: > > Hi Randall, >> Yes, I guess it may be surprising ... but I was thinking more about >> getting this effort implemented in an expedited fashion rather than >> potentially delaying due to the potential issues (also pointed out in th= e >> draft) around getting the necessary trust anchors in place between PSAPs >> and service providers enabling the mutual authentication. >> >> It may be good to say something about MTI suites - I would suggest >> mandating support for a set of suites that offers PFS and avoids CBC, e.= g., >> something like: >> >> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 >> >> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >> >> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >> >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >> >> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 >> >> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 >> >> >> I would also suggest mandating TLS 1.2 (or later) for a new application >> like this. >> On the last point, yes, if the service provider is in a possession to >> vouch for or sanity-check then that could help introduce reliability. >> >> Best, >> >> >> On Tue, Sep 15, 2015 at 5:58 PM, Randall Gellens <> randy@qti.qualcomm.com>randy@qti.qualcomm.com> wrote: >> >> Hi Magnus, >> >> Thank you for your review and comments. Please see in-line. >> >> At 9:26 PM -0700 8/31/15, Magnus Nystr=C3=B6m 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 ar= ea >> directors. Document editors and WG chairs should treat these comments ju= st >> like any other last call comments. >> >> This memo provides fundamental data structure definitions and >> procedural rules for providing auxiliary information to public service >> answering points (PSAPs) when emergency calls are being made. >> >> >> This reads as an important memo and has been at least five years in th= e >> making. I don't find the Security (and Privacy) Considerations section >> lacking per se, but do have these questions: >> >> - Why require HTTPS for the reference case but not the value case (I >> can understand why you don't require it for the value case, but couldn't= it >> be a choice for the PSAP also in the reference case? This would also see= m >> to simplify during an introductory phase when a wide-spread PKI solution= is >> not yet in place.)? >> >> >> I'm very surprised that a security area person is asking why we don't >> make TLS optional! It's a valid question, of course, just surprising in >> this context. Because of the limited scope of the document, specificall= y >> emergency services, and given that the dereferencing entities will be PS= APs >> and other responders that have upgraded to support next-generation, we f= elt >> that it was reasonable to require the use of TLS and client-side >> certificates for dereferencing. >> >> - When HTTPS is required, I assume the PSAP needs a client certificate >> - i.e., that the mutual auth option of TLS is being used, perhaps this >> needs to be clarified? >> >> >> Yes, good point. I added clarifying text in response to Ben's comments= . >> >> - Was there any discussion around any MTI TLS cipher suites? >> >> >> No, this was never discussed as far as I can recall. >> >> - I assume there's not only a privacy issue but also a potential >> spoofing issue - the PSAPs don't want to be overly susceptible to spoofe= d >> calls (although they rather err on the side of safety, of course. Thus, >> should integrity of infomation in the direct case be considered? I.e., b= y >> n/w or service providers in the path to the PSAP vouching for the >> information? >> >> >> You're absolutely correct that PSAPs are concerned about spoofed (and >> other false) calls but will generally err by taking a call and asking th= e >> caller for information. In general, PSAPs prefer information that comes >> from known and trusted providers (the major carriers). Are you suggestin= g a >> mechanism by which providers verify the information provided by the devi= ce? >> For location information, there are discussions in other SDOs about >> sanity-checking device-provided information (location or Wi-Fi APs) agai= nst >> network-known information (macro cell to which the device is associated)= . >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> In a sense, when we started Virgin Atlantic, I was trying to create >> an airline for myself. If you try to build the perfect airline for >> yourself, it will be appreciated by others. --Richard Branson, 1996. >> >> >> >> >> -- >> >> -- Magnus >> > > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > All we're seeing is the negative side of nuclear war. > --Barry Goldwater > --=20 -- Magnus --047d7bd91af2f3de88051fd49e49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, at least mandating TLS 1.2 or higher and re= commending as per above seems reasonable.
The references for the G= CM suites would be RFC 5288 and RFC 5289.

Thanks!

On Tue, Sep 15, 2015= at 7:06 PM, Randall Gellens <randy@qti.qualcomm.com> w= rote:
Hi Magnus,

I think we can mandate TLS 1.2 or later without any problem, and I can add = that to the text that mandates HTTPS.=C2=A0 I don't think I can add MTI= cypher suites at this stage, but I think it would be OK to add text such a= s "it is RECOMMENDED to use only suites that offer Perfect Forward Sec= recy (PFS) and avoid Cipher Block Chaining (CBC)", with your list of s= uites as an example. What do you think?=C2=A0 If we go this way, I'd pr= obably need to also add an informational reference or two; what do you sugg= est?

At 6:39 PM -0700 9/15/15, Magnus Nystr=C3=B6m wrote:

=C2=A0Hi Randall,
=C2=A0Yes, I guess it may be surprising ... but I was thinking more about g= etting this effort implemented in an expedited fashion rather than potentia= lly delaying due to the potential issues (also pointed out in the draft) ar= ound getting the necessary trust anchors in place between PSAPs and service= providers enabling the mutual authentication.

=C2=A0It may be good to say something about MTI suites - I would suggest ma= ndating support for a set of suites that offers PFS and avoids CBC, e.g., s= omething like:

=C2=A0TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

=C2=A0TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

=C2=A0TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

=C2=A0TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

=C2=A0TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

=C2=A0TLS_DHE_RSA_WITH_AES_128_GCM_SHA256


=C2=A0I would also suggest mandating TLS 1.2 (or later) for a new applicati= on like this.
=C2=A0On the last point, yes, if the service provider is in a possession to= vouch for or sanity-check then that could help introduce reliability.

=C2=A0Best,


=C2=A0On Tue, Sep 15, 2015 at 5:58 PM, Randall Gellens <<mailto:randy@qti.qualcomm.c= om>randy= @qti.qualcomm.com> wrote:

=C2=A0Hi Magnus,

=C2=A0Thank you for your review and comments.=C2=A0 Please see in-line.

=C2=A0At 9:26 PM -0700 8/31/15, Magnus Nystr=C3=B6m wrote:

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

=C2=A0 This memo provides fundamental data structure definitions and proced= ural rules for providing auxiliary information to public service answering = points (PSAPs) when emergency calls are being made.


=C2=A0 This reads as an important memo and has been at least five years in = the making. I don't find the Security (and Privacy) Considerations sect= ion lacking per se, but do have these questions:

=C2=A0 - Why require HTTPS for the reference case but not the value case (I= can understand why you don't require it for the value case, but couldn= 't it be a choice for the PSAP also in the reference case? This would a= lso seem to simplify during an introductory phase when a wide-spread PKI so= lution is not yet in place.)?


=C2=A0I'm very surprised that a security area person is asking why we d= on't make TLS optional!=C2=A0 It's a valid question, of course, jus= t surprising in this context.=C2=A0 Because of the limited scope of the doc= ument, specifically emergency services, and given that the dereferencing en= tities will be PSAPs and other responders that have upgraded to support nex= t-generation, we felt that it was reasonable to require the use of TLS and = client-side certificates for dereferencing.

=C2=A0 - When HTTPS is required, I assume the PSAP needs a client certifica= te - i.e., that the mutual auth option of TLS is being used, perhaps this n= eeds to be clarified?


=C2=A0Yes, good point.=C2=A0 I added clarifying text in response to Ben'= ;s comments.

=C2=A0 - Was there any discussion around any MTI TLS cipher suites?


=C2=A0No, this was never discussed as far as I can recall.

=C2=A0 - I assume there's not only a privacy issue but also a potential= spoofing issue - the PSAPs don't want to be overly susceptible to spoo= fed calls (although they rather err on the side of safety, of course. Thus,= should integrity of infomation in the direct case be considered? I.e., by = n/w or service providers in the path to the PSAP vouching for the informati= on?


=C2=A0You're absolutely correct that PSAPs are concerned about spoofed = (and other false) calls but will generally err by taking a call and asking = the caller for information.=C2=A0 In general, PSAPs prefer information that= comes from known and trusted providers (the major carriers). Are you sugge= sting a mechanism by which providers verify the information provided by the= device? For location information, there are discussions in other SDOs abou= t sanity-checking device-provided information (location or Wi-Fi APs) again= st network-known information (macro cell to which the device is associated)= .

=C2=A0--
=C2=A0Randall Gellens
=C2=A0Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I= speak for myself only
=C2=A0-------------- Randomly selected tag: ---------------
=C2=A0In a sense, when we started Virgin Atlantic, I was trying to create =C2=A0an airline for myself. If you try to build the perfect airline for =C2=A0yourself, it will be appreciated by others. --Richard Branson, 1996.<= br>



=C2=A0--

=C2=A0-- Magnus



--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
All we're seeing is the negative side of nuclear war.
=C2=A0 =C2=A0--Barry Goldwater



--
-- Magnus
--047d7bd91af2f3de88051fd49e49-- From nobody Tue Sep 15 21:21:21 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C001B33AD for ; Tue, 15 Sep 2015 21:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.711 X-Spam-Level: X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 eYC3aFgShDGB for ; Tue, 15 Sep 2015 21:21:18 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380761B33AA for ; Tue, 15 Sep 2015 21:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442377278; x=1473913278; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=vtbIpv0pP5RbIABRpiXY5HEGJtjnz0/jx6MHDaYbPPE=; b=uxh57WN7t6J5my0Qgxl/Gmi7zjlxZZz1dv5vUhzia2+w4cCfkkBbwpAm owoUtA6h7H78gwg28wr7l+nMBPJWauqPty9lLqUlTzAIBmJZPUr9fsyxw aFkKsnI7uIKICA5FKZeYB7VeehFhjttBN/69TyEn/mHNDa4x8FbHHpTFD Y=; X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="97936575" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2015 21:21:17 -0700 X-IronPort-AV: E=Sophos;i="5.17,537,1437462000"; d="scan'208";a="1002528923" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Sep 2015 21:21:17 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 15 Sep 2015 21:21:16 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Tue, 15 Sep 2015 21:21:14 -0700 To: Magnus =?iso-8859-1?Q?Nystr=F6m?= From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 04:21:20 -0000 I've made these changes and included the two references. Thanks very much. At 8:09 PM -0700 9/15/15, Magnus Nystr=F6m wrote: > Yes, at least mandating TLS 1.2 or higher and recommending as per above > seems reasonable. > The references for the GCM suites would be RFC 5288 and RFC 5289. > > Thanks! > > On Tue, Sep 15, 2015 at 7:06 PM, Randall Gellens > wrote: > >> Hi Magnus, >> >> I think we can mandate TLS 1.2 or later without any problem, and I can a= dd >> that to the text that mandates HTTPS. I don't think I can add MTI cyphe= r >> suites at this stage, but I think it would be OK to add text such as "it= is >> RECOMMENDED to use only suites that offer Perfect Forward Secrecy (PFS) = and >> avoid Cipher Block Chaining (CBC)", with your list of suites as an examp= le. >> What do you think? If we go this way, I'd probably need to also add an >> informational reference or two; what do you suggest? >> >> At 6:39 PM -0700 9/15/15, Magnus Nystr=F6m wrote: >> >> Hi Randall, >>> Yes, I guess it may be surprising ... but I was thinking more about >>> getting this effort implemented in an expedited fashion rather than >>> potentially delaying due to the potential issues (also pointed out in t= he >>> draft) around getting the necessary trust anchors in place between PSAP= s >>> and service providers enabling the mutual authentication. >>> >>> It may be good to say something about MTI suites - I would suggest >>> mandating support for a set of suites that offers PFS and avoids CBC, e= =2Eg., >>> something like: >>> >>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 >>> >>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >>> >>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >>> >>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >>> >>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 >>> >>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 >>> >>> >>> I would also suggest mandating TLS 1.2 (or later) for a new applicatio= n >>> like this. >>> On the last point, yes, if the service provider is in a possession to >>> vouch for or sanity-check then that could help introduce reliability. >>> >>> Best, >>> >>> >>> On Tue, Sep 15, 2015 at 5:58 PM, Randall Gellens <>> randy@qti.qualcomm.com>randy@qti.qualcomm.com> wrote: >>> >>> Hi Magnus, >>> >>> Thank you for your review and comments. Please see in-line. >>> >>> At 9:26 PM -0700 8/31/15, Magnus Nystr=F6m 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= =2E >>> These comments were written primarily for the benefit of the security a= rea >>> directors. Document editors and WG chairs should treat these comments j= ust >>> like any other last call comments. >>> >>> This memo provides fundamental data structure definitions and >>> procedural rules for providing auxiliary information to public service >>> answering points (PSAPs) when emergency calls are being made. >>> >>> >>> This reads as an important memo and has been at least five years in t= he >>> making. I don't find the Security (and Privacy) Considerations section >>> lacking per se, but do have these questions: >>> >>> - Why require HTTPS for the reference case but not the value case (I >>> can understand why you don't require it for the value case, but= couldn't it >>> be a choice for the PSAP also in the reference case? This would also se= em >>> to simplify during an introductory phase when a wide-spread PKI= solution is >>> not yet in place.)? >>> >>> >>> I'm very surprised that a security area person is asking why we don't >>> make TLS optional! It's a valid question, of course, just surprising i= n >>> this context. Because of the limited scope of the document, specifical= ly >>> emergency services, and given that the dereferencing entities will be P= SAPs >>> and other responders that have upgraded to support next-generation, we = felt >>> that it was reasonable to require the use of TLS and client-side > >> certificates for dereferencing. >>> >>> - When HTTPS is required, I assume the PSAP needs a client certificat= e >>> - i.e., that the mutual auth option of TLS is being used, perhaps this >>> needs to be clarified? >>> >>> >>> Yes, good point. I added clarifying text in response to Ben's comment= s -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- This fortune intentionally not included. From nobody Wed Sep 16 00:38:14 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218671B3845 for ; Wed, 16 Sep 2015 00:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YuwV87AbOUYj for ; Wed, 16 Sep 2015 00:38:09 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1859D1B36F3 for ; Wed, 16 Sep 2015 00:38:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1D938BE87; Wed, 16 Sep 2015 08:38:07 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKoUC8D3Vd6p; Wed, 16 Sep 2015 08:38:05 +0100 (IST) Received: from [127.0.0.1] (unknown [86.46.27.30]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0AB57BE2F; Wed, 16 Sep 2015 08:38:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1442389085; bh=N0zrb2vwbaIxy9LSK8koJFRc5CNbdGbC4HAKPj/ogLE=; h=To:Cc:From:Subject:In-Reply-To:References:Date:From; b=SA9nCw9bUIp0MfitPLjQnaPqBwyppstAslOjOCo6vSEwNMiti8uOKTC5mE8YLZ8hM nZDOUjJkaq+zqj2TzY1XT1gYFd9yI1Oynebw7IHwWAKnFPr6Vadco7jCPLYfvo0wxR BqN+QxmknDRoDWZfCMlzwSvle/0KKXNZlZ7bD2e8= X-Priority: 3 To: magnusn@gmail.com From: stephen.farrell@cs.tcd.ie In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Date: Wed, 16 Sep 2015 07:38:03 +0000 Message-ID: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> MIME-Version: 1.0 Archived-At: Cc: randy@qti.qualcomm.com, draft-ietf-ecrit-additional-data@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 07:38:12 -0000 DQoNCk9uIFdlZCBTZXAgMTYgMDQ6MDk6MDMgMjAxNSBHTVQrMDEwMCwgTWFnbnVzIE55c3Ryw7Zt IHdyb3RlOg0KPiBZZXMsIGF0IGxlYXN0IG1hbmRhdGluZyBUTFMgMS4yIG9yIGhpZ2hlciBhbmQg cmVjb21tZW5kaW5nIGFzIHBlciBhYm92ZQ0KPiBzZWVtcyByZWFzb25hYmxlLg0KPiBUaGUgcmVm ZXJlbmNlcyBmb3IgdGhlIEdDTSBzdWl0ZXMgd291bGQgYmUgUkZDIDUyODggYW5kIFJGQyA1Mjg5 Lg0KDQpCQ1AxOTUgaGFzIHJlY2VudCByZWNvbW1lbmRhdGlvbnMgZm9yIG1vc3QgVExTIG9wdGlv bnMuIEknZCBzYXkgaXQnZCBiZSBiZXN0IHRvIHVzZSB0aG9zZSBvciBpZiBub3QgZmlndXJlIG91 dCB3aHkgdGhleSdyZSBub3QgY29ycmVjdCBmb3IgdGhpcyBjb250ZXh0Lg0KDQpTLg0KIA0KDQo+ IA0KPiBUaGFua3MhDQo+IA0KPiBPbiBUdWUsIFNlcCAxNSwgMjAxNSBhdCA3OjA2IFBNLCBSYW5k YWxsIEdlbGxlbnMgPHJhbmR5QHF0aS5xdWFsY29tbS5jb20+DQo+IHdyb3RlOg0KPiANCj4gPiBI aSBNYWdudXMsDQo+ID4NCj4gPiBJIHRoaW5rIHdlIGNhbiBtYW5kYXRlIFRMUyAxLjIgb3IgbGF0 ZXIgd2l0aG91dCBhbnkgcHJvYmxlbSwgYW5kIEkgY2FuIGFkZA0KPiA+IHRoYXQgdG8gdGhlIHRl eHQgdGhhdCBtYW5kYXRlcyBIVFRQUy4gIEkgZG9uJ3QgdGhpbmsgSSBjYW4gYWRkIE1USSBjeXBo ZXINCj4gPiBzdWl0ZXMgYXQgdGhpcyBzdGFnZSwgYnV0IEkgdGhpbmsgaXQgd291bGQgYmUgT0sg dG8gYWRkIHRleHQgc3VjaCBhcyAiaXQgaXMNCj4gPiBSRUNPTU1FTkRFRCB0byB1c2Ugb25seSBz dWl0ZXMgdGhhdCBvZmZlciBQZXJmZWN0IEZvcndhcmQgU2VjcmVjeSAoUEZTKSBhbmQNCj4gPiBh dm9pZCBDaXBoZXIgQmxvY2sgQ2hhaW5pbmcgKENCQykiLCB3aXRoIHlvdXIgbGlzdCBvZiBzdWl0 ZXMgYXMgYW4gZXhhbXBsZS4NCj4gPiBXaGF0IGRvIHlvdSB0aGluaz8gIElmIHdlIGdvIHRoaXMg d2F5LCBJJ2QgcHJvYmFibHkgbmVlZCB0byBhbHNvIGFkZCBhbg0KPiA+IGluZm9ybWF0aW9uYWwg cmVmZXJlbmNlIG9yIHR3bzsgd2hhdCBkbyB5b3Ugc3VnZ2VzdD8NCj4gPg0KPiA+IEF0IDY6Mzkg UE0gLTA3MDAgOS8xNS8xNSwgTWFnbnVzIE55c3Ryw7ZtIHdyb3RlOg0KPiA+DQo+ID4gIEhpIFJh bmRhbGwsDQo+ID4+ICBZZXMsIEkgZ3Vlc3MgaXQgbWF5IGJlIHN1cnByaXNpbmcgLi4uIGJ1dCBJ IHdhcyB0aGlua2luZyBtb3JlIGFib3V0DQo+ID4+IGdldHRpbmcgdGhpcyBlZmZvcnQgaW1wbGVt ZW50ZWQgaW4gYW4gZXhwZWRpdGVkIGZhc2hpb24gcmF0aGVyIHRoYW4NCj4gPj4gcG90ZW50aWFs bHkgZGVsYXlpbmcgZHVlIHRvIHRoZSBwb3RlbnRpYWwgaXNzdWVzIChhbHNvIHBvaW50ZWQgb3V0 IGluIHRoZQ0KPiA+PiBkcmFmdCkgYXJvdW5kIGdldHRpbmcgdGhlIG5lY2Vzc2FyeSB0cnVzdCBh bmNob3JzIGluIHBsYWNlIGJldHdlZW4gUFNBUHMNCj4gPj4gYW5kIHNlcnZpY2UgcHJvdmlkZXJz IGVuYWJsaW5nIHRoZSBtdXR1YWwgYXV0aGVudGljYXRpb24uDQo+ID4+DQo+ID4+ICBJdCBtYXkg YmUgZ29vZCB0byBzYXkgc29tZXRoaW5nIGFib3V0IE1USSBzdWl0ZXMgLSBJIHdvdWxkIHN1Z2dl c3QNCj4gPj4gbWFuZGF0aW5nIHN1cHBvcnQgZm9yIGEgc2V0IG9mIHN1aXRlcyB0aGF0IG9mZmVy cyBQRlMgYW5kIGF2b2lkcyBDQkMsIGUuZy4sDQo+ID4+IHNvbWV0aGluZyBsaWtlOg0KPiA+Pg0K PiA+PiAgVExTX0VDREhFX0VDRFNBX1dJVEhfQUVTXzI1Nl9HQ01fU0hBMzg0DQo+ID4+DQo+ID4+ ICBUTFNfRUNESEVfRUNEU0FfV0lUSF9BRVNfMTI4X0dDTV9TSEEyNTYNCj4gPj4NCj4gPj4gIFRM U19FQ0RIRV9SU0FfV0lUSF9BRVNfMjU2X0dDTV9TSEEzODQNCj4gPj4NCj4gPj4gIFRMU19FQ0RI RV9SU0FfV0lUSF9BRVNfMTI4X0dDTV9TSEEyNTYNCj4gPj4NCj4gPj4gIFRMU19ESEVfUlNBX1dJ VEhfQUVTXzI1Nl9HQ01fU0hBMzg0DQo+ID4+DQo+ID4+ICBUTFNfREhFX1JTQV9XSVRIX0FFU18x MjhfR0NNX1NIQTI1Ng0KPiA+Pg0KPiA+Pg0KPiA+PiAgSSB3b3VsZCBhbHNvIHN1Z2dlc3QgbWFu ZGF0aW5nIFRMUyAxLjIgKG9yIGxhdGVyKSBmb3IgYSBuZXcgYXBwbGljYXRpb24NCj4gPj4gbGlr ZSB0aGlzLg0KPiA+PiAgT24gdGhlIGxhc3QgcG9pbnQsIHllcywgaWYgdGhlIHNlcnZpY2UgcHJv dmlkZXIgaXMgaW4gYSBwb3NzZXNzaW9uIHRvDQo+ID4+IHZvdWNoIGZvciBvciBzYW5pdHktY2hl Y2sgdGhlbiB0aGF0IGNvdWxkIGhlbHAgaW50cm9kdWNlIHJlbGlhYmlsaXR5Lg0KPiA+Pg0KPiA+ PiAgQmVzdCwNCj4gPj4NCj4gPj4NCj4gPj4gIE9uIFR1ZSwgU2VwIDE1LCAyMDE1IGF0IDU6NTgg UE0sIFJhbmRhbGwgR2VsbGVucyA8PG1haWx0bzoNCj4gPj4gcmFuZHlAcXRpLnF1YWxjb21tLmNv bT5yYW5keUBxdGkucXVhbGNvbW0uY29tPiB3cm90ZToNCj4gPj4NCj4gPj4gIEhpIE1hZ251cywN Cj4gPj4NCj4gPj4gIFRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLiAgUGxl YXNlIHNlZSBpbi1saW5lLg0KPiA+Pg0KPiA+PiAgQXQgOToyNiBQTSAtMDcwMCA4LzMxLzE1LCBN YWdudXMgTnlzdHLDtm0gd3JvdGU6DQo+ID4+DQo+ID4+ICAgSSBoYXZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncw0KPiA+PiBvbmdv aW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBi eSB0aGUgSUVTRy4NCj4gPj4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBm b3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWENCj4gPj4gZGlyZWN0b3JzLiBEb2N1 bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1 c3QNCj4gPj4gbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiA+Pg0KPiA+PiAg IFRoaXMgbWVtbyBwcm92aWRlcyBmdW5kYW1lbnRhbCBkYXRhIHN0cnVjdHVyZSBkZWZpbml0aW9u cyBhbmQNCj4gPj4gcHJvY2VkdXJhbCBydWxlcyBmb3IgcHJvdmlkaW5nIGF1eGlsaWFyeSBpbmZv cm1hdGlvbiB0byBwdWJsaWMgc2VydmljZQ0KPiA+PiBhbnN3ZXJpbmcgcG9pbnRzIChQU0FQcykg d2hlbiBlbWVyZ2VuY3kgY2FsbHMgYXJlIGJlaW5nIG1hZGUuDQo+ID4+DQo+ID4+DQo+ID4+ICAg VGhpcyByZWFkcyBhcyBhbiBpbXBvcnRhbnQgbWVtbyBhbmQgaGFzIGJlZW4gYXQgbGVhc3QgZml2 ZSB5ZWFycyBpbiB0aGUNCj4gPj4gbWFraW5nLiBJIGRvbid0IGZpbmQgdGhlIFNlY3VyaXR5IChh bmQgUHJpdmFjeSkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbg0KPiA+PiBsYWNraW5nIHBlciBzZSwg YnV0IGRvIGhhdmUgdGhlc2UgcXVlc3Rpb25zOg0KPiA+Pg0KPiA+PiAgIC0gV2h5IHJlcXVpcmUg SFRUUFMgZm9yIHRoZSByZWZlcmVuY2UgY2FzZSBidXQgbm90IHRoZSB2YWx1ZSBjYXNlIChJDQo+ ID4+IGNhbiB1bmRlcnN0YW5kIHdoeSB5b3UgZG9uJ3QgcmVxdWlyZSBpdCBmb3IgdGhlIHZhbHVl IGNhc2UsIGJ1dCBjb3VsZG4ndCBpdA0KPiA+PiBiZSBhIGNob2ljZSBmb3IgdGhlIFBTQVAgYWxz byBpbiB0aGUgcmVmZXJlbmNlIGNhc2U/IFRoaXMgd291bGQgYWxzbyBzZWVtDQo+ID4+IHRvIHNp bXBsaWZ5IGR1cmluZyBhbiBpbnRyb2R1Y3RvcnkgcGhhc2Ugd2hlbiBhIHdpZGUtc3ByZWFkIFBL SSBzb2x1dGlvbiBpcw0KPiA+PiBub3QgeWV0IGluIHBsYWNlLik/DQo+ID4+DQo+ID4+DQo+ID4+ ICBJJ20gdmVyeSBzdXJwcmlzZWQgdGhhdCBhIHNlY3VyaXR5IGFyZWEgcGVyc29uIGlzIGFza2lu ZyB3aHkgd2UgZG9uJ3QNCj4gPj4gbWFrZSBUTFMgb3B0aW9uYWwhICBJdCdzIGEgdmFsaWQgcXVl c3Rpb24sIG9mIGNvdXJzZSwganVzdCBzdXJwcmlzaW5nIGluDQo+ID4+IHRoaXMgY29udGV4dC4g IEJlY2F1c2Ugb2YgdGhlIGxpbWl0ZWQgc2NvcGUgb2YgdGhlIGRvY3VtZW50LCBzcGVjaWZpY2Fs bHkNCj4gPj4gZW1lcmdlbmN5IHNlcnZpY2VzLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZGVyZWZlcmVu Y2luZyBlbnRpdGllcyB3aWxsIGJlIFBTQVBzDQo+ID4+IGFuZCBvdGhlciByZXNwb25kZXJzIHRo YXQgaGF2ZSB1cGdyYWRlZCB0byBzdXBwb3J0IG5leHQtZ2VuZXJhdGlvbiwgd2UgZmVsdA0KPiA+ PiB0aGF0IGl0IHdhcyByZWFzb25hYmxlIHRvIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMgYW5kIGNs aWVudC1zaWRlDQo+ID4+IGNlcnRpZmljYXRlcyBmb3IgZGVyZWZlcmVuY2luZy4NCj4gPj4NCj4g Pj4gICAtIFdoZW4gSFRUUFMgaXMgcmVxdWlyZWQsIEkgYXNzdW1lIHRoZSBQU0FQIG5lZWRzIGEg Y2xpZW50IGNlcnRpZmljYXRlDQo+ID4+IC0gaS5lLiwgdGhhdCB0aGUgbXV0dWFsIGF1dGggb3B0 aW9uIG9mIFRMUyBpcyBiZWluZyB1c2VkLCBwZXJoYXBzIHRoaXMNCj4gPj4gbmVlZHMgdG8gYmUg Y2xhcmlmaWVkPw0KPiA+Pg0KPiA+Pg0KPiA+PiAgWWVzLCBnb29kIHBvaW50LiAgSSBhZGRlZCBj bGFyaWZ5aW5nIHRleHQgaW4gcmVzcG9uc2UgdG8gQmVuJ3MgY29tbWVudHMuDQo+ID4+DQo+ID4+ ICAgLSBXYXMgdGhlcmUgYW55IGRpc2N1c3Npb24gYXJvdW5kIGFueSBNVEkgVExTIGNpcGhlciBz dWl0ZXM/DQo+ID4+DQo+ID4+DQo+ID4+ICBObywgdGhpcyB3YXMgbmV2ZXIgZGlzY3Vzc2VkIGFz IGZhciBhcyBJIGNhbiByZWNhbGwuDQo+ID4+DQo+ID4+ICAgLSBJIGFzc3VtZSB0aGVyZSdzIG5v dCBvbmx5IGEgcHJpdmFjeSBpc3N1ZSBidXQgYWxzbyBhIHBvdGVudGlhbA0KPiA+PiBzcG9vZmlu ZyBpc3N1ZSAtIHRoZSBQU0FQcyBkb24ndCB3YW50IHRvIGJlIG92ZXJseSBzdXNjZXB0aWJsZSB0 byBzcG9vZmVkDQo+ID4+IGNhbGxzIChhbHRob3VnaCB0aGV5IHJhdGhlciBlcnIgb24gdGhlIHNp ZGUgb2Ygc2FmZXR5LCBvZiBjb3Vyc2UuIFRodXMsDQo+ID4+IHNob3VsZCBpbnRlZ3JpdHkgb2Yg aW5mb21hdGlvbiBpbiB0aGUgZGlyZWN0IGNhc2UgYmUgY29uc2lkZXJlZD8gSS5lLiwgYnkNCj4g Pj4gbi93IG9yIHNlcnZpY2UgcHJvdmlkZXJzIGluIHRoZSBwYXRoIHRvIHRoZSBQU0FQIHZvdWNo aW5nIGZvciB0aGUNCj4gPj4gaW5mb3JtYXRpb24/DQo+ID4+DQo+ID4+DQo+ID4+ICBZb3UncmUg YWJzb2x1dGVseSBjb3JyZWN0IHRoYXQgUFNBUHMgYXJlIGNvbmNlcm5lZCBhYm91dCBzcG9vZmVk IChhbmQNCj4gPj4gb3RoZXIgZmFsc2UpIGNhbGxzIGJ1dCB3aWxsIGdlbmVyYWxseSBlcnIgYnkg dGFraW5nIGEgY2FsbCBhbmQgYXNraW5nIHRoZQ0KPiA+PiBjYWxsZXIgZm9yIGluZm9ybWF0aW9u LiAgSW4gZ2VuZXJhbCwgUFNBUHMgcHJlZmVyIGluZm9ybWF0aW9uIHRoYXQgY29tZXMNCj4gPj4g ZnJvbSBrbm93biBhbmQgdHJ1c3RlZCBwcm92aWRlcnMgKHRoZSBtYWpvciBjYXJyaWVycykuIEFy ZSB5b3Ugc3VnZ2VzdGluZyBhDQo+ID4+IG1lY2hhbmlzbSBieSB3aGljaCBwcm92aWRlcnMgdmVy aWZ5IHRoZSBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSB0aGUgZGV2aWNlPw0KPiA+PiBGb3IgbG9j YXRpb24gaW5mb3JtYXRpb24sIHRoZXJlIGFyZSBkaXNjdXNzaW9ucyBpbiBvdGhlciBTRE9zIGFi b3V0DQo+ID4+IHNhbml0eS1jaGVja2luZyBkZXZpY2UtcHJvdmlkZWQgaW5mb3JtYXRpb24gKGxv Y2F0aW9uIG9yIFdpLUZpIEFQcykgYWdhaW5zdA0KPiA+PiBuZXR3b3JrLWtub3duIGluZm9ybWF0 aW9uIChtYWNybyBjZWxsIHRvIHdoaWNoIHRoZSBkZXZpY2UgaXMgYXNzb2NpYXRlZCkuDQo+ID4+ DQo+ID4+ICAtLQ0KPiA+PiAgUmFuZGFsbCBHZWxsZW5zDQo+ID4+ICBPcGluaW9ucyBhcmUgcGVy c29uYWw7ICAgIGZhY3RzIGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZvciBteXNlbGYgb25seQ0K PiA+PiAgLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0t LS0NCj4gPj4gIEluIGEgc2Vuc2UsIHdoZW4gd2Ugc3RhcnRlZCBWaXJnaW4gQXRsYW50aWMsIEkg d2FzIHRyeWluZyB0byBjcmVhdGUNCj4gPj4gIGFuIGFpcmxpbmUgZm9yIG15c2VsZi4gSWYgeW91 IHRyeSB0byBidWlsZCB0aGUgcGVyZmVjdCBhaXJsaW5lIGZvcg0KPiA+PiAgeW91cnNlbGYsIGl0 IHdpbGwgYmUgYXBwcmVjaWF0ZWQgYnkgb3RoZXJzLiAtLVJpY2hhcmQgQnJhbnNvbiwgMTk5Ni4N Cj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gIC0tDQo+ID4+DQo+ID4+ICAtLSBNYWdudXMN Cj4gPj4NCj4gPg0KPiA+DQo+ID4NCj4gPiAtLQ0KPiA+IFJhbmRhbGwgR2VsbGVucw0KPiA+IE9w aW5pb25zIGFyZSBwZXJzb25hbDsgICAgZmFjdHMgYXJlIHN1c3BlY3Q7ICAgIEkgc3BlYWsgZm9y IG15c2VsZiBvbmx5DQo+ID4gLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAt LS0tLS0tLS0tLS0tLS0NCj4gPiBBbGwgd2UncmUgc2VlaW5nIGlzIHRoZSBuZWdhdGl2ZSBzaWRl IG9mIG51Y2xlYXIgd2FyLg0KPiA+ICAgIC0tQmFycnkgR29sZHdhdGVyDQo+ID4NCj4gDQo+IA0K PiANCj4gLS0gDQo+IC0tIE1hZ251cw0KPg== From nobody Wed Sep 16 03:55:58 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABB31A6F9F for ; Wed, 16 Sep 2015 03:55:57 -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 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 wj3olpQA28-z for ; Wed, 16 Sep 2015 03:55:54 -0700 (PDT) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [207.82.80.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B771A6F84 for ; Wed, 16 Sep 2015 03:55:48 -0700 (PDT) Received: from emea-cam-gw2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-10-3MAizUhoQ02o6SqVZiDbSA-2; Wed, 16 Sep 2015 11:55:46 +0100 Received: from EMEA-CAM-GW3.Emea.Arm.com (10.1.106.86) by emea-cam-gw2.Emea.Arm.com (10.1.105.150) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 16 Sep 2015 11:55:40 +0100 Received: from george.Emea.Arm.com ([fe80::6ccb:73b1:f5c3:796]) by EMEA-CAM-GW3.Emea.Arm.com ([::1]) with mapi; Wed, 16 Sep 2015 11:55:40 +0100 From: Hannes Tschofenig To: "stephen.farrell@cs.tcd.ie" , "magnusn@gmail.com" Date: Wed, 16 Sep 2015 11:55:41 +0100 Thread-Topic: [secdir] Secdir review of draft-ietf-ecrit-additional-data Thread-Index: AdDwUqnlHP38AwnPTnKalfOVbYlGWAAG4svA Message-ID: References: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> In-Reply-To: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 X-MC-Unique: 3MAizUhoQ02o6SqVZiDbSA-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: "randy@qti.qualcomm.com" , "draft-ietf-ecrit-additional-data@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 10:55:57 -0000 SSB0aGluayBCQ1AxOTUgZG9lcyB0aGUgam9iIGZvciB1cy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHNlY2RpciBbbWFpbHRvOnNlY2Rpci1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2Ygc3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZQ0KU2VudDogMTYgU2VwdGVtYmVy IDIwMTUgMDk6MzgNClRvOiBtYWdudXNuQGdtYWlsLmNvbQ0KQ2M6IHJhbmR5QHF0aS5xdWFsY29t bS5jb207IGRyYWZ0LWlldGYtZWNyaXQtYWRkaXRpb25hbC1kYXRhQHRvb2xzLmlldGYub3JnOyBz ZWNkaXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2VjZGlyXSBTZWNkaXIgcmV2aWV3IG9mIGRy YWZ0LWlldGYtZWNyaXQtYWRkaXRpb25hbC1kYXRhDQoNCg0KDQpPbiBXZWQgU2VwIDE2IDA0OjA5 OjAzIDIwMTUgR01UKzAxMDAsIE1hZ251cyBOeXN0csO2bSB3cm90ZToNCj4gWWVzLCBhdCBsZWFz dCBtYW5kYXRpbmcgVExTIDEuMiBvciBoaWdoZXIgYW5kIHJlY29tbWVuZGluZyBhcyBwZXINCj4g YWJvdmUgc2VlbXMgcmVhc29uYWJsZS4NCj4gVGhlIHJlZmVyZW5jZXMgZm9yIHRoZSBHQ00gc3Vp dGVzIHdvdWxkIGJlIFJGQyA1Mjg4IGFuZCBSRkMgNTI4OS4NCg0KQkNQMTk1IGhhcyByZWNlbnQg cmVjb21tZW5kYXRpb25zIGZvciBtb3N0IFRMUyBvcHRpb25zLiBJJ2Qgc2F5IGl0J2QgYmUgYmVz dCB0byB1c2UgdGhvc2Ugb3IgaWYgbm90IGZpZ3VyZSBvdXQgd2h5IHRoZXkncmUgbm90IGNvcnJl Y3QgZm9yIHRoaXMgY29udGV4dC4NCg0KUy4NCg0KDQo+DQo+IFRoYW5rcyENCj4NCj4gT24gVHVl LCBTZXAgMTUsIDIwMTUgYXQgNzowNiBQTSwgUmFuZGFsbCBHZWxsZW5zDQo+IDxyYW5keUBxdGku cXVhbGNvbW0uY29tPg0KPiB3cm90ZToNCj4NCj4gPiBIaSBNYWdudXMsDQo+ID4NCj4gPiBJIHRo aW5rIHdlIGNhbiBtYW5kYXRlIFRMUyAxLjIgb3IgbGF0ZXIgd2l0aG91dCBhbnkgcHJvYmxlbSwg YW5kIEkNCj4gPiBjYW4gYWRkIHRoYXQgdG8gdGhlIHRleHQgdGhhdCBtYW5kYXRlcyBIVFRQUy4g IEkgZG9uJ3QgdGhpbmsgSSBjYW4NCj4gPiBhZGQgTVRJIGN5cGhlciBzdWl0ZXMgYXQgdGhpcyBz dGFnZSwgYnV0IEkgdGhpbmsgaXQgd291bGQgYmUgT0sgdG8NCj4gPiBhZGQgdGV4dCBzdWNoIGFz ICJpdCBpcyBSRUNPTU1FTkRFRCB0byB1c2Ugb25seSBzdWl0ZXMgdGhhdCBvZmZlcg0KPiA+IFBl cmZlY3QgRm9yd2FyZCBTZWNyZWN5IChQRlMpIGFuZCBhdm9pZCBDaXBoZXIgQmxvY2sgQ2hhaW5p bmcgKENCQykiLCB3aXRoIHlvdXIgbGlzdCBvZiBzdWl0ZXMgYXMgYW4gZXhhbXBsZS4NCj4gPiBX aGF0IGRvIHlvdSB0aGluaz8gIElmIHdlIGdvIHRoaXMgd2F5LCBJJ2QgcHJvYmFibHkgbmVlZCB0 byBhbHNvIGFkZA0KPiA+IGFuIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIG9yIHR3bzsgd2hhdCBk byB5b3Ugc3VnZ2VzdD8NCj4gPg0KPiA+IEF0IDY6MzkgUE0gLTA3MDAgOS8xNS8xNSwgTWFnbnVz IE55c3Ryw7ZtIHdyb3RlOg0KPiA+DQo+ID4gIEhpIFJhbmRhbGwsDQo+ID4+ICBZZXMsIEkgZ3Vl c3MgaXQgbWF5IGJlIHN1cnByaXNpbmcgLi4uIGJ1dCBJIHdhcyB0aGlua2luZyBtb3JlDQo+ID4+ IGFib3V0IGdldHRpbmcgdGhpcyBlZmZvcnQgaW1wbGVtZW50ZWQgaW4gYW4gZXhwZWRpdGVkIGZh c2hpb24NCj4gPj4gcmF0aGVyIHRoYW4gcG90ZW50aWFsbHkgZGVsYXlpbmcgZHVlIHRvIHRoZSBw b3RlbnRpYWwgaXNzdWVzIChhbHNvDQo+ID4+IHBvaW50ZWQgb3V0IGluIHRoZQ0KPiA+PiBkcmFm dCkgYXJvdW5kIGdldHRpbmcgdGhlIG5lY2Vzc2FyeSB0cnVzdCBhbmNob3JzIGluIHBsYWNlIGJl dHdlZW4NCj4gPj4gUFNBUHMgYW5kIHNlcnZpY2UgcHJvdmlkZXJzIGVuYWJsaW5nIHRoZSBtdXR1 YWwgYXV0aGVudGljYXRpb24uDQo+ID4+DQo+ID4+ICBJdCBtYXkgYmUgZ29vZCB0byBzYXkgc29t ZXRoaW5nIGFib3V0IE1USSBzdWl0ZXMgLSBJIHdvdWxkIHN1Z2dlc3QNCj4gPj4gbWFuZGF0aW5n IHN1cHBvcnQgZm9yIGEgc2V0IG9mIHN1aXRlcyB0aGF0IG9mZmVycyBQRlMgYW5kIGF2b2lkcw0K PiA+PiBDQkMsIGUuZy4sIHNvbWV0aGluZyBsaWtlOg0KPiA+Pg0KPiA+PiAgVExTX0VDREhFX0VD RFNBX1dJVEhfQUVTXzI1Nl9HQ01fU0hBMzg0DQo+ID4+DQo+ID4+ICBUTFNfRUNESEVfRUNEU0Ff V0lUSF9BRVNfMTI4X0dDTV9TSEEyNTYNCj4gPj4NCj4gPj4gIFRMU19FQ0RIRV9SU0FfV0lUSF9B RVNfMjU2X0dDTV9TSEEzODQNCj4gPj4NCj4gPj4gIFRMU19FQ0RIRV9SU0FfV0lUSF9BRVNfMTI4 X0dDTV9TSEEyNTYNCj4gPj4NCj4gPj4gIFRMU19ESEVfUlNBX1dJVEhfQUVTXzI1Nl9HQ01fU0hB Mzg0DQo+ID4+DQo+ID4+ICBUTFNfREhFX1JTQV9XSVRIX0FFU18xMjhfR0NNX1NIQTI1Ng0KPiA+ Pg0KPiA+Pg0KPiA+PiAgSSB3b3VsZCBhbHNvIHN1Z2dlc3QgbWFuZGF0aW5nIFRMUyAxLjIgKG9y IGxhdGVyKSBmb3IgYSBuZXcNCj4gPj4gYXBwbGljYXRpb24gbGlrZSB0aGlzLg0KPiA+PiAgT24g dGhlIGxhc3QgcG9pbnQsIHllcywgaWYgdGhlIHNlcnZpY2UgcHJvdmlkZXIgaXMgaW4gYSBwb3Nz ZXNzaW9uDQo+ID4+IHRvIHZvdWNoIGZvciBvciBzYW5pdHktY2hlY2sgdGhlbiB0aGF0IGNvdWxk IGhlbHAgaW50cm9kdWNlIHJlbGlhYmlsaXR5Lg0KPiA+Pg0KPiA+PiAgQmVzdCwNCj4gPj4NCj4g Pj4NCj4gPj4gIE9uIFR1ZSwgU2VwIDE1LCAyMDE1IGF0IDU6NTggUE0sIFJhbmRhbGwgR2VsbGVu cyA8PG1haWx0bzoNCj4gPj4gcmFuZHlAcXRpLnF1YWxjb21tLmNvbT5yYW5keUBxdGkucXVhbGNv bW0uY29tPiB3cm90ZToNCj4gPj4NCj4gPj4gIEhpIE1hZ251cywNCj4gPj4NCj4gPj4gIFRoYW5r IHlvdSBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLiAgUGxlYXNlIHNlZSBpbi1saW5lLg0K PiA+Pg0KPiA+PiAgQXQgOToyNiBQTSAtMDcwMCA4LzMxLzE1LCBNYWdudXMgTnlzdHLDtm0gd3Jv dGU6DQo+ID4+DQo+ID4+ICAgSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBv ZiB0aGUgc2VjdXJpdHkNCj4gPj4gZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZp ZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4NCj4gPj4g VGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2Yg dGhlDQo+ID4+IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBX RyBjaGFpcnMgc2hvdWxkDQo+ID4+IHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkg b3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiA+Pg0KPiA+PiAgIFRoaXMgbWVtbyBwcm92aWRl cyBmdW5kYW1lbnRhbCBkYXRhIHN0cnVjdHVyZSBkZWZpbml0aW9ucyBhbmQNCj4gPj4gcHJvY2Vk dXJhbCBydWxlcyBmb3IgcHJvdmlkaW5nIGF1eGlsaWFyeSBpbmZvcm1hdGlvbiB0byBwdWJsaWMN Cj4gPj4gc2VydmljZSBhbnN3ZXJpbmcgcG9pbnRzIChQU0FQcykgd2hlbiBlbWVyZ2VuY3kgY2Fs bHMgYXJlIGJlaW5nIG1hZGUuDQo+ID4+DQo+ID4+DQo+ID4+ICAgVGhpcyByZWFkcyBhcyBhbiBp bXBvcnRhbnQgbWVtbyBhbmQgaGFzIGJlZW4gYXQgbGVhc3QgZml2ZSB5ZWFycw0KPiA+PiBpbiB0 aGUgbWFraW5nLiBJIGRvbid0IGZpbmQgdGhlIFNlY3VyaXR5IChhbmQgUHJpdmFjeSkNCj4gPj4g Q29uc2lkZXJhdGlvbnMgc2VjdGlvbiBsYWNraW5nIHBlciBzZSwgYnV0IGRvIGhhdmUgdGhlc2Ug cXVlc3Rpb25zOg0KPiA+Pg0KPiA+PiAgIC0gV2h5IHJlcXVpcmUgSFRUUFMgZm9yIHRoZSByZWZl cmVuY2UgY2FzZSBidXQgbm90IHRoZSB2YWx1ZSBjYXNlDQo+ID4+IChJIGNhbiB1bmRlcnN0YW5k IHdoeSB5b3UgZG9uJ3QgcmVxdWlyZSBpdCBmb3IgdGhlIHZhbHVlIGNhc2UsIGJ1dA0KPiA+PiBj b3VsZG4ndCBpdCBiZSBhIGNob2ljZSBmb3IgdGhlIFBTQVAgYWxzbyBpbiB0aGUgcmVmZXJlbmNl IGNhc2U/DQo+ID4+IFRoaXMgd291bGQgYWxzbyBzZWVtIHRvIHNpbXBsaWZ5IGR1cmluZyBhbiBp bnRyb2R1Y3RvcnkgcGhhc2Ugd2hlbg0KPiA+PiBhIHdpZGUtc3ByZWFkIFBLSSBzb2x1dGlvbiBp cyBub3QgeWV0IGluIHBsYWNlLik/DQo+ID4+DQo+ID4+DQo+ID4+ICBJJ20gdmVyeSBzdXJwcmlz ZWQgdGhhdCBhIHNlY3VyaXR5IGFyZWEgcGVyc29uIGlzIGFza2luZyB3aHkgd2UNCj4gPj4gZG9u J3QgbWFrZSBUTFMgb3B0aW9uYWwhICBJdCdzIGEgdmFsaWQgcXVlc3Rpb24sIG9mIGNvdXJzZSwg anVzdA0KPiA+PiBzdXJwcmlzaW5nIGluIHRoaXMgY29udGV4dC4gIEJlY2F1c2Ugb2YgdGhlIGxp bWl0ZWQgc2NvcGUgb2YgdGhlDQo+ID4+IGRvY3VtZW50LCBzcGVjaWZpY2FsbHkgZW1lcmdlbmN5 IHNlcnZpY2VzLCBhbmQgZ2l2ZW4gdGhhdCB0aGUNCj4gPj4gZGVyZWZlcmVuY2luZyBlbnRpdGll cyB3aWxsIGJlIFBTQVBzIGFuZCBvdGhlciByZXNwb25kZXJzIHRoYXQgaGF2ZQ0KPiA+PiB1cGdy YWRlZCB0byBzdXBwb3J0IG5leHQtZ2VuZXJhdGlvbiwgd2UgZmVsdCB0aGF0IGl0IHdhcyByZWFz b25hYmxlDQo+ID4+IHRvIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMgYW5kIGNsaWVudC1zaWRlIGNl cnRpZmljYXRlcyBmb3IgZGVyZWZlcmVuY2luZy4NCj4gPj4NCj4gPj4gICAtIFdoZW4gSFRUUFMg aXMgcmVxdWlyZWQsIEkgYXNzdW1lIHRoZSBQU0FQIG5lZWRzIGEgY2xpZW50DQo+ID4+IGNlcnRp ZmljYXRlDQo+ID4+IC0gaS5lLiwgdGhhdCB0aGUgbXV0dWFsIGF1dGggb3B0aW9uIG9mIFRMUyBp cyBiZWluZyB1c2VkLCBwZXJoYXBzDQo+ID4+IHRoaXMgbmVlZHMgdG8gYmUgY2xhcmlmaWVkPw0K PiA+Pg0KPiA+Pg0KPiA+PiAgWWVzLCBnb29kIHBvaW50LiAgSSBhZGRlZCBjbGFyaWZ5aW5nIHRl eHQgaW4gcmVzcG9uc2UgdG8gQmVuJ3MgY29tbWVudHMuDQo+ID4+DQo+ID4+ICAgLSBXYXMgdGhl cmUgYW55IGRpc2N1c3Npb24gYXJvdW5kIGFueSBNVEkgVExTIGNpcGhlciBzdWl0ZXM/DQo+ID4+ DQo+ID4+DQo+ID4+ICBObywgdGhpcyB3YXMgbmV2ZXIgZGlzY3Vzc2VkIGFzIGZhciBhcyBJIGNh biByZWNhbGwuDQo+ID4+DQo+ID4+ICAgLSBJIGFzc3VtZSB0aGVyZSdzIG5vdCBvbmx5IGEgcHJp dmFjeSBpc3N1ZSBidXQgYWxzbyBhIHBvdGVudGlhbA0KPiA+PiBzcG9vZmluZyBpc3N1ZSAtIHRo ZSBQU0FQcyBkb24ndCB3YW50IHRvIGJlIG92ZXJseSBzdXNjZXB0aWJsZSB0bw0KPiA+PiBzcG9v ZmVkIGNhbGxzIChhbHRob3VnaCB0aGV5IHJhdGhlciBlcnIgb24gdGhlIHNpZGUgb2Ygc2FmZXR5 LCBvZg0KPiA+PiBjb3Vyc2UuIFRodXMsIHNob3VsZCBpbnRlZ3JpdHkgb2YgaW5mb21hdGlvbiBp biB0aGUgZGlyZWN0IGNhc2UgYmUNCj4gPj4gY29uc2lkZXJlZD8gSS5lLiwgYnkgbi93IG9yIHNl cnZpY2UgcHJvdmlkZXJzIGluIHRoZSBwYXRoIHRvIHRoZQ0KPiA+PiBQU0FQIHZvdWNoaW5nIGZv ciB0aGUgaW5mb3JtYXRpb24/DQo+ID4+DQo+ID4+DQo+ID4+ICBZb3UncmUgYWJzb2x1dGVseSBj b3JyZWN0IHRoYXQgUFNBUHMgYXJlIGNvbmNlcm5lZCBhYm91dCBzcG9vZmVkDQo+ID4+IChhbmQg b3RoZXIgZmFsc2UpIGNhbGxzIGJ1dCB3aWxsIGdlbmVyYWxseSBlcnIgYnkgdGFraW5nIGEgY2Fs bCBhbmQNCj4gPj4gYXNraW5nIHRoZSBjYWxsZXIgZm9yIGluZm9ybWF0aW9uLiAgSW4gZ2VuZXJh bCwgUFNBUHMgcHJlZmVyDQo+ID4+IGluZm9ybWF0aW9uIHRoYXQgY29tZXMgZnJvbSBrbm93biBh bmQgdHJ1c3RlZCBwcm92aWRlcnMgKHRoZSBtYWpvcg0KPiA+PiBjYXJyaWVycykuIEFyZSB5b3Ug c3VnZ2VzdGluZyBhIG1lY2hhbmlzbSBieSB3aGljaCBwcm92aWRlcnMgdmVyaWZ5IHRoZSBpbmZv cm1hdGlvbiBwcm92aWRlZCBieSB0aGUgZGV2aWNlPw0KPiA+PiBGb3IgbG9jYXRpb24gaW5mb3Jt YXRpb24sIHRoZXJlIGFyZSBkaXNjdXNzaW9ucyBpbiBvdGhlciBTRE9zIGFib3V0DQo+ID4+IHNh bml0eS1jaGVja2luZyBkZXZpY2UtcHJvdmlkZWQgaW5mb3JtYXRpb24gKGxvY2F0aW9uIG9yIFdp LUZpIEFQcykNCj4gPj4gYWdhaW5zdCBuZXR3b3JrLWtub3duIGluZm9ybWF0aW9uIChtYWNybyBj ZWxsIHRvIHdoaWNoIHRoZSBkZXZpY2UgaXMgYXNzb2NpYXRlZCkuDQo+ID4+DQo+ID4+ICAtLQ0K PiA+PiAgUmFuZGFsbCBHZWxsZW5zDQo+ID4+ICBPcGluaW9ucyBhcmUgcGVyc29uYWw7ICAgIGZh Y3RzIGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZvciBteXNlbGYgb25seQ0KPiA+PiAgLS0tLS0t LS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0tLS0gIEluIGEgc2Vu c2UsDQo+ID4+IHdoZW4gd2Ugc3RhcnRlZCBWaXJnaW4gQXRsYW50aWMsIEkgd2FzIHRyeWluZyB0 byBjcmVhdGUgIGFuIGFpcmxpbmUNCj4gPj4gZm9yIG15c2VsZi4gSWYgeW91IHRyeSB0byBidWls ZCB0aGUgcGVyZmVjdCBhaXJsaW5lIGZvciAgeW91cnNlbGYsDQo+ID4+IGl0IHdpbGwgYmUgYXBw cmVjaWF0ZWQgYnkgb3RoZXJzLiAtLVJpY2hhcmQgQnJhbnNvbiwgMTk5Ni4NCj4gPj4NCj4gPj4N Cj4gPj4NCj4gPj4NCj4gPj4gIC0tDQo+ID4+DQo+ID4+ICAtLSBNYWdudXMNCj4gPj4NCj4gPg0K PiA+DQo+ID4NCj4gPiAtLQ0KPiA+IFJhbmRhbGwgR2VsbGVucw0KPiA+IE9waW5pb25zIGFyZSBw ZXJzb25hbDsgICAgZmFjdHMgYXJlIHN1c3BlY3Q7ICAgIEkgc3BlYWsgZm9yIG15c2VsZiBvbmx5 DQo+ID4gLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0t LS0gQWxsIHdlJ3JlDQo+ID4gc2VlaW5nIGlzIHRoZSBuZWdhdGl2ZSBzaWRlIG9mIG51Y2xlYXIg d2FyLg0KPiA+ICAgIC0tQmFycnkgR29sZHdhdGVyDQo+ID4NCj4NCj4NCj4NCj4gLS0NCj4gLS0g TWFnbnVzDQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc2VjZGlyIG1haWxpbmcgbGlzdA0Kc2VjZGlyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpcg0Kd2lraTogaHR0cDovL3Rvb2xzLmlldGYub3Jn L2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZpZXcNCg0KLS0gSU1QT1JUQU5UIE5PVElDRTog VGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlk ZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0 IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55 IG1lZGl1bS4gIFRoYW5rIHlvdS4NCg0KQVJNIExpbWl0ZWQsIFJlZ2lzdGVyZWQgb2ZmaWNlIDEx MCBGdWxib3VybiBSb2FkLCBDYW1icmlkZ2UgQ0IxIDlOSiwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5k ICYgV2FsZXMsIENvbXBhbnkgTm86ICAyNTU3NTkwDQpBUk0gSG9sZGluZ3MgcGxjLCBSZWdpc3Rl cmVkIG9mZmljZSAxMTAgRnVsYm91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5TkosIFJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAmIFdhbGVzLCBDb21wYW55IE5vOiAgMjU0ODc4Mg0K From nobody Wed Sep 16 09:14:31 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E70E1A0275 for ; Wed, 16 Sep 2015 09:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 o5iegzKJqp0N for ; Wed, 16 Sep 2015 09:14:28 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F101A026E for ; Wed, 16 Sep 2015 09:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442420069; x=1473956069; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=3MlQFPYuNdznl48u/LFaTcwSATG1kJjFqHkJaYaNDhY=; b=O1KJwpFLcMq3zxNHrSUCRJ1qg8xgqYksJnrfUJmDzxMvKdIaXqSmZJgJ 2Lr+mxVhzPey2OEaStux8/dEDR44rQZvFUaFSNu9lzdjy0x9Esn+QBG/L oAIk7vfdYnauOJQIhs8NkOcXx4PrKTk0uAoai7trOAdNX+5pAC+SqoKUA s=; X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="97973667" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Sep 2015 09:14:09 -0700 X-IronPort-AV: E=Sophos;i="5.17,540,1437462000"; d="scan'208";a="1055867249" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Sep 2015 09:14:08 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 16 Sep 2015 09:14:07 -0700 Message-ID: In-Reply-To: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> References: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> X-Mailer: Eudora for Mac OS X Date: Wed, 16 Sep 2015 09:14:05 -0700 To: , , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 16:14:29 -0000 At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: > On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=F6m wrote: >> Yes, at least mandating TLS 1.2 or higher and recommending as per above >> seems reasonable. >> The references for the GCM suites would be RFC 5288 and RFC 5289. > > BCP195 has recent recommendations for most TLS=20 > options. I'd say it'd be best to use those or=20 > if not figure out why they're not correct for=20 > this context. Just to be clear: are you suggesting that we replace text suggested by Magnu= s: TLS MUST be version 1.2 or later. It is RECOMMENDED to use only cypher suites that offer Perfect Forward Secrecy (PFS) and avoid Cipher Block Chaining (CBC), for example, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. With this: TLS MUST be version 1.2 or later. It is RECOMMENDED follow [BCP195]. Note that BCP 195 does not address CBC (but does=20 discuss PFS). I just want to be clear before=20 making the change, so please confirm that this=20 works. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- If the odds are a million to one against something occurring, chances are 50-50 it will. From nobody Wed Sep 16 10:18:01 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C2D1A21AB for ; Wed, 16 Sep 2015 10:02: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 QUxoxY6TDQFU for ; Wed, 16 Sep 2015 10:02:39 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) by ietfa.amsl.com (Postfix) with ESMTP id C1D451A21A4 for ; Wed, 16 Sep 2015 10:02:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by chessie.everett.org (Postfix) with SMTP id BD18BB82B for ; Wed, 16 Sep 2015 17:02:38 +0000 (UTC) Received: from [10.2.64.185] (unknown [198.22.153.36]) by chessie.everett.org (Postfix) with ESMTPSA id 738CBB80E; Wed, 16 Sep 2015 17:02:36 +0000 (UTC) References: To: Sean Turner , draft-ietf-ntp-extension-field.all@tools.ietf.org, The IESG , secdir@ietf.org From: Danny Mayer Message-ID: <55F9A0AA.90300@pdmconsulting.net> Date: Wed, 16 Sep 2015 13:02:34 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Sep 16 17:02:38 2015 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 6780,55f9a0ae829931401138963 Archived-At: X-Mailman-Approved-At: Wed, 16 Sep 2015 10:18:00 -0700 Subject: Re: [secdir] secdir review of draft-ietf-ntp-extension-field X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mayer@pdmconsulting.net List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 17:02:42 -0000 Sorry for the delay in responding. I've been up to my ears in problems. See my feedback below. Danny On 8/27/2015 9:08 AM, Sean Turner wrote: > Fear not as this is just the secdir review! > > I have reviewed this document as part of the security directorates > 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. > > draft summary: This draft updates NTPv4 Protocol and Algorithm > Specification (aka RFC 5905) s7.5, which is the section that > describes extension fields, and to paraphrase the: clarify the > relationship between extension fields and MACs and define the > behavior of a host that receives an unknown extension field. Note > that when comparing the OLD section to RFC 5905, youll should note > that the OLD text incorporates a verified errata > (http://www.rfc-editor.org/errata_search.php?eid=3627). The NEW" > text requires things like when defining an extension the definition > must specify whether it must be MACed or not, the MTI MAC, the length > of the MAC, etc. > > secdir status summary: I need to clarify something in my mind, which > I hope fall into the you missed that in this spec over here or the > these are *NOT* the droids youre looking for bucket, before I can > say "ready with nits": > > 0) 7.5.1.1 says an extension can support multiple MACs, that the > extensions document defines the MTI algorithm & MAC length, and that > if more than one algorithm is allowed the extension includes an > indication of which one was actually used; all great. But, Im > trying to figure out how that fits with RFC 5905: > > - In s7.3, I see "dgst (128) in f8 > > - In s9.2, I see "There is no specific requirement for > authentication; however, if authentication is implemented, then the > MD5-keyed hash algorithm described in [RFC1321] must be supported > > Doesnt s7.3 limit the MAC to HMAC-MD5 and the length to 128? I mean > if youre going to allow an extension to override s9.2 that seems > like something worth noting in say the abstract/intro. Now that you bring this up, I should tell you that the reference implementation implements MD5 and NOT HMAC_MD5 but it also implements DES (not 3DES) and SHA-1! None of this is documented of course and the packets are inspected for which algorithm to use based on the size of the MAC field! Since there is no way to know from the packet whether there is one or more extension fields or if there is a MAC present the code ends up guessing which in turn limits the size that you can give an extension field. This all leads to the strange wording in section 7.5.1.3 and 7.5.1.4 in the draft and is necessary to detect the presence of a MAC. We probably need to update the dgest field in RFC5905 to make it clear that it can have multiple lengths depending on the algorithm used. On the other hand I would prefer to get rid of the MAC and turn it into an extension field, assuming that the NTS/CMS scheme is not used. The advantages of that is obvious especially as no guessing would be required and we could specify the algorithm to use and you could have multiple MAC extension fields that would cover different parts of the packet. > > Thinking theres got to be a reason for this I went off and looked at > the other NTP WG drafts after finding the NTS & CMS-based specs, > are the changes proposed in this draft to to allow an NTP packet blob > that doesnt use the MAC mechanism described in RFC 5905 but instead > use the NTS/CMS scheme, i.e., an NTP extension that is a CMS > object, with no MAC in the 5905 sense - the CMS object instead of the > NTP MAC field gives you the authentication? > > 1) s7.5.1.2 seems to be saying if extension A specifies alg X, and > extension B specifies alg X and Y, and extension C specifies alg Y > then extension A and B can appear together as can extension B and C, > but A and C cant appear together? Sounds great, but what if A and > C do appear together what happens? I think that the draft makes it clear that you cannot have that case since it requires that the MAC use one algorithm. "multiple extension fields that require a MAC they MUST all require use of the same algorithm and MAC length" > > 2) Still on 7.5.12: "If there are multiple extension fields that > require a MAC they MUST all require use of the same algorithm and MAC > length. > > So if I specify extension A with X as the MUST, and extension B with > X as the SHOULD and Y as the MUST, then I cant include both > extension A and B? Extension A requires X, but extension B requires > Y. That's right. > > 3) s7.5.1.3: Whats the 24-octet limitation based on? > The MAC guessing game. See the insanity above. > Minor: > > 0) The new s7.5 says: > > The Field Type field is specific to the defined function and is not > elaborated here. If a . > > 0.a) I think what youre trying to say is that the Field Type field > is defined in an IANA registry and its length and value are defined > by the document referred to by the registry? > Yes. > 0.b) Neither RFC5905 nor this document specify how the padding is > done. Is padding determined by the document referred to by the field > type? I.e., can I do padding with all 1s and somebody else do it > with all zeros? > It shouldn't matter. If the extension field specification needs it to be specific it should state that in the specification. > Maybe: > > The Field Type field defines the extensions semantics as well as the > extensions syntax, i.e., length, value, and padding. This > document defines no extensions. > Yes. > If a > > Nits: > > 0) process wise: RFC 5905 has a lot of other errata; some marked > verified some marked HFDU. Since this document updates RFC 5905, did > the WG consider including the other verified errata and resolving > whether the errata marked HFDU were worth including? Ill also > readily admit that this could have been found in the WG archives, but > I didnt search them. > We didn't consider this. We were only concentrating of the extension field specification and MAC. This was never meant as a proposed REF5905bis. > 1) s3: Might be worth noting that the OLD text includes the errata > text. I cant remember whether you can normatively or informatively > point to errata (sorry). > > 2) The new s7.5 includes: > > If a host receives an extension field with an unknown Field Type > value > > I was like hmm theres a Field Type value, which is # that goes in > Field Type and theres the Value field for the Field Type. Maybe > dropping value from the quoted sentence makes it clearer that > youre really talking about the # that goes in Field Type and not the > Value? It's supposed to be the value of the field type. > > 2) s5: Might be worth a reference to the NTP Extension Field Type > IANA registry. Though obviously folks reading the base spec and > extensions are going to find it though. > true. > spt > > PS - RFC 5905 KoD packets are my favorite packets now. > From nobody Wed Sep 16 10:31:43 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D911B40AE for ; Wed, 16 Sep 2015 10:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 qBdLzmnMS_Ya for ; Wed, 16 Sep 2015 10:31:41 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 077B01B40AD for ; Wed, 16 Sep 2015 10:31:41 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so84210990wic.1 for ; Wed, 16 Sep 2015 10:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wb50QZFsIvSZweBzvo7wIuFxAwScvzyeNDp+Qsi4D7M=; b=LHGqhsYV/bP9dU1y98LBniOGEJeKU9zwpaPAlv3Z9f6n1OBAU9TvriUhgPTHsX/SpK XhMTpicA00JszJ+nn0rDq1pBpX5QRPNwn/UyS3qy4GFMw7w0osG9MlEzMUAresVrZEpS nz1CoKrx8rnLC1tYIETXaNNLqPSfRW8HPyd3cOzsvdTnjGD17+5MZhwpLCp17y2/P2t2 RMGhm7iaU4jfElXpV/qwK9r+GBjA6jhv6oIgmHTjXnwB1voqoE0VsswNKdEEwkBxQ3l2 d5pYLXIsg3oKZFJFpQnejX4FfARvJq7DMwKZuBDq/siD17BWrABdhhV20WdGSXLKA5+v 9YvQ== MIME-Version: 1.0 X-Received: by 10.194.205.68 with SMTP id le4mr26213744wjc.74.1442424699516; Wed, 16 Sep 2015 10:31:39 -0700 (PDT) Received: by 10.27.130.200 with HTTP; Wed, 16 Sep 2015 10:31:39 -0700 (PDT) In-Reply-To: References: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> Date: Wed, 16 Sep 2015 10:31:39 -0700 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: Randall Gellens Content-Type: multipart/alternative; boundary=001a11c33fa8d47f29051fe0ab14 Archived-At: Cc: "secdir@ietf.org" , draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 17:31:42 -0000 --001a11c33fa8d47f29051fe0ab14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just a personal remark: BCP 195 still allows earlier versions of TLS, even TLS 1.0. I felt that for a new application like this, one could go stronger. Maybe a combo - where you rely on BCP 195 but mandate TLS 1.2 (or later)? On Wed, Sep 16, 2015 at 9:14 AM, Randall Gellens wrote: > At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: > > On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=C3=B6m wrote: >> >>> Yes, at least mandating TLS 1.2 or higher and recommending as per abov= e >>> seems reasonable. >>> The references for the GCM suites would be RFC 5288 and RFC 5289. >>> >> >> BCP195 has recent recommendations for most TLS options. I'd say it'd be >> best to use those or if not figure out why they're not correct for this >> context. >> > > Just to be clear: are you suggesting that we replace text suggested by > Magnus: > > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > cypher suites that offer Perfect Forward Secrecy (PFS) and avoid > Cipher Block Chaining (CBC), for example, > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. > > With this: > > TLS MUST be version 1.2 or later. It is RECOMMENDED follow > [BCP195]. > > > Note that BCP 195 does not address CBC (but does discuss PFS). I just > want to be clear before making the change, so please confirm that this > works. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > If the odds are a million to one against something occurring, chances > are 50-50 it will. > --=20 -- Magnus --001a11c33fa8d47f29051fe0ab14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just a personal remark: BCP 195 still allows earlier versi= ons of TLS, even TLS 1.0. I felt that for a new application like this, one = could go stronger. Maybe=C2=A0 a combo - where you rely on BCP 195 but mand= ate TLS 1.2 (or later)?

On Wed, Sep 16, 2015 at 9:14 AM, Randall Gellens <randy@q= ti.qualcomm.com> wrote:
At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote:

=C2=A0On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=C3=B6m wrote:
=C2=A0Yes, at least mandating TLS 1.2 or higher and recommending as per abo= ve
=C2=A0seems reasonable.
=C2=A0The references for the GCM suites would be RFC 5288 and RFC 5289.

=C2=A0BCP195 has recent recommendations for most TLS options. I'd say i= t'd be best to use those or if not figure out why they're not corre= ct for this context.

Just to be clear: are you suggesting that we replace text suggested by Magn= us:

=C2=A0 =C2=A0TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED to u= se only
=C2=A0 =C2=A0cypher suites that offer Perfect Forward Secrecy (PFS) and avo= id
=C2=A0 =C2=A0Cipher Block Chaining (CBC), for example,
=C2=A0 =C2=A0TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
=C2=A0 =C2=A0TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
=C2=A0 =C2=A0TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
=C2=A0 =C2=A0TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
=C2=A0 =C2=A0TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
=C2=A0 =C2=A0TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289].

With this:

=C2=A0 =C2=A0TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED foll= ow
=C2=A0 =C2=A0[BCP195].


Note that BCP 195 does not address CBC (but does discuss PFS).=C2=A0 I just= want to be clear before making the change, so please confirm that this wor= ks.

--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
If the odds are a million to one against something occurring, chances
are 50-50 it will.



--
-- Magnus
--001a11c33fa8d47f29051fe0ab14-- From nobody Wed Sep 16 10:58:08 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2FE1A7014 for ; Wed, 16 Sep 2015 10:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 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, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=0.723, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Zx9ATeVvgkVd for ; Wed, 16 Sep 2015 10:58:04 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF24B1A6FFE for ; Wed, 16 Sep 2015 10:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442426284; x=1473962284; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=n4b4XZHQOvSaA15lJxspBMv6Z07zvbkhdgiIpEJNRiE=; b=uLtfeES28TE5ElLvFOtpCjUXLEpQe6v36MNmzZzkWUcz69nFkGklGz0C nk2SAuVDnx8wjcf2JRieqslmi7oFvQfdWK4XrF3kwkw1ZVk6yYEpqoulg LkgQfl47pD81fWmK2eWhxnW/6gSx+BsSDYKcdqqzYhDtCWe3rozuDVcUH U=; X-IronPort-AV: E=McAfee;i="5700,7163,7926"; a="97979683" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Sep 2015 10:58:04 -0700 X-IronPort-AV: E=Sophos;i="5.17,540,1437462000"; d="scan'208,217";a="1002870692" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Sep 2015 10:58:04 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 16 Sep 2015 10:58:03 -0700 Message-ID: In-Reply-To: References: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> X-Mailer: Eudora for Mac OS X Date: Wed, 16 Sep 2015 10:57:59 -0700 To: Magnus =?iso-8859-1?Q?Nystr=F6m?= From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: "secdir@ietf.org" , draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 17:58:06 -0000 Re: [secdir] Secdir review of draft-ietf-ecrit-additional-
At 10:31 AM -0700 9/16/15, Magnus Nystr=F6m wrote:

Just a personal remark: BCP 195 still allows earlier versions of TLS, even TLS 1.0. I felt that for a new application like this, one could go stronger. Maybe  a combo - where you rely on BCP 195 but mandate TLS 1.2 (or later)?


And not mention CBC?



On Wed, Sep 16, 2015 at 9:14 AM, Randall Gellens <randy@qti.qualcomm.com> wrote:
At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote:
 On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=F6m wrote:
 Yes, at least mandating TLS 1.2 or higher and recommending as per above
 seems reasonable.
 The references for the GCM suites would be RFC 5288 and RFC 5289.

 BCP195 has recent recommendations for most TLS options. I'd say it'd be best to use those or if not figure out why they're not correct for this context.

Just to be clear: are you suggesting that we replace text suggested by Magnus:

   TLS MUST be version 1.2 or later.  It is RECOMMENDED to use only
   cypher suites that offer Perfect Forward Secrecy (PFS) and avoid
   Cipher Block Chaining (CBC), for example,
   TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289].

With this:

   TLS MUST be version 1.2 or later.  It is RECOMMENDED follow
   [BCP195].


Note that BCP 195 does not address CBC (but does discuss PFS).  I just want to be clear before making the change, so please confirm that this works.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If the odds are a million to one against something occurring, chances
are 50-50 it will.



--
-- Magnus



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Between two evils, I always pick the one I never tried before.
                                                  --Mae West.
From nobody Wed Sep 16 11:02:41 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9186C1B40CE for ; Wed, 16 Sep 2015 11:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham 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 34cBcKHnFh3l for ; Wed, 16 Sep 2015 11:02:37 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 69D031B40B9 for ; Wed, 16 Sep 2015 11:02:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8435122405FB; Wed, 16 Sep 2015 20:02:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6rsYsiFrzV1; Wed, 16 Sep 2015 20:02:36 +0200 (CEST) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id A30DF22404D9; Wed, 16 Sep 2015 20:02:35 +0200 (CEST) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Sep 2015 14:02:33 -0400 Message-Id: <6FD706E2-FEAC-4EF2-BCE8-43D16095BB11@deployingradius.com> To: secdir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-ippm-owamp-registry@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-ippm-owamp-registry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:02:39 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document requests IANA allocation of registries for OWAMP. As = such, it has minimal security impact. One practical note is the request to assign an "Experimentation" = OWAMP-Control Command Number. Experience shows that such numbers are = either never used, or used as experiments... which then get widely = deployed before standards action catches up to practical needs. It may be good to add some discussion as to *how* experiments are = done, and how experiments can transition from the "Experimentation" = number to a standard number. One suggestion would be to change the label from "Experimentation" to = "Site-Local". That would still allow sites to experiment with = OWAMP-Control commands, but would make it clearer that such = experimentation is only for the local site, and MUST NOT be used in a = wider context.= From nobody Wed Sep 16 11:19:17 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE72F1A87E9 for ; Wed, 16 Sep 2015 11:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 ZzIaEpJgH1Ru for ; Wed, 16 Sep 2015 11:19:13 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 4BD0E1A87C9 for ; Wed, 16 Sep 2015 11:19:13 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so82289489wic.0 for ; Wed, 16 Sep 2015 11:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sJYrtsU3RpzFpwTFYeJyDKCjH+Sm4TgNKgzDKMEfZCs=; b=qviTXQ9eQstrOX4baepNb9jtll6mRVuJmcWKJ/R8silLAr6jldpPKP+N4TsAMOutwc 4Z/k/EiqpjKgOHrHcdZ6UbMU7smyZqDyTvr1XliGrnR3/h76QAqAxe+KMaygho2y20Al aSAN8NLJzl5wj03xCtita2uQ6DDrpZsrIoy49Mq2eAqWXtPUPNrFJFvuwTkDSyTjcwzB w4O4WtJ3Q/s5Ap10X3EbuRTeGNkOY8Y/uQatLsxdAoQu66A6i4eveFbDXTddWMsUZuMI rSqCzQISpGH/UjZaR98CPzUIm4SZr+X3svu1Quu3O/TxctKiB/WaMPdKHa9e7LMfqOOG cw+A== MIME-Version: 1.0 X-Received: by 10.194.205.68 with SMTP id le4mr26673021wjc.74.1442427551870; Wed, 16 Sep 2015 11:19:11 -0700 (PDT) Received: by 10.27.130.200 with HTTP; Wed, 16 Sep 2015 11:19:11 -0700 (PDT) In-Reply-To: References: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> Date: Wed, 16 Sep 2015 11:19:11 -0700 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: Randall Gellens Content-Type: multipart/alternative; boundary=001a11c33fa8d7f419051fe1559c Archived-At: Cc: "secdir@ietf.org" , draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:19:15 -0000 --001a11c33fa8d7f419051fe1559c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, yes, also mention no CBC On Wed, Sep 16, 2015 at 10:57 AM, Randall Gellens wrote: > At 10:31 AM -0700 9/16/15, Magnus Nystr=C3=B6m wrote: > > Just a personal remark: BCP 195 still allows earlier versions of TLS, eve= n > TLS 1.0. I felt that for a new application like this, one could go > stronger. Maybe a combo - where you rely on BCP 195 but mandate TLS 1.2 > (or later)? > > > > And not mention CBC? > > > > On Wed, Sep 16, 2015 at 9:14 AM, Randall Gellens > wrote: > > At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: > > On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=C3=B6m wrote: > > Yes, at least mandating TLS 1.2 or higher and recommending as per above > seems reasonable. > The references for the GCM suites would be RFC 5288 and RFC 5289. > > > BCP195 has recent recommendations for most TLS options. I'd say it'd be > best to use those or if not figure out why they're not correct for this > context. > > > Just to be clear: are you suggesting that we replace text suggested by > Magnus: > > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > cypher suites that offer Perfect Forward Secrecy (PFS) and avoid > Cipher Block Chaining (CBC), for example, > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. > > With this: > > TLS MUST be version 1.2 or later. It is RECOMMENDED follow > [BCP195]. > > > Note that BCP 195 does not address CBC (but does discuss PFS). I just > want to be clear before making the change, so please confirm that this > works. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > If the odds are a million to one against something occurring, chances > are 50-50 it will. > > > > > -- > > -- Magnus > > > > > -- > > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Between two evils, I always pick the one I never tried before. > --Mae West. > --=20 -- Magnus --001a11c33fa8d7f419051fe1559c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, yes, also mention no CBC

On Wed, Sep 16, 2015 at 10:57 AM, Rand= all Gellens <randy@qti.qualcomm.com> wrote:
At 10:31 AM -0700 9/16/15, Magnus Nystr=C3=B6m wrote:

Just a personal remark: BCP 195 still allows earlier versions of TLS, even TLS 1.0. I felt that for a new application like this, one could go stronger. Maybe=C2=A0 a combo - where you rely on BCP 195 but mandate TLS 1.2 (or later)?


And not mention CBC?



On Wed, Sep 16, 2015 at 9:14 AM, Randall Gellens <ran= dy@qti.qualcomm.com> wrote:
At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote:
=C2=A0On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=C3=B6m wrote:
=C2=A0Yes, at least mandating TLS 1.2 or higher and recommending as per above
=C2=A0seems reasonable.
=C2=A0The references for the GCM suites would be RFC 5288 and RFC 5289.

=C2=A0BCP195 has recent recommendations for most TLS options. I'd say it'd be best to use those or if not figure out why they're not corr= ect for this context.

Just to be clear: are you suggesting that we replace text suggested by Magnus:

=C2=A0 =C2=A0TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED to use only
=C2=A0 =C2=A0cypher suites that offer Perfect Forward Secrecy (PFS) and avoid
=C2=A0 =C2=A0Cipher Block Chaining (CBC), for example,
=C2=A0 =C2=A0TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
=C2=A0 =C2=A0TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
=C2=A0 =C2=A0TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
=C2=A0 =C2=A0TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
=C2=A0 =C2=A0TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
=C2=A0 =C2=A0TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289].

With this:

=C2=A0 =C2=A0TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED follow
=C2=A0 =C2=A0[BCP195].


Note that BCP 195 does not address CBC (but does discuss PFS).=C2=A0 I just want to be clear before making the change, so please confirm that this works.

--
Randall Gellens
Opinions are personal;=C2=A0=C2=A0=C2=A0 facts are suspect;=C2=A0=C2=A0=C2=A0 I speak for myself only
-------------- Randomly selected tag: ---------------
If the odds are a million to one against something occurring, chances
are 50-50 it will.



--
-- Magnus



--=20
Randall Gellens
Opinions are personal;=C2=A0=C2=A0=C2=A0 facts are suspect;=C2=A0=C2=A0=C2=A0 I speak for myself only
-------------- Randomly selected tag: ---------------
Between two evils, I always pick the one I never tried before.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0--Mae West.



--
-- Magnus
--001a11c33fa8d7f419051fe1559c-- From nobody Wed Sep 16 11:25:45 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8A21A8AF5 for ; Wed, 16 Sep 2015 11:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.711 X-Spam-Level: X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 x9M6wOAxPhrX for ; Wed, 16 Sep 2015 11:25:43 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7AB1A8AB2 for ; Wed, 16 Sep 2015 11:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442427943; x=1473963943; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=TiouLSSqjy1DmCbzJTYZdGcpoWmnIIvzh9L0RIsTArw=; b=GaKFXPIHYdDSY5p1Kysg4Jfo1kkAEpHfG4tp9COriQCVIUGIupjCGi1e EwEr4B1a56BY1tzzXIH2HJ/bsARK3jNK32rWrPPxd1og9HBEwC4wR5GfX ZniUnOiAGBiAuiAP2ygAyW07VIbxfE0wWGUM01SJZdKB/9MMKzQTLbOUI 8=; X-IronPort-AV: E=McAfee;i="5700,7163,7926"; a="97981420" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 16 Sep 2015 11:25:42 -0700 X-IronPort-AV: E=Sophos;i="5.17,540,1437462000"; d="scan'208";a="33681572" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Sep 2015 11:25:41 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 16 Sep 2015 11:25:40 -0700 Message-ID: In-Reply-To: References: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> X-Mailer: Eudora for Mac OS X Date: Wed, 16 Sep 2015 11:25:37 -0700 To: Magnus =?iso-8859-1?Q?Nystr=F6m?= From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: "secdir@ietf.org" , draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:25:44 -0000 How do we want to word this? The original wording based on your suggestions was: TLS MUST be version 1.2 or later. It is RECOMMENDED to use only cypher suites that offer Perfect Forward Secrecy (PFS) and avoid Cipher Block Chaining (CBC), for example, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. The next revision was: TLS MUST be version 1.2 or later. It is RECOMMENDED follow [BCP195]. So how to we want to work CBC in to this? And if=20 we do, does that mean we need to also mention the=20 specific cypher suites? At 11:19 AM -0700 9/16/15, Magnus Nystr=F6m wrote: > Sorry, yes, also mention no CBC > > On Wed, Sep 16, 2015 at 10:57 AM, Randall=20 > Gellens=20 > <randy@qti.qualcomm.com>=20 > wrote: > > At 10:31 AM -0700 9/16/15, Magnus Nystr=F6m wrote: > >> Just a personal remark: BCP 195 still allows=20 >> earlier versions of TLS, even TLS 1.0. I felt=20 >> that for a new application like this, one=20 >> could go stronger. Maybe a combo - where you=20 >> rely on BCP 195 but mandate TLS 1.2 (or later)? >> > > > And not mention CBC? > > >> > On Wed, Sep 16, 2015 at 9:14 AM, Randall=20 > Gellens=20 > <randy@qti.qualcomm.com>=20 > wrote: > > At 7:38 AM +0000 9/16/15,=20 > stephen.farrell@cs.tcd.ie=20 > wrote: > > On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=F6m wrote: > > Yes, at least mandating TLS 1.2 or higher and recommending as per above > seems reasonable. > The references for the GCM suites would be RFC 5288 and RFC 5289. > > > BCP195 has recent recommendations for most TLS=20 > options. I'd say it'd be best to use those or=20 > if not figure out why they're not correct for=20 > this context. > > > Just to be clear: are you suggesting that we=20 > replace text suggested by Magnus: > > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > cypher suites that offer Perfect Forward Secrecy (PFS) and avoid > Cipher Block Chaining (CBC), for example, > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. > > With this: > > TLS MUST be version 1.2 or later. It is RECOMMENDED follow > [BCP195]. > > > Note that BCP 195 does not address CBC (but=20 > does discuss PFS). I just want to be clear=20 > before making the change, so please confirm=20 > that this works. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > If the odds are a million to one against something occurring, chances > are 50-50 it will. > > > > > -- > > -- Magnus > > > > > -- > > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > > Between two evils, I always pick the one I never tried before. > --Mae West. > > > > > -- > > -- Magnus -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Total deregulation would allow anybody to fly any route, a situation that is unlikely ever to occur. --New York Times Magazine, 9 May 1976. From nobody Wed Sep 16 11:50:29 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0021A8A9B for ; Wed, 16 Sep 2015 11:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 I7T9Y08ff3FS for ; Wed, 16 Sep 2015 11:50:22 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::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 0AD6A1A8A75 for ; Wed, 16 Sep 2015 11:50:22 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so83754820wic.1 for ; Wed, 16 Sep 2015 11:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IoIKU/t3lFrhphbAUq2z9z5Yvum8dH8lbKuaajUwFHk=; b=NzGXyuGatCUMAI9YRsMdRz1lP18iGk4txwTJUhBRycUo63Fhh4dQ0l/sdUd4/S4MVV eu6zvDH+TK1inJLBy3XAHT9Vwome3PIgQxhH4YMfJwNgpWdCObROCjYG7roge3mdt5/M NNHk8AxwMSZM9xFWCR2pnwV6w5/pTtwyGk7KcVVGGsewkt0yMOPcZBljN3lFUM8Y4ptZ z/jWzCD1S6Hii6RfthSLq4C5HjbWayCRkW0hs+n+5y6L0CHbN/IgXqV+rLWKDBa+Q7F7 fmq7DAS3qW2l7DTMD85Unu4gX/fdyQUkTH9U4lVGYN0x0cNK8QBdU5lescboJO/iRhvS p7gw== MIME-Version: 1.0 X-Received: by 10.180.21.137 with SMTP id v9mr21168519wie.8.1442429420584; Wed, 16 Sep 2015 11:50:20 -0700 (PDT) Received: by 10.27.130.200 with HTTP; Wed, 16 Sep 2015 11:50:20 -0700 (PDT) In-Reply-To: <4EE7311A-C4AA-4153-8B19-2C3175F03D89@brianrosen.net> References: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> <4EE7311A-C4AA-4153-8B19-2C3175F03D89@brianrosen.net> Date: Wed, 16 Sep 2015 11:50:20 -0700 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: Brian Rosen Content-Type: multipart/alternative; boundary=047d7b873c423a466e051fe1c572 Archived-At: Cc: "secdir@ietf.org" , Randall Gellens , draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:50:23 -0000 --047d7b873c423a466e051fe1c572 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That looks good to me. On Wed, Sep 16, 2015 at 11:32 AM, Brian Rosen wrote: > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > cipher suites that offer Perfect Forward Secrecy (PFS), avoid > Cipher Block Chaining (CBC) and follow the recommendations in BCP195. > > > On Sep 16, 2015, at 12:14 PM, Randall Gellens > wrote: > > > > At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: > > > >> On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=C3=B6m wrote: > >>> Yes, at least mandating TLS 1.2 or higher and recommending as per abo= ve > >>> seems reasonable. > >>> The references for the GCM suites would be RFC 5288 and RFC 5289. > >> > >> BCP195 has recent recommendations for most TLS options. I'd say it'd b= e > best to use those or if not figure out why they're not correct for this > context. > > > > Just to be clear: are you suggesting that we replace text suggested by > Magnus: > > > > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > > cypher suites that offer Perfect Forward Secrecy (PFS) and avoid > > Cipher Block Chaining (CBC), for example, > > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. > > > > With this: > > > > TLS MUST be version 1.2 or later. It is RECOMMENDED follow > > [BCP195]. > > > > > > Note that BCP 195 does not address CBC (but does discuss PFS). I just > want to be clear before making the change, so please confirm that this > works. > > > > -- > > Randall Gellens > > Opinions are personal; facts are suspect; I speak for myself only > > -------------- Randomly selected tag: --------------- > > If the odds are a million to one against something occurring, chances > > are 50-50 it will. > > --=20 -- Magnus --047d7b873c423a466e051fe1c572 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That looks good to me.
On Wed, Sep 16, 2015 at 11:32 AM, Brian Rosen <= span dir=3D"ltr"><br@brianrosen.net> wrote:
= TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED to use only=
=C2=A0 cipher suites that offer Perfect Forward Secrecy (PFS), avoid=
=C2=A0 Cipher Block Chaining (CBC) and follow the recommendations in BCP195= .

> On Sep 16, 2015, at 12:14 PM, Randall Gellens <randy@qti.qualcomm.com> wrote:
>
> At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote:
>
>> On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=C3=B6m wrote: >>> Yes, at least mandating TLS 1.2 or higher and recommending as = per above
>>> seems reasonable.
>>> The references for the GCM suites would be RFC 5288 and RFC 52= 89.
>>
>> BCP195 has recent recommendations for most TLS options. I'd sa= y it'd be best to use those or if not figure out why they're not co= rrect for this context.
>
> Just to be clear: are you suggesting that we replace text suggested by= Magnus:
>
>=C2=A0 =C2=A0TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED = to use only
>=C2=A0 =C2=A0cypher suites that offer Perfect Forward Secrecy (PFS) and= avoid
>=C2=A0 =C2=A0Cipher Block Chaining (CBC), for example,
>=C2=A0 =C2=A0TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
>=C2=A0 =C2=A0TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
>=C2=A0 =C2=A0TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
>=C2=A0 =C2=A0TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>=C2=A0 =C2=A0TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
>=C2=A0 =C2=A0TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. >
> With this:
>
>=C2=A0 =C2=A0TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED = follow
>=C2=A0 =C2=A0[BCP195].
>
>
> Note that BCP 195 does not address CBC (but does discuss PFS).=C2=A0 I= just want to be clear before making the change, so please confirm that thi= s works.
>
> --
> Randall Gellens
> Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I = speak for myself only
> -------------- Randomly selected tag: ---------------
> If the odds are a million to one against something occurring, chances<= br> > are 50-50 it will.




--
-- Magnus
--047d7b873c423a466e051fe1c572-- From nobody Wed Sep 16 11:52:26 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701C71A8897 for ; Wed, 16 Sep 2015 11:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 k4eR4_2pdgrk for ; Wed, 16 Sep 2015 11:32:52 -0700 (PDT) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) (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 26B3F1A88A0 for ; Wed, 16 Sep 2015 11:32:49 -0700 (PDT) Received: by qkfq186 with SMTP id q186so90299958qkf.1 for ; Wed, 16 Sep 2015 11:32:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=sdJKgzJfazeDHOSnFVjpw+8pBdBGGWsJcH1kvZv8+Y8=; b=h0z47MwIdlNObSnw6OCehymTB4ADqqoQHIpZpEdCG4v7rzDepJKLMaoTNSy5OK4Opf 2W/YG/Ljyig/MGfrhqQO6HiDI5suV04VOENFRrU3/jVHDdj9gyNcR1z2gNPnrMJtf0fg kaYQmVT4qjtuhtQbNkZHjsKu22fnObAK34l8TyErGkb6UAGhn5rd49mSqpbl46R4sHI4 XNH4IGcBi3NasH42qbelDzGcSRqbF/N2rAtXQdtTQnXyHEMj2zZx7DMyPuGf2lkjsNON nN8Zyg3zsVG6i6YGXlVazzxIaEJazQ45z+gMl43PFEPiSgmKx/p/U4PQoDjY93wJhom5 bjcg== X-Gm-Message-State: ALoCoQnxayrzE8Zuyl8szuVSWsQ4B41F/Awjl4i124/nJig4OCdPWB31ANtKTYwYc9wkKmWhiKfs X-Received: by 10.55.198.11 with SMTP id b11mr43779372qkj.53.1442428368294; Wed, 16 Sep 2015 11:32:48 -0700 (PDT) Received: from [10.33.192.36] (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id v34sm10495711qge.47.2015.09.16.11.32.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Sep 2015 11:32:47 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Brian Rosen In-Reply-To: Date: Wed, 16 Sep 2015 14:32:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4EE7311A-C4AA-4153-8B19-2C3175F03D89@brianrosen.net> References: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> To: Randall Gellens X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Wed, 16 Sep 2015 11:52:23 -0700 Cc: secdir@ietf.org, draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:32:53 -0000 TLS MUST be version 1.2 or later. It is RECOMMENDED to use only cipher suites that offer Perfect Forward Secrecy (PFS), avoid Cipher Block Chaining (CBC) and follow the recommendations in BCP195. > On Sep 16, 2015, at 12:14 PM, Randall Gellens = wrote: >=20 > At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: >=20 >> On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=F6m wrote: >>> Yes, at least mandating TLS 1.2 or higher and recommending as per = above >>> seems reasonable. >>> The references for the GCM suites would be RFC 5288 and RFC 5289. >>=20 >> BCP195 has recent recommendations for most TLS options. I'd say it'd = be best to use those or if not figure out why they're not correct for = this context. >=20 > Just to be clear: are you suggesting that we replace text suggested by = Magnus: >=20 > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > cypher suites that offer Perfect Forward Secrecy (PFS) and avoid > Cipher Block Chaining (CBC), for example, > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. >=20 > With this: >=20 > TLS MUST be version 1.2 or later. It is RECOMMENDED follow > [BCP195]. >=20 >=20 > Note that BCP 195 does not address CBC (but does discuss PFS). I just = want to be clear before making the change, so please confirm that this = works. >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > If the odds are a million to one against something occurring, chances > are 50-50 it will. From nobody Wed Sep 16 12:22:50 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DD11A00EF for ; Wed, 16 Sep 2015 12:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Aw3hhSaUw_Nq for ; Wed, 16 Sep 2015 12:22:47 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78A01A000F for ; Wed, 16 Sep 2015 12:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442431367; x=1473967367; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=qwZtK5lUxaRf9PD7+I2A8aRYEHnmE6DudQsyCZv17k0=; b=tJe0RY22xW3Gp3A0bhXpt9c+MnO+w2dtNx/9kKPjJEcSFYKfnSoOTeI7 eNabw6IFEKApqyoj2WmWuFJILViNcZykMLQxTi+JbjKxwNVtilxsU/8VI GVj6x4BLjmaj1Gk9+i8J2wP9lQctwcEzMiL2IlKavXcwkdv6NTRC8dzFl Q=; X-IronPort-AV: E=McAfee;i="5700,7163,7926"; a="138971862" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Sep 2015 12:22:47 -0700 X-IronPort-AV: E=Sophos;i="5.17,541,1437462000"; d="scan'208";a="1002915462" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Sep 2015 12:22:47 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 16 Sep 2015 12:22:46 -0700 Message-ID: In-Reply-To: <4EE7311A-C4AA-4153-8B19-2C3175F03D89@brianrosen.net> References: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> <4EE7311A-C4AA-4153-8B19-2C3175F03D89@brianrosen.net> X-Mailer: Eudora for Mac OS X Date: Wed, 16 Sep 2015 12:22:42 -0700 To: Brian Rosen , Randall Gellens From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: secdir@ietf.org, draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 19:22:49 -0000 At 2:32 PM -0400 9/16/15, Brian Rosen wrote: > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > cipher suites that offer Perfect Forward Secrecy (PFS), avoid > Cipher Block Chaining (CBC) and follow the recommendations in BCP195. Do we need to give examples of such suites? > >> On Sep 16, 2015, at 12:14 PM, Randall Gellens=20 >> wrote: >> >> At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: >> >>> On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=F6m wrote: >>>> Yes, at least mandating TLS 1.2 or higher and recommending as per abov= e >>>> seems reasonable. >>>> The references for the GCM suites would be RFC 5288 and RFC 5289. >>> >>> BCP195 has recent recommendations for most=20 >>> TLS options. I'd say it'd be best to use=20 >>> those or if not figure out why they're not=20 >>> correct for this context. >> >> Just to be clear: are you suggesting that we=20 >> replace text suggested by Magnus: >> >> TLS MUST be version 1.2 or later. It is RECOMMENDED to use only >> cypher suites that offer Perfect Forward Secrecy (PFS) and avoid >> Cipher Block Chaining (CBC), for example, >> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, >> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, >> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, >> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, >> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. >> >> With this: >> >> TLS MUST be version 1.2 or later. It is RECOMMENDED follow >> [BCP195]. >> >> >> Note that BCP 195 does not address CBC (but=20 >> does discuss PFS). I just want to be clear=20 >> before making the change, so please confirm=20 >> that this works. >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> If the odds are a million to one against something occurring, chances >> are 50-50 it will. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It takes a wonderful brain and exquisite senses to produce a few stupid ideas. --Santayana From nobody Wed Sep 16 12:39:06 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2032A1A01A5 for ; Wed, 16 Sep 2015 12:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 cnnGKQ-ji6WR for ; Wed, 16 Sep 2015 12:39:02 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (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 DDC3D1A0197 for ; Wed, 16 Sep 2015 12:39:01 -0700 (PDT) Received: by qgx61 with SMTP id 61so181332251qgx.3 for ; Wed, 16 Sep 2015 12:39:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=a5VRwzcifVbZf2RDeBn/InhnZMne9BlkZAWmpHPpOhQ=; b=iTTwpLAie/BvtGhasqGU/X7XRl1S3g/LyC0fFfGny8zYP19CQL+s8JKepDnQ9a2tq2 XCsyFJvxzUizIGioPXPrd0ik3VMnmv93MlhB0euUzbqC3Qx3686+2wrCbYuSVFHMUFwX TPP6lJhgugv6g95cHD8MFjpGxKMYdhJd8t8M3GrYM3P83D3n24VF1czzwY3SyuCY2WQ6 wTYSFYgIAHJgWD4YyuluXIVbOrx2HyhwammnDJn3RyFnZLlI4guyK8tIc4LWHrF0DKm3 ThBKQTFM0eenupw0p6670JYMW+93uegEAjf3HLvPRdlOzXLUeqrVvyXU9OulI7tky+u/ Gicw== X-Gm-Message-State: ALoCoQmxVW5qKWdGg+e39DNiBIruYVoi/+PpilWCpxVK70DMh/PHS/jOtodOVruPTOGp5CkpjZ/p X-Received: by 10.140.38.167 with SMTP id t36mr44926457qgt.66.1442432340988; Wed, 16 Sep 2015 12:39:00 -0700 (PDT) Received: from [10.33.192.36] (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id 139sm8364324qhh.43.2015.09.16.12.38.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Sep 2015 12:39:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_69645160-2823-4270-979D-03EE37D0A698" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Brian Rosen In-Reply-To: Date: Wed, 16 Sep 2015 15:38:55 -0400 Message-Id: <70E145DD-8A93-4136-BBD2-82E1385A58FD@brianrosen.net> References: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> <4EE7311A-C4AA-4153-8B19-2C3175F03D89@brianrosen.net> To: Randall Gellens X-Mailer: Apple Mail (2.2104) Archived-At: Cc: secdir@ietf.org, draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 19:39:04 -0000 --Apple-Mail=_69645160-2823-4270-979D-03EE37D0A698 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Don=92t think so. Brian > On Sep 16, 2015, at 3:22 PM, Randall Gellens = wrote: >=20 > At 2:32 PM -0400 9/16/15, Brian Rosen wrote: >=20 >> TLS MUST be version 1.2 or later. It is RECOMMENDED to use only >> cipher suites that offer Perfect Forward Secrecy (PFS), avoid >> Cipher Block Chaining (CBC) and follow the recommendations in = BCP195. >=20 > Do we need to give examples of such suites? >=20 >>=20 >>> On Sep 16, 2015, at 12:14 PM, Randall Gellens = wrote: >>>=20 >>> At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: >>>=20 >>>> On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=F6m wrote: >>>>> Yes, at least mandating TLS 1.2 or higher and recommending as per = above >>>>> seems reasonable. >>>>> The references for the GCM suites would be RFC 5288 and RFC 5289. >>>>=20 >>>> BCP195 has recent recommendations for most TLS options. I'd say = it'd be best to use those or if not figure out why they're not correct = for this context. >>>=20 >>> Just to be clear: are you suggesting that we replace text suggested = by Magnus: >>>=20 >>> TLS MUST be version 1.2 or later. It is RECOMMENDED to use only >>> cypher suites that offer Perfect Forward Secrecy (PFS) and avoid >>> Cipher Block Chaining (CBC), for example, >>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, >>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, >>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, >>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, >>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, >>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. >>>=20 >>> With this: >>>=20 >>> TLS MUST be version 1.2 or later. It is RECOMMENDED follow >>> [BCP195]. >>>=20 >>>=20 >>> Note that BCP 195 does not address CBC (but does discuss PFS). I = just want to be clear before making the change, so please confirm that = this works. >>>=20 >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself = only >>> -------------- Randomly selected tag: --------------- >>> If the odds are a million to one against something occurring, = chances >>> are 50-50 it will. >=20 >=20 >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > It takes a wonderful brain and exquisite senses to produce a few > stupid ideas. --Santayana --Apple-Mail=_69645160-2823-4270-979D-03EE37D0A698 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Don=92t think so.

Brian
On Sep 16, 2015, at 3:22 PM, = Randall Gellens <randy@qti.qualcomm.com> wrote:

At 2:32 PM -0400 9/16/15, Brian Rosen = wrote:

TLS MUST be version 1.2 or later.  It is = RECOMMENDED to use only
  cipher suites that = offer Perfect Forward Secrecy (PFS), avoid
  Cipher Block Chaining (CBC) and follow the = recommendations in BCP195.

Do we need to give examples of such = suites?


On = Sep 16, 2015, at 12:14 PM, Randall Gellens <randy@qti.qualcomm.com> wrote:

At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote:

On Wed Sep 16 04:09:03 = 2015 GMT+0100, Magnus Nystr=F6m wrote:
Yes, at least mandating TLS 1.2 or higher and = recommending as per above
seems reasonable.
The references for the GCM suites would be RFC 5288 and RFC = 5289.

BCP195 has recent = recommendations for most TLS options. I'd say it'd be best to use those = or if not figure out why they're not correct for this context.

Just to be clear: are you = suggesting that we replace text suggested by Magnus:

  TLS MUST be version 1.2 or later.  It is = RECOMMENDED to use only
  cypher suites that = offer Perfect Forward Secrecy (PFS) and avoid
  Cipher Block Chaining (CBC), for example,
  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
  TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] = [RFC5289].

With this:

  TLS MUST be version 1.2 or later.  It is = RECOMMENDED follow
  [BCP195].


Note that BCP 195 does not address CBC (but = does discuss PFS).  I just want to be clear before making the = change, so please confirm that this works.

--
Randall Gellens
Opinions are = personal;    facts are suspect;    I speak = for myself only
-------------- Randomly selected tag: = ---------------
If the odds are a million to one against = something occurring, chances
are 50-50 it will.



--
Randall Gellens
Opinions are personal;    facts = are suspect;    I speak for myself only
-------------- Randomly selected tag: = ---------------
It takes a wonderful brain = and exquisite senses to produce a few
stupid ideas. =             &n= bsp;           &nbs= p;            =   --Santayana

= --Apple-Mail=_69645160-2823-4270-979D-03EE37D0A698-- From nobody Wed Sep 16 22:14:59 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF7A1B31F0 for ; Wed, 16 Sep 2015 22:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 nZqyzZaLyMMa for ; Wed, 16 Sep 2015 22:14:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 11DC11B31EE for ; Wed, 16 Sep 2015 22:14:54 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t8H5EpMF018375 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Sep 2015 08:14:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t8H5EpKT023783; Thu, 17 Sep 2015 08:14:51 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22010.19531.253544.215699@fireball.acr.fi> Date: Thu, 17 Sep 2015 08:14:51 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 05:14:57 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Chris Inacio is next in the rotation. For telechat 2015-09-17 Reviewer LC end Draft Dave Cridland T 2015-09-08 draft-ietf-pals-vccv-for-gal-05 Chris Inacio T 2015-07-29 draft-ietf-homenet-dncp-09 Ben Laurie T 2015-08-11 draft-ietf-dnsop-dns-terminology-04 Hannes Tschofenig TR2015-09-17 draft-wkumari-dhc-capport-16 For telechat 2015-10-01 John Bradley T 2015-09-03 draft-ietf-mpls-lsp-ping-reply-mode-simple-04 Daniel Kahn Gillmor T 2015-09-17 draft-ietf-tzdist-caldav-timezone-ref-04 Dan Harkins T 2015-09-24 draft-ietf-bess-spbm-evpn-01 Tom Yu T 2015-09-08 draft-ietf-dhc-dhcpv4-active-leasequery-06 Dacheng Zhang T 2015-09-04 draft-ietf-dice-profile-16 Last calls and special requests: Derek Atkins 2015-09-23 draft-kivinen-ipsecme-oob-pubkey-11 Donald Eastlake 2015-09-11 draft-ietf-dane-openpgpkey-05 Shawn Emery 2015-09-23 draft-ietf-pwe3-iccp-stp-04 Daniel Kahn Gillmor E None draft-ietf-rtcweb-security-08 Tobias Gondrom E None draft-ietf-rtcweb-security-arch-11 Tobias Gondrom 2015-09-22 draft-ietf-v6ops-siit-dc-02 Olafur Gudmundsson 2015-09-22 draft-ietf-v6ops-siit-dc-2xlat-01 Phillip Hallam-Baker 2015-09-22 draft-ietf-v6ops-siit-eam-01 Steve Hanna 2015-10-09 draft-blanchet-ccsds-urn-00 Sam Hartman 2015-09-30 draft-ietf-teas-fast-lsps-requirements-01 Paul Hoffman 2015-09-24 draft-ietf-teas-rsvp-te-srlg-collect-02 Christian Huitema 2015-09-30 draft-ietf-teas-te-express-path-03 Jeffrey Hutzelman 2015-09-30 draft-ietf-v6ops-pmtud-ecmp-problem-04 Brian Weis 2015-09-23 draft-housley-sow-author-statistics-00 -- kivinen@iki.fi From nobody Thu Sep 17 02:44:13 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A371B2C2A; Thu, 17 Sep 2015 02:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YSKUo8oUYVqM; Thu, 17 Sep 2015 02:44:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E981B29F4; Thu, 17 Sep 2015 02:44:07 -0700 (PDT) Received: from [192.168.10.183] ([134.76.0.127]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0ML6XF-1ZcmiC1mYD-000MEi; Thu, 17 Sep 2015 11:43:49 +0200 To: Warren Kumari , Hannes Tschofenig References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55FA8B49.7040303@gmx.net> Date: Thu, 17 Sep 2015 11:43:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="deTV7UsFLDceDVec7nE68uNoBmXAopegD" X-Provags-ID: V03:K0:dHX7a23A0l9aYAnnZ0/qq5/XWE/K6DslrWiTdBuVlKcTX4KPeKF ctasznCIkDiSZPKs0ibvCtROwell1NJuuWd6XO9WmtiPj7+RBHNSkj8LLaTgSdT8jnuZqOO 5dVfNlfCD39IWIuI7J6tukqaELZlMvylMmj2bvKWqwvu/TnJy4NudYT0O8KPI1iVTDCKJRB ysK3XiYK+7hqk5VWRoZBA== X-UI-Out-Filterresults: notjunk:1;V01:K0:o9nXMWaiQAU=:R+jxVGDt+EmQpDa4p86Jp3 Sl3umek6rNQ2WyrKdlxop3Sgw2aMR2d37bVhzhqJEjHyEd/Yv5Soudlp5P8DsRd/nRHxFLaTI gSnBG8BEMHQsJpmGlTmVftQML4jtQiufdfDEVyU1XLAQwrWN+W1RzMFnbRETEiJfPFv58DIga cJ3xXZr55QTqlAw2XHscmzemENXb3m9NHAX6WwToLbW6UC51HF0PRlMhs3rjsuqv894tjofno SoiH0hgRlOxHgZWI7RQ3tH+7x5Kyb8fQhIZsLE59eTXxMQDr6VJmuShtUNmpXquIK/fXXzbpA I3sR6L71e/Bjz4KJc+YAca6Pbnql6b0THF24HZ3sOu3VtzRgwurcqKrW+yL9nMJ6O0rHqAnQx AHnSdh0j7q2NgrrMqp91lCdqivzsqJIQf3UEHc3wHVKcczCv/+QRNChPMcuNHP0vvIC+5hqdG uBUpsgMQ7C9cKO21S3xOqfy306A4bQPNWbZBeROYTXrAY/3k1zgx+H0i7aD3+o3EMojuREt/K 0wWN7TlEyIZxrU3zgc9fyELB1iIH8IbX+MEwLGFScpQRyjor0VPtud4YTs2q81b33bINlACpT OM5N0YTJa/0XebcbUZIs29T0RwzSB1SquW1EYnIilbankcXqzmlBVnORLTallwBj2Ffps4Z2j JKgB+qsKXMWrx+HUhFAmTbb1PWNFAuW9iYR2JuXX4Xf0ZXwWg+jRT3BUSWyuMrcrLKsKEY7RJ M3wwAsfl0LBD/0W8 Archived-At: Cc: "draft-wkumari-dhc-capport.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-wkumari-dhc-capport-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 09:44:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --deTV7UsFLDceDVec7nE68uNoBmXAopegD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Warren, ~snip~ >> The motivation of the document makes sense, namely to avoid intercepti= on of >> traffic, and the document is an easy extension to already available >> mechanisms (RA/DHCP). I was expecting to see a reference to Hotspot 2.= 0, >> which aims to make the interaction between hotspot providers and end d= evices >> more intelligent (but covers a much larger scope). >=20 > I originally had this as an editor's note: > https://github.com/wkumari/draft-wkumari-dhc-capport/blob/de293471faef5= 62517978b709aaca762d1d78dbe/README.md >=20 > "[ Ed note: This solution is somewhat similar / complements 802.11u / > WiFi Passpoint Online Sign-up, but is much simpler, easier to deploy= , > and works on wired as well ] > " >=20 > I spent some time looking at the Hotspot 2.0 stuff, but after slogging > through much 4 color glossy type material it seemed that it more > allowed you to use different reaming providers / snap a RADIUS > connection back to another provider. I even spent some $$$ on > purchasing a spec, which I found largely unintelligible. > So, I decided to remove the vague / editorial note... :-) >=20 > If you happen to have any suggested text I'm happy to stick it in... Good to hear that you took the work into account. It is fine for me if you came up with the conclusion that it is too complex. (Btw, the specifications are now available for download for free at http://www.wi-fi.org/discover-wi-fi/specifications) Ciao Hannes --deTV7UsFLDceDVec7nE68uNoBmXAopegD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV+otJAAoJEGhJURNOOiAtr8MH/jc1VU2le2A42RAlWUIdV4p/ lUc2wK8YJJf6SIoZZAUlal2d00CXG3bBdRBIT3zBh6ryKLP6pPeMbO46jjZ6mYk1 ghT52otBI0ZxEwjjmX3HDEqQOZbxDl+12iYI9rijHeBdjZ9q2iMetqy9zrIblK+x od0fu6xXzFqVty4CZ5A/nljDcI5lkM4UgAC5BPjkFHjRuwoYTThNqEbJPIs6bt/b 5O1E9FbFgfiQipopYFdUCxLNaPpCtKmXmdbTwN7JOzAYXkLioe5i0vZcBiHmpZXE m8drxsPhvAfZAz1VjKWBMhbFaBZVF2vLWbMlmp8FmB0zodYQFJwYlU28wVgNQFk= =5G7x -----END PGP SIGNATURE----- --deTV7UsFLDceDVec7nE68uNoBmXAopegD-- From nobody Thu Sep 17 07:02:57 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A591A0015; Thu, 17 Sep 2015 07:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VET4-lxMYEur; Thu, 17 Sep 2015 07:02:53 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5D21A00B9; Thu, 17 Sep 2015 07:02:50 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id CC28D1229CD; Thu, 17 Sep 2015 10:28:53 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 91E99E101C; Thu, 17 Sep 2015 10:01:14 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Thu, 17 Sep 2015 10:02:50 -0400 From: "MORTON, ALFRED C (AL)" To: Alan DeKok , "secdir@ietf.org" Date: Thu, 17 Sep 2015 10:02:49 -0400 Thread-Topic: Secdir review of draft-ietf-ippm-owamp-registry-03 Thread-Index: AdDwr+ejrlXABYCpRsygInVxFp7LpAAn3HQw Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB4581583@NJFPSRVEXG0.research.att.com> References: <6FD706E2-FEAC-4EF2-BCE8-43D16095BB11@deployingradius.com> In-Reply-To: <6FD706E2-FEAC-4EF2-BCE8-43D16095BB11@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ippm-ads@ietf.org" , "ippm-chairs@ietf.org" , "draft-ietf-ippm-owamp-registry@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-owamp-registry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 14:02:55 -0000 Hi Alan, thanks for your review, please see replies below. FWIW - I had to look-up the details. Al > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Wednesday, September 16, 2015 2:03 PM > To: secdir@ietf.org > Cc: draft-ietf-ippm-owamp-registry@tools.ietf.org > Subject: Secdir review of draft-ietf-ippm-owamp-registry-03 >=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 > This document requests IANA allocation of registries for OWAMP. As > such, it has minimal security impact. >=20 > One practical note is the request to assign an "Experimentation" > OWAMP-Control Command Number. Experience shows that such numbers are > either never used, or used as experiments... which then get widely > deployed before standards action catches up to practical needs. [ACM]=20 I understand how this might happen, but IETF already has a=20 BCP that covers this topic: https://tools.ietf.org/html/bcp82 >=20 > It may be good to add some discussion as to *how* experiments are > done, and how experiments can transition from the "Experimentation" > number to a standard number. [ACM]=20 IMO, BCP82 covers this aspect adequately.=20 >=20 > One suggestion would be to change the label from "Experimentation" to > "Site-Local". That would still allow sites to experiment with OWAMP- > Control commands, but would make it clearer that such experimentation is > only for the local site, and MUST NOT be used in a wider context. [ACM]=20 Site-local is not a valid registry assignment, see: https://tools.ietf.org/html/rfc5226#section-4 Also, I would expect that an Internet performance characterization protocol will be deployed on the Internet when using an experimental comman= d to conduct experiments, so not Site-Local. Note that the existing reference to RFC5226 makes a clear reference to BCP 82 in section 4. From nobody Fri Sep 18 07:53:58 2015 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 951671B2D97; Fri, 18 Sep 2015 07:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1442587932; bh=o1gEAuEfSezOeTdYmOS6nRJxPobaKanyGYgiwT6A+oo=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=R46L/H4N9J4UoO1eN2IhZpuROYIpjghHLNE5iUNhlUZbwctsMeNc7iNEcPxioOSTw iwNPCtIqQxlE/sKPWxTKlz1gQWF7yoOf9tLPLzwce+VfMsALa1ZzxiH0YhxWY99bUE sO5+NQPhv3Sx9kzElIaZVbsB8i6bDxm3ZQ3F6qHE= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492BC1B2D98; Fri, 18 Sep 2015 07:52:10 -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 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 qrN13AyZZj61; Fri, 18 Sep 2015 07:52:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA031B2D92; Fri, 18 Sep 2015 07:52:08 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150918145208.24504.76897.idtracker@ietfa.amsl.com> Date: Fri, 18 Sep 2015 07:52:08 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2015 07:53:57 -0700 Subject: [secdir] [new-work] WG Review: Deterministic Networking (detnet) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 14:52:12 -0000 A new IETF working group has been proposed in the Routing 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 at ietf.org) by 2015-09-28. Deterministic Networking (detnet) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Deborah Brungard Mailing list Address: detnet@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/detnet Archive: https://mailarchive.ietf.org/arch/browse/detnet/ Charter: The Deterministic Networking (DetNet) Working Group focuses on deterministic data paths that operate over Layer 2 bridged and Layer 3 routed segments, where such paths can provide bounds on latency, loss, and packet delay variation (jitter), and high reliability. The Working Group addresses Layer 3 aspects in support of applications requiring deterministic networking. The Working Group collaborates with IEEE802.1 Time Sensitive Networking (TSN), which is responsible for Layer 2 operations, to define a common architecture for both Layer 2 and Layer 3. Example applications for deterministic networks include professional and home audio/video, multimedia in transportation, engine control systems, and other general industrial and vehicular applications being consider by the IEEE 802.1 TSN Task Group. The Working Group will initially focus on solutions for networks that are under a single administrative control or within a closed group of administrative control; these include not only campus-wide networks but also can include private WANs. The DetNet WG will not spend energy on solutions for large groups of domains such as the Internet. The Working Group will specify an overall architecture that encompasses the data plane, OAM (Operations, Administration, and Maintenance), time synchronization, management, control, and security aspects which are required to enable a multi-hop path, and forwarding along the path, with the deterministic properties of controlled latency, low packet loss, low packet delay variation, and high reliability. The work applies to point-to-point (unicast) and point-to-multipoint (multicast) flows which can be characterized in a manner that allows the network to 1) reserve the appropriate resources for the flows in advance, and 2) release/reuse the resources when they are no longer required. The work covers the characterization of flows, the encapsulation of frames, the required forwarding behaviors, as well as the state that may need to be established in intermediate nodes. Candidate Layer 3 data plane technologies that may be used, without modification, include: IP and MPLS. The working group will document which deployment environments and types of topologies are within (or outside) the scope of the DetNet architecture. This work focuses on the data plane aspects and is independent from any path setup protocol or mechanism. The data plane will be compatible with the work done in IEEE802.1 TSN. The Working Group's scope explicitly excludes modifications of transport protocols, OAM, Layer 3 forwarding, encapsulations, and control plane protocols. DetNet is chartered to work in the following areas: Overall architecture: This work encompasses the data plane, OAM, time synchronization, management, control, and security aspects. Data plane: This work will document how to use IP and/or MPLS to support a data plane method of flow identification and packet forwarding over Layer 3. Data flow information model: This work will identify the information needed for flow establishment and control and be used by a reservation protocol or by YANG data models. The work will be independent from the protocol(s) used to control the flows (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS). Identification of additional YANG models: This work will document device and link capabilities (feature support) and resources (e.g. buffers, bandwidth) for use in device configuration and status reporting. Such information may also be used when advertising the deterministic network elements to a control plane. Control plane related information will be independent from the protocol(s) which may be used to advertise this information (e.g. IS-IS or GMPLS extensions). Any new YANG models will be coordinated with the Working Groups that define any augmented base models. As needed, problem statement: This effort will establish the deployment environment and deterministic network requirements. As needed, vertical requirements: This effort will detail the requirements for deterministic networks in various industries, for example, professional audio, electrical utilities, building automation systems, wireless for industrial applications. To investigate whether existing data plane encryption mechanisms can be applied, possibly opportunistically, to improve security and privacy. The WG coordinates with other relevant IETF Working Groups, including CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, and 6TisSCH. As the work progresses, requirements may be provided to the responsible Working Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point to maintain the consistency of the overall architecture. The WG will liaise with appropriate groups in IEEE and other Standards Development Organizations (SDOs). WG deliverables include: As standard track or informational RFCs Overall architecture Data plane specification Data flow information model YANG model augmentations WG sustaining/informational documents may include: These documents may not necessarily be published, but may be maintained in a draft form or on a collaborative Working Group wiki to support the efforts of the Working Group and help new comers: Problem statement and (constrained) deployment environments User-driven use cases Milestones: _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Sep 18 08:15:52 2015 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 1BADB1B2DF2; Fri, 18 Sep 2015 08:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1442589251; bh=HcebDJGi3iL5245BE/87PkYtTp0I3o+7ju9ClW+VolQ=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=xxFndWybuQHWMdu+rvVtVBjVL/dQPDL9E+culRzh/n2u32h8MMv3DvLOua2ycKZXI R2JB/IcGmf8a4z1eqoxCJY22Qo3dSnDb/DDXyuzkwMvn7WaN1xyrtcOLiFB+rqzaDo cfHxnkIs/vySY1+FFmZKGG6EB9stt2/dWvU5YGjM= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D62B1B2DF2; Fri, 18 Sep 2015 08:14:09 -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 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 hFXg-G8HWUjc; Fri, 18 Sep 2015 08:14:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 803D11B2E07; Fri, 18 Sep 2015 08:14:00 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150918151400.4500.34261.idtracker@ietfa.amsl.com> Date: Fri, 18 Sep 2015 08:14:00 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2015 08:15:51 -0700 Subject: [secdir] [new-work] WG Review: Simplified Use of Policy Abstractions (supa) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 15:14:11 -0000 A new IETF working group has been proposed in the Operations and Management 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 at ietf.org) by 2015-09-28. Simplified Use of Policy Abstractions (supa) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Benoit Claise Mailing list Address: supa@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/supa Archive: https://mailarchive.ietf.org/arch/browse/supa/ Charter: Policies are a set of rules that define how services are designed, delivered, and operated within an operator's networking environment. As such, policies play a critical role in the automated service delivery and operational procedures. Operators want and need to be able to define the policies that apply to their different customers and to the equipment that comprises their physical and virtual networks. Policies usually span a wide range of services that are supported by various technologies: thus, a common way for expressing and describing policies that is uniform and consistent regardless of the nature of the networking environment is likely to facilitate the overall service delivery procedure and operation. Such an approach will minimize the risk of configuration errors that arise from confusion between different systems, will enable easy understanding of policies that apply in different environments, will make the implementation of policy-based systems quicker and cheaper, and will facilitate the rapid development of standards-based data models that include policy elements. The SUPA (Simplified Use of Policy Abstractions) working group defines a data model, to be used to represent high-level, possibly network-wide policies, which can be input to a network management function (within a controller, an orchestrator, or a network element). Processing that input most probably results in network configuration changes. SUPA however does not deal with the definition of the specific network configuration changes but with how the configuration changes are applied (e.g. who is allowed to set policies, when and how the policies are activated, changed or de-activated). Practically, SUPA defines base YANG data models to encode policy, which will point to device-, technology-, and service-specific YANG models developed in other working groups. SUPA focuses on a single management domain, and is designed to work with device, protocol, network, and service data models. The working group will have succeeded when the SUPA policy constructs are re-used in future IETF specifications (and ideally specifications from other SDOs), in a matter that saves development time and avoid inconsistencies between data models developed by different working groups. In the mean time, other working groups should not delay their deliverables waiting for SUPA to complete its work. The SUPA working group develops models for expressing policy at different levels of abstraction. Specifically, two models are envisioned: (i) a generic model that defines concepts and vocabulary needed by policy management independent of the form and content of the policy (ii) a more specific model that refines the generic model to specify how to build policy rules of the event-condition-action paradigm If the working group finds it necessary to work on an information model before the data model, to help provide guidance and derive the data models, it may do so. The working group will decide later whether the information model needs to be published as an RFC. Out of scope of this working group are: - The specification of a new policy protocol or a new data modelling language. - Design of protocol-specific policies and specific design for embedded policies in network elements (which are usually interpreted in isolation, and often at timescales that require optimization for specific purposes). - Specific handling of policies (although the application document will provide some examples). Therefore the specification of a policy engine that maps a specific policy instance to actual configuration snippets is also out of scope. Declarative policies that specify the goals to achieve but not how to achieve those goals (also called "intent-based" policies) are out of scope for the initial phase of SUPA but may be considered in future phases of SUPA. List of work items: 1) An explanation of the scope of the policy-based management framework and how it relates to existing work of the IETF. 2) If the working group considers it necessary, a generic information model composed of policy concepts and vocabulary. 3) A set of YANG data models consisting of a base policy model for representing policy management concepts independent of the type or structure of a policy, plus an extension for defining policy rules according to the event-condition-action paradigm. 4) An applicability document providing a few examples that demonstrate how the YANG policy data models can be used to express policies that are relevant for network operators. The examples may tie into configuration models or network service models developed by other working groups. The working group will decide how the work items are best mapped into deliverables. The working group will communicate with other SDOs (MEF, TMF, ETSI) that are working on related issues. Milestones: Apr 2016 Submit the policy-based management framework (Informational) Apr 2016 Submit the generic information model (Informational) Jun 2016 Submit the set of YANG data models (Standards Track) Aug 2016 Submit the applicability document (Informational) Aug 2016 Re-charter or close _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Sep 21 08:56:02 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8AA1B33C8; Mon, 21 Sep 2015 08:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_SOFTFAIL=0.665] autolearn=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 aJoBs9aNv3Xj; Mon, 21 Sep 2015 08:55:50 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5963B1B33D1; Mon, 21 Sep 2015 08:55:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id E601620801; Mon, 21 Sep 2015 11:55:16 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv33nv6_EIMb; Mon, 21 Sep 2015 11:55:16 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 21 Sep 2015 11:55:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4FB1A80D01; Mon, 21 Sep 2015 11:55:48 -0400 (EDT) From: Sam Hartman To: secdir@ietf.org,sec-ads@ietf.org,iesg@ietf.org Date: Mon, 21 Sep 2015 11:55:48 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: draft-ietf-teas-fast-lsps-requirements-01.all@ietf.org Subject: [secdir] Secdir Review of draft-ietf-teas-fast-lsps-requirements-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 15:55:52 -0000 Hi. I am the assigned secdir reviewer for this draft on requirements for very fast GMPLS path establishment. This draft outlines scaling requirements for new applications of GMPLS. I'd like to flag this draft for particular review from the security ADs and recommend that the IESG consider a process question and get input from the sponsoring AD. So, for the security ADS: The security considerations section reads in its entirety: . Security Considerations Being able to support very fast setup and a high churn rate of GMPLS LSPs is not expected to adversely affect the underlying security issues associated with existing GMPLS signaling. however the draft talks about increasing the number of cases where GMPLS paths cross administrative boundaries and significantly increasing the scale of GMPLS applications. I don't think we have good security solutions for cases where we're trying to do PCE-like things across mutually suspicious or potentially hostile administrative boundaries. And yes it's reasonable to assume that there are business relationships in place here, but we also understand from our experience with BGP and other internet-scale services the limitations of that. I think significantly more security work is consider. On a general level, there's basically no justification for the requirements given. For example, the document talks about how cloud computing is an application that will drive these requirements. The document neither talks about nor cites any explanation of what it is about cloud computing that creates that need nor gives the reader any ability to evaluate whether the need is real. The depth of analysis is similar for all the other cited applications. We jump from very broad staments like "cloud computing, datacenters and data visualization will need this," to specific requirements in terms of requests per second. I'd particularly like to call out section 2: 2. Background The Defense Advanced Research Projects Agency (DARPA) Core Optical Networks (CORONET) program [Chiu], is an example target environment that includes IP and optical commercial and government networks, with a focus on highly dynamic and resilient multi-terabit core networks. It anticipates the need for rapid (sub-second) setup and SONET/SDH- like restoration times for high-churn (up to tens of requests per second network-wide and holding times as short as one second) on- demand wavelength, sub-wavelength and packet services for a variety of applications (e.g., grid computing, cloud computing, data visualization, fast data transfer, etc.). This must be done while meeting stringent call blocking requirements, and while minimizing the use of resources such as time slots, switch ports, wavelength conversion, etc. I recommend that someone take a look at the material on that DARPA project and see how well the DARPA requirements align with the recommendations in this spec. I'm somewhat concerned that DARPA put together a research project and said "Hey we'd like these things," and now the IETF, without any significant independent analysis is rubber stamping that as our requirements in this space. I don't know that's what happened here, thus I have not copied ietf@ietf.org. However, DARPA's request should not represent an informed consensus of the IETF. I'd like to see the IESG evaluate whether we actually have done our own analysis here and whether there is an informed consensus behind this document. Thanks for your consideration, --Sam From nobody Mon Sep 21 09:08:54 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C681A90D3; Mon, 21 Sep 2015 09:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_SOFTFAIL=0.665] autolearn=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 RAWcZVM3BYoA; Mon, 21 Sep 2015 09:08:50 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9271A90C0; Mon, 21 Sep 2015 09:08:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 04B8320801; Mon, 21 Sep 2015 12:08:17 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPsdIybh5rW9; Mon, 21 Sep 2015 12:08:16 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 21 Sep 2015 12:08:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7A41F80D01; Mon, 21 Sep 2015 12:08:48 -0400 (EDT) From: Sam Hartman To: secdir@ietf.org,sec-ads@ietf.org,iesg@ietf.org Date: Mon, 21 Sep 2015 11:55:48 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "draft-ietf-teas-fast-lsps-requirements..all"@ietf.org Subject: [secdir] Secdir Review of draft-ietf-teas-fast-lsps-requirements-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 16:08:52 -0000 Hi. I am the assigned secdir reviewer for this draft on requirements for very fast GMPLS path establishment. This draft outlines scaling requirements for new applications of GMPLS. I'd like to flag this draft for particular review from the security ADs and recommend that the IESG consider a process question and get input from the sponsoring AD. So, for the security ADS: The security considerations section reads in its entirety: . Security Considerations Being able to support very fast setup and a high churn rate of GMPLS LSPs is not expected to adversely affect the underlying security issues associated with existing GMPLS signaling. however the draft talks about increasing the number of cases where GMPLS paths cross administrative boundaries and significantly increasing the scale of GMPLS applications. I don't think we have good security solutions for cases where we're trying to do PCE-like things across mutually suspicious or potentially hostile administrative boundaries. And yes it's reasonable to assume that there are business relationships in place here, but we also understand from our experience with BGP and other internet-scale services the limitations of that. I think significantly more security work is consider. On a general level, there's basically no justification for the requirements given. For example, the document talks about how cloud computing is an application that will drive these requirements. The document neither talks about nor cites any explanation of what it is about cloud computing that creates that need nor gives the reader any ability to evaluate whether the need is real. The depth of analysis is similar for all the other cited applications. We jump from very broad staments like "cloud computing, datacenters and data visualization will need this," to specific requirements in terms of requests per second. I'd particularly like to call out section 2: 2. Background The Defense Advanced Research Projects Agency (DARPA) Core Optical Networks (CORONET) program [Chiu], is an example target environment that includes IP and optical commercial and government networks, with a focus on highly dynamic and resilient multi-terabit core networks. It anticipates the need for rapid (sub-second) setup and SONET/SDH- like restoration times for high-churn (up to tens of requests per second network-wide and holding times as short as one second) on- demand wavelength, sub-wavelength and packet services for a variety of applications (e.g., grid computing, cloud computing, data visualization, fast data transfer, etc.). This must be done while meeting stringent call blocking requirements, and while minimizing the use of resources such as time slots, switch ports, wavelength conversion, etc. I recommend that someone take a look at the material on that DARPA project and see how well the DARPA requirements align with the recommendations in this spec. I'm somewhat concerned that DARPA put together a research project and said "Hey we'd like these things," and now the IETF, without any significant independent analysis is rubber stamping that as our requirements in this space. I don't know that's what happened here, thus I have not copied ietf@ietf.org. However, DARPA's request should not represent an informed consensus of the IETF. I'd like to see the IESG evaluate whether we actually have done our own analysis here and whether there is an informed consensus behind this document. Thanks for your consideration, --Sam From nobody Mon Sep 21 09:17:05 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143981A9104; Mon, 21 Sep 2015 09:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_SOFTFAIL=0.665] autolearn=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 Ak5R06ckTlvu; Mon, 21 Sep 2015 09:16:54 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B8F1A9102; Mon, 21 Sep 2015 09:16:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6412520802; Mon, 21 Sep 2015 12:16:17 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF_MIZxBX1SJ; Mon, 21 Sep 2015 12:16:16 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 21 Sep 2015 12:16:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6C14980D01; Mon, 21 Sep 2015 12:16:48 -0400 (EDT) From: Sam Hartman To: secdir@ietf.org,sec-ads@ietf.org,iesg@ietf.org Date: Mon, 21 Sep 2015 11:55:48 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: draft-ietf-teas-fast-lsps-requirements.all@ietf.org Subject: [secdir] Secdir Review of draft-ietf-teas-fast-lsps-requirements-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 16:16:55 -0000 Hi. I am the assigned secdir reviewer for this draft on requirements for very fast GMPLS path establishment. This draft outlines scaling requirements for new applications of GMPLS. I'd like to flag this draft for particular review from the security ADs and recommend that the IESG consider a process question and get input from the sponsoring AD. So, for the security ADS: The security considerations section reads in its entirety: . Security Considerations Being able to support very fast setup and a high churn rate of GMPLS LSPs is not expected to adversely affect the underlying security issues associated with existing GMPLS signaling. however the draft talks about increasing the number of cases where GMPLS paths cross administrative boundaries and significantly increasing the scale of GMPLS applications. I don't think we have good security solutions for cases where we're trying to do PCE-like things across mutually suspicious or potentially hostile administrative boundaries. And yes it's reasonable to assume that there are business relationships in place here, but we also understand from our experience with BGP and other internet-scale services the limitations of that. I think significantly more security work is consider. On a general level, there's basically no justification for the requirements given. For example, the document talks about how cloud computing is an application that will drive these requirements. The document neither talks about nor cites any explanation of what it is about cloud computing that creates that need nor gives the reader any ability to evaluate whether the need is real. The depth of analysis is similar for all the other cited applications. We jump from very broad staments like "cloud computing, datacenters and data visualization will need this," to specific requirements in terms of requests per second. I'd particularly like to call out section 2: 2. Background The Defense Advanced Research Projects Agency (DARPA) Core Optical Networks (CORONET) program [Chiu], is an example target environment that includes IP and optical commercial and government networks, with a focus on highly dynamic and resilient multi-terabit core networks. It anticipates the need for rapid (sub-second) setup and SONET/SDH- like restoration times for high-churn (up to tens of requests per second network-wide and holding times as short as one second) on- demand wavelength, sub-wavelength and packet services for a variety of applications (e.g., grid computing, cloud computing, data visualization, fast data transfer, etc.). This must be done while meeting stringent call blocking requirements, and while minimizing the use of resources such as time slots, switch ports, wavelength conversion, etc. I recommend that someone take a look at the material on that DARPA project and see how well the DARPA requirements align with the recommendations in this spec. I'm somewhat concerned that DARPA put together a research project and said "Hey we'd like these things," and now the IETF, without any significant independent analysis is rubber stamping that as our requirements in this space. I don't know that's what happened here, thus I have not copied ietf@ietf.org. However, DARPA's request should not represent an informed consensus of the IETF. I'd like to see the IESG evaluate whether we actually have done our own analysis here and whether there is an informed consensus behind this document. Thanks for your consideration, --Sam From nobody Mon Sep 21 09:20:41 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD381A9104; Mon, 21 Sep 2015 09:20:38 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 986OMEGTtoxv; Mon, 21 Sep 2015 09:20:36 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DE41A90F7; Mon, 21 Sep 2015 09:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=827; q=dns/txt; s=iport; t=1442852436; x=1444062036; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=PBwD9Ht+ELeF6AiHub1MKsLeHD6UQ2VevYDDYfviBTs=; b=clRv+DkARP9eP9ehTiHIqpTICrL3WN240E6rpf0c22xPEEBToAVuehDz EqhZQqmVY0hZXwFSrABIBFhiouDhrkFobGf6V0/JbeBI9DfmSKKya4YMZ kxXKOvT1KCpW7wAHl1JTQChQV1b+hQWNFo1VCxpVNgDop+dASdFy5CVRc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D0AQDPLQBW/51dJa1dgySBQ71AAQ2HdIE3OBQBAQEBAQEBgQqEJgQ6PxIBPkInBAENiDPLEQEBAQEBAQEBAQEBAQEBAQEBAQEZiQKHe4MfgRQFlWQBdowQmxkBHwEBQoQBiVmBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,568,1437436800"; d="scan'208";a="30666001" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 21 Sep 2015 16:20:35 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t8LGKZX1030150 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Sep 2015 16:20:35 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 21 Sep 2015 11:20:34 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.000; Mon, 21 Sep 2015 11:20:34 -0500 From: "Brian Weis (bew)" To: The IESG , "secdir@ietf.org" Thread-Topic: Secdir review of draft-housley-sow-author-statistics-00 Thread-Index: AQHQ9IlxCj3sTSDbo0+nPTqc+MpEgA== Date: Mon, 21 Sep 2015 16:20:34 +0000 Message-ID: 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.24.200.178] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-housley-sow-author-statistics.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-housley-sow-author-statistics-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 16:20:38 -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 com= ments 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. This draft outlines requirements for a statement of work to provide statist= ics about RFCs, Internet-Drafts, and their authors. There are no particular= security considerations to the statement of work. There are also no privac= y considerations that I can see, insomuch that the results will formalize t= he existing tools that gather statistics, and the statistics are gathered f= rom previously published documents. I consider this draft to be Ready to publish. Brian= From nobody Mon Sep 21 09:42:34 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7401A9139; Mon, 21 Sep 2015 09:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 lafuCjYbaRuA; Mon, 21 Sep 2015 09:29:50 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::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 247481A9127; Mon, 21 Sep 2015 09:29:49 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so119587622wic.0; Mon, 21 Sep 2015 09:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MC4lsP9vFFJwW0UAc57DOFe9JLGKN3yA6hUXNkkoIsM=; b=uQbwFexMrd9ty5W5S72WCGqw/lBf7zASKBuiOOe6cPQ3Krs/rxiPBMI9ELV3+tnIWL dmruxIFuQ+VTfUSNbP30ipnLGJm2IeSHFE5kwaepSaRRFRga0WNIDrhp19DmNYSJZw9y zR/H91obZcHTkcvCAX4RWBTDmQx3Gely6Kk0JAsNz85/zjhkfs2NsK6/PdHK91nPF+Ih SaYSRK2scVV9S22Gh4PquAhZyqx2WMnADG+lTJvh6rfIa0FX4YmWJBW7lJ5edFgVpsAF FCw2yYrLmiw8EAJf8wKjSOlRil/31EP44l8lAJG17U65L6T7a+Pgp7lO1izRUP0zYWAO EXfA== X-Received: by 10.194.23.167 with SMTP id n7mr23196701wjf.112.1442852987728; Mon, 21 Sep 2015 09:29:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.9.212 with HTTP; Mon, 21 Sep 2015 09:29:28 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Mon, 21 Sep 2015 12:29:28 -0400 Message-ID: To: Sam Hartman Content-Type: multipart/alternative; boundary=047d7b5d33eecbf960052044630c Archived-At: X-Mailman-Approved-At: Mon, 21 Sep 2015 09:42:33 -0700 Cc: sec-ads@ietf.org, draft-ietf-teas-fast-lsps-requirements.all@ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] Secdir Review of draft-ietf-teas-fast-lsps-requirements-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 16:29:58 -0000 --047d7b5d33eecbf960052044630c Content-Type: text/plain; charset=UTF-8 Sam, Thanks for your comments. We (the authors) will await further review from the IESG before taking any particular action. Cheers, Andy On Mon, Sep 21, 2015 at 11:55 AM, Sam Hartman wrote: > > Hi. > I am the assigned secdir reviewer for this draft on requirements for > very fast GMPLS path establishment. > > This draft outlines scaling requirements for new applications of GMPLS. > > I'd like to flag this draft for particular review from the security ADs > and recommend that the IESG consider a process question and get input > from the sponsoring AD. > > So, for the security ADS: > The security considerations section reads in its entirety: > > . Security Considerations > > Being able to support very fast setup and a high churn rate of GMPLS > LSPs is not expected to adversely affect the underlying security > issues associated with existing GMPLS signaling. > > > however the draft talks about increasing the number of cases where GMPLS > paths cross administrative boundaries and significantly increasing the > scale of GMPLS applications. > > I don't think we have good security solutions for cases where we're > trying to do PCE-like things across mutually suspicious or potentially > hostile administrative boundaries. > And yes it's reasonable to assume that there are business relationships > in place here, but we also understand from our experience with BGP and > other internet-scale services the limitations of that. > > I think significantly more security work is consider. > > On a general level, there's basically no justification for the > requirements given. > For example, the document talks about how cloud computing is an > application that will drive these requirements. The document neither > talks about nor cites any explanation of what it is about cloud > computing that creates that need nor gives the reader any ability to > evaluate whether the need is real. > The depth of analysis is similar for all the other cited applications. > We jump from very broad staments like "cloud computing, datacenters and > data visualization will need this," to specific requirements in terms of > requests per second. > > I'd particularly like to call out section 2: > 2. Background > > The Defense Advanced Research Projects Agency (DARPA) Core Optical > Networks (CORONET) program [Chiu], is an example target > environment > that includes IP and optical commercial and government > networks, with > a focus on highly dynamic and resilient multi-terabit core > networks. > It anticipates the need for rapid (sub-second) setup > and SONET/SDH- > like restoration times for high-churn (up to tens of > requests per > second network-wide and holding times as short as > one second) on- > demand wavelength, sub-wavelength and packet > services for a variety > of applications (e.g., grid computing, > cloud computing, data > visualization, fast data transfer, > etc.). This must be done while > meeting stringent call blocking > requirements, and while minimizing > the use of resources such as time > slots, switch ports, wavelength > conversion, etc. > > I recommend that someone take a look at the material on that DARPA > project and see how well the DARPA requirements align with the > recommendations in this spec. > I'm somewhat concerned that DARPA put together a research project and > said "Hey we'd like these things," and now the IETF, without any > significant independent analysis is rubber stamping that as our > requirements in this space. > > I don't know that's what happened here, thus I have not copied > ietf@ietf.org. > However, DARPA's request should not represent an informed consensus of > the IETF. > I'd like to see the IESG evaluate whether we actually have done our own > analysis here and whether there is an informed consensus behind this > document. > > Thanks for your consideration, > > --Sam > --047d7b5d33eecbf960052044630c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sam,

Thanks for your comments. We (the = authors) will await further review from the IESG before taking any particul= ar action.

Cheers,
Andy


On Mon,= Sep 21, 2015 at 11:55 AM, Sam Hartman <hartmans-ietf@mit.edu><= /span> wrote:

Hi.
I am the assigned secdir reviewer for this draft on requirements for
very fast GMPLS path establishment.

This draft outlines scaling requirements for new applications of GMPLS.

I'd like to flag this draft for particular review from the security ADs=
and recommend that the IESG consider a process question and get input
from the sponsoring AD.

So, for the security ADS:
The security considerations section reads in its entirety:

.=C2=A0 Security Considerations

=C2=A0 =C2=A0Being able to support very fast setup and a high churn rate of= GMPLS
=C2=A0 =C2=A0LSPs is not expected to adversely affect the underlying securi= ty
=C2=A0 =C2=A0issues associated with existing GMPLS signaling.


however the draft talks about increasing the number of cases where GMPLS paths cross administrative boundaries and significantly increasing the
scale of GMPLS applications.

I don't think we have good security solutions for cases where we're=
trying to do PCE-like things across mutually suspicious or potentially
hostile administrative boundaries.
And yes it's reasonable to assume that there are business relationships=
in place here, but we also understand from our experience with BGP and
other internet-scale services the limitations of that.

I think significantly more security work is consider.

On a general level, there's basically no justification for the
requirements given.
For example, the document talks about how cloud computing is an
application that will drive these requirements.=C2=A0 The document neither<= br> talks about nor cites any explanation of=C2=A0 what it is about cloud
computing that creates that need nor gives the reader any ability to
evaluate whether the need is real.
The depth of analysis is similar for all the other cited applications.
We jump from very broad staments like "cloud computing, datacenters an= d
data visualization will need this," to specific requirements in terms = of
requests per second.

I'd particularly like to call out section 2:
=C2=A0 =C2=A0 2.=C2=A0 Background

=C2=A0 =C2=A0 =C2=A0 =C2=A0The Defense Advanced Research Projects Agency (D= ARPA) Core Optical
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Networks (CORONET) program [Chiu], is an= example target environment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that includes IP and optica= l commercial and government networks, with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a focus on highly d= ynamic and resilient multi-terabit core networks.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It ant= icipates the need for rapid (sub-second) setup and SONET/SDH-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 like restoration times for high-churn (up to tens of requests per
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0second network-wide and holding times as short as one seco= nd) on-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 demand wavelength, sub-wavelength and packet servi= ces for a variety
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of applications (e.g., grid computing= , cloud computing, data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 visualization, fast data tran= sfer, etc.).=C2=A0 This must be done while
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0meeting stringen= t call blocking requirements, and while minimizing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the use = of resources such as time slots, switch ports, wavelength
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0conversion, etc.

I recommend that someone take a look at the material on that DARPA
project and see how well the DARPA requirements align with the
recommendations in this spec.
I'm somewhat concerned that DARPA put together a research project and said "Hey we'd like these things," and now the IETF, without = any
significant independent analysis is rubber stamping that as our
requirements in this space.

I don't know that's what happened here, thus I have not copied
ietf@ietf.org.
However, DARPA's request should not represent an informed consensus of<= br> the IETF.
I'd like to see the IESG evaluate whether we actually have done our own=
analysis here and whether there is an informed consensus=C2=A0 behind this<= br> document.

Thanks for your consideration,

--Sam

--047d7b5d33eecbf960052044630c-- From nobody Mon Sep 21 10:58:19 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CCD1ACE15 for ; Mon, 21 Sep 2015 10:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 n0NqGIAXbeAi for ; Mon, 21 Sep 2015 10:58:15 -0700 (PDT) Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com [209.85.160.182]) (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 51B631ACE06 for ; Mon, 21 Sep 2015 10:58:13 -0700 (PDT) Received: by ykdz138 with SMTP id z138so29533071ykd.2 for ; Mon, 21 Sep 2015 10:58:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Col85FjPA+4EEQG4q1afABKuVN3FBZ5hf9ul4o6EoCY=; b=SZYqVrih//UkMxhIz3D51spkjgRxdv3AVsyeGc4/2sMm6HfRu14qcAdW1dMhOa4GRO wmWnFPv0prgYy1myJ59EKgnPphiy8jLTQlVxb/lTcRPnwIv3uwOVGEdotTLuD5YXb0if MqqtF9gZCN1HORLHxVsYAATQdyU370bauOm6v9XrprUya2pRZHjMILQg2Rll1mMjjTYQ SJXL4iCUnnJhF5dW+Pmp/oPufAaVGgL09wZB8v389g6tWHXUnpdfNPW2tMvv8n33fNN5 KVU+ElgLbGjLqPIVGpZNnTmqOnAKfYucu7KDQNdOo8UyK8Ort5S6M2DlWbeE/2y6QjK6 LQHQ== X-Gm-Message-State: ALoCoQkSdZ3cvOIfYsVAHj0CzuPleb8KKkweSuJaTvA0ji9/AOAS1ofvaL8ptBlBMo6LVM2WJJbZ MIME-Version: 1.0 X-Received: by 10.170.133.144 with SMTP id z138mr17469338ykb.111.1442858292488; Mon, 21 Sep 2015 10:58:12 -0700 (PDT) Received: by 10.37.52.135 with HTTP; Mon, 21 Sep 2015 10:58:12 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Sep 2015 13:58:12 -0400 Message-ID: From: Warren Kumari To: "Brian Weis (bew)" Content-Type: multipart/alternative; boundary=001a11397a96fc69870520459fca Archived-At: Cc: "draft-housley-sow-author-statistics.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-housley-sow-author-statistics-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 17:58:16 -0000 --001a11397a96fc69870520459fca Content-Type: text/plain; charset=UTF-8 I had not seen this draft until now, but I wanted to quickly insert myself into the conversation to thank Jari again for having provided these tools for so long. I have found them to be incredibly helpful - it's about the only way I know what drafts I have active, and what I need to do next... It will be great to have this in the datatracker if Jari cannot continue to run it on Arkko.net W On Monday, September 21, 2015, Brian Weis (bew) 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. > > This draft outlines requirements for a statement of work to provide > statistics about RFCs, Internet-Drafts, and their authors. There are no > particular security considerations to the statement of work. There are also > no privacy considerations that I can see, insomuch that the results will > formalize the existing tools that gather statistics, and the statistics are > gathered from previously published documents. > > I consider this draft to be Ready to publish. > > Brian > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --001a11397a96fc69870520459fca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I had not seen this draft until now, but I wanted to quickly insert myself = into the conversation to thank Jari again for having provided these tools f= or so long.=C2=A0
I have found =C2=A0them to be incredibly helpful - it= 's about the only way I know what drafts I have active, and what I need= to do next...

It will be great to have this in th= e datatracker if Jari cannot continue to run it on Arkko.net


W
On Monday, September 21, 2015, Brian Weis (bew) <bew@cisco.com> wrote:
I have reviewed this document as part of the security directo= rate's ongoing effort to review all IETF documents being processed by t= he IESG. These comments were written primarily for the benefit of the secur= ity area directors. Document editors and WG chairs should treat these comme= nts just like any other last call comments.

This draft outlines requirements for a statement of work to provide statist= ics about RFCs, Internet-Drafts, and their authors. There are no particular= security considerations to the statement of work. There are also no privac= y considerations that I can see, insomuch that the results will formalize t= he existing tools that gather statistics, and the statistics are gathered f= rom previously published documents.

I consider this draft to be Ready to publish.

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


--
I don't think the execution is releva= nt when it was obviously a bad idea in the first place.
This is like put= ting rabid weasels in your pants, and later expressing regret at having cho= sen those particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0= ---maf
--001a11397a96fc69870520459fca-- From nobody Mon Sep 21 14:24:05 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9661A904A; Mon, 21 Sep 2015 14:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 AO7T1y2qnMW2; Mon, 21 Sep 2015 14:10:17 -0700 (PDT) Received: from mx0b-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 128A41A9034; Mon, 21 Sep 2015 14:10:17 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t8LL9VEX048788; Mon, 21 Sep 2015 17:10:15 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 1x2n4ck9m2-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Sep 2015 17:10:14 -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 t8LLADjd017479; Mon, 21 Sep 2015 17:10:13 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8LL9xCb017258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 21 Sep 2015 17:10:09 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 21 Sep 2015 21:09:47 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.138]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0248.002; Mon, 21 Sep 2015 17:09:47 -0400 From: "BRUNGARD, DEBORAH A" To: "Andrew G. Malis" , Sam Hartman Thread-Topic: Secdir Review of draft-ietf-teas-fast-lsps-requirements-01 Thread-Index: AQHQ9IYJxnPjPhMq40utAuh70RK6mp5Hb2AA///9luA= Date: Mon, 21 Sep 2015 21:09:46 +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: [135.70.100.84] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C85272FBC1MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-21_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509210295 Archived-At: X-Mailman-Approved-At: Mon, 21 Sep 2015 14:24:04 -0700 Cc: "sec-ads@ietf.org" , "draft-ietf-teas-fast-lsps-requirements.all@ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir Review of draft-ietf-teas-fast-lsps-requirements-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 21:10:26 -0000 --_000_F64C10EAA68C8044B33656FA214632C85272FBC1MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FtLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KDQpJIHNlZSBiYXNpY2FsbHkgdHdv IGNvbmNlcm5zLCBvbmUgcXVlc3Rpb25pbmcgdGhlIHNlY3VyaXR5IGFzcGVjdHMsIHRoZSBvdGhl ciBvbiB0aGUgZ2VuZXJhbCBsZXZlbCBxdWVzdGlvbmluZyB0aGUgZG9jdW1lbnQgaXRzZWxmLg0K DQpBcyB0aGUgZ2VuZXJhbCBsZXZlbCBjb25jZXJuIGlzIG11Y2ggbW9yZSBzZXJpb3VzLCBsZXTi gJlzIGFkZHJlc3MgaXQgZmlyc3QuIE1heWJlIHNvbWUgYmFja2dyb3VuZCB3b3VsZCBoZWxwLiBJ IHdhcyBjaGFpciBvZiBDQ0FNUCBhbmQgdGhlbiBURUFTIHdoZW4gdGhlIGRvY3VtZW50IHRyYW5z aXRpb25lZCB0byBURUFTLiBBdCBmaXJzdCB0aGUgZG9jdW1lbnQgd2FzIHdyaXR0ZW4gaW4gdGhl IHN0eWxlIG9mIGJlaW5nIHF1aXRlIG5lZ2F0aXZlIG9uIEdNUExTIGFzIHRoZSBpZGVudGlmaWVk IHByb2JsZW1zIHdlcmUgYmFzZWQgb24gaW5jb3JyZWN0IGludGVycHJldGF0aW9uIG9mIHRoZSBS RkNzIChicm9rZW4gaW1wbGVtZW50YXRpb25zKS4gU28gdGhlIFdHIGFza2VkIHRoZSBhdXRob3Jz IHRvIGZpcnN0IGJlIHByZWNpc2Ugb24gdGhlaXIgcmVxdWlyZW1lbnRzIGJlZm9yZSBhc3N1bWlu ZyBuZXcgc29sdXRpb25zIHdlcmUgbmVlZGVkLiBBZnRlciBzZXZlcmFsIHNwaW5zLCB0aGUgV0cg d2FzIGNvbWZvcnRhYmxlIHdpdGggdGhlIHJlcXVpcmVtZW50cy4gRm9sa3MgZGlkbuKAmXQgcXVl c3Rpb24gdGhlIHJlcXVpcmVtZW50cyB0aGVtc2VsdmVzIGFzIEdNUExTIGlzIHRhcmdldGVkIGF0 IGFwcGxpY2F0aW9ucyBmb3IgaW1wcm92aW5nIGNvbm5lY3Rpb24gc2V0IHVwIHRpbWVzIGZvciBs YXJnZSBtZXNoIG5ldHdvcmtzIHZzLiB1c2luZyBhIFBDRS9tYW5hZ2VtZW50IHN5c3RlbS4gQW5k IHdoZW4gYXNrZWQsIHRoZSBhdXRob3JzIHNhaWQgdGhpcyB3YXMgbm90IHRhcmdldGVkIGZvciB3 YXZlbGVuZ3RocyAod2hlcmUgdGhlIHBoeXNpY2FsIGNvbm5lY3Rpdml0eSBpcyBtb3JlIGNvbnN0 cmFpbmluZyB0aGFuIHRoZSBjb250cm9sIHBsYW5lIHNpZ25hbGluZykgYnV0IE9UTiAoT3B0aWNh bCBUcmFuc3BvcnQgTmV0d29yayBpcyBhIGRpZ2l0YWwgZnJhbWUpIGUuZy4gZnJvbSBNYXJjaCAy MDE0IENDQU1QIE1lZXRpbmcgTm90ZXM6DQrigJxMb3UgQmVyZ2VyOiBbcG9sbF0gaG93IG1hbnkg aGF2ZSByZWFkIHRoZSBkb2N1bWVudCBbXSBob3cgbWFueSB0aGluayB0aGlzIGlzIGFuIGludGVy ZXN0aW5nIHByb2JsZW0gdG8gZGlzY3Vzcz8gW2EgZ29vZCBudW1iZXIgZm9yIGVhY2hdDQpHZW9y Z2UgU3dhbGxvdzogV2hhdCBpcyBhY2hpZXZhYmxlIGZvciBPVE4gaXMgbXVjaCBjbG9zZXIgdG8g eW91ciByZXF1aXJlbWVudHMgdGhhbiB3aGF0IGlzIGFjaGlldmFibGUgZm9yIG9wdGljYWwuIEkg d2FzIHdvbmRlcmluZyBpZiByZXF1aXJlbWVudHMgYXBwbHkgdG8gYm90aC4NCkFuZHkgTWFsaXM6 IFRoZXkgYXBwbHkgdG8gYm90aCwgd2UgaGF2ZSBwb3NzaWJsZSBzb2x1dGlvbnMgZm9yIGJvdGgg YnV0IGJlZm9yZSBjb21pbmcgd2l0aCBzb2x1dGlvbnMgd2Ugd2FudCBhbiBhZ3JlZW1lbnQgb24g cmVxdWlyZW1lbnRzLg0KUmFqYW4gUmFvOiBJZiB3ZSBoYXZlIHNlcGFyYXRlIGRhdGEgcGxhbmUg YW5kIGNvbnRyb2wgcGxhbmUgcmVxdWlyZW1lbnRzLCBpZiB0aGUgdHJhZmZpYyBkb2VzbuKAmXQg Y29tZSBvdXQsIHdoYXQgZG9lcyBpdCByZWFsbHkgbWVhbj8NCkxvdSBCZXJnZXI6IHF1ZXN0aW9u IGZvciB0aGUgbGlzdC4NCkFkcmlhbiBGYXJyZWw6IEkgbGlrZSB0aGlzIHNldCBvZiByZXF1aXJl bWVudHMsIEkgaGF0ZSB5b3Ugc2F5IHlvdSBjYW4ndCBzb2x2ZSB0aGVtIHdpdGggZXhpc3Rpbmcg c3R1ZmYuIFB1c2ggcmVxdWlyZW1lbnRzIGFuZCB0aGVuIHdlIGNhbiB3b3JrIG9uIGFuIGFwcGxp Y2FiaWxpdHkgdG8gc2VlIGlmIGV4aXN0aW5nIHNvbHV0aW9ucyBjYW4gbWVldCB0aGVtLuKAnQ0K DQpUaGUgU2hlcGhlcmQgd3JpdGV1cCBwcm92aWRlcyBtb3JlIGRldGFpbC4gQW5kIHRoaXMgaXMg bm90IHRoZSBmaXJzdCBkb2N1bWVudCBkaXNjdXNzaW5nIG9wdGltaXppbmcgc2V0IHVwIHRpbWVz LiBSRkM2MzgzIHdhcyBvbiBvcHRpbWl6YXRpb25zIGFuZCByZWNlbnRseSB0aGUgTVBMUyBXRyBo YXMganVzdCBjb21wbGV0ZWQgZHJhZnQtaWV0Zi1tcGxzLXNlbGYtcGluZy4NCg0KSWYgeW91IHN0 aWxsIGFyZSB1bmNvbWZvcnRhYmxlIHdpdGggdGhlc2UgcmVxdWlyZW1lbnRzLCBpdCB3b3VsZCBi ZSBiZXN0IGlmIHlvdSBleHByZXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgVEVBUyBXRy4gSSBu b3RlZCB5b3UgZGlkIG5vdCBpbmNsdWRlIHRoZW0gb24geW91ciByZXZpZXcuDQoNCk9uIHlvdXIg c2Vjb25kIGNvbmNlcm4sIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMuIFRoaXMgaXMgYW4gaW5m b3JtYXRpb25hbCBkb2N1bWVudC4gQXMgdGhlIHNoZXBoZXJkIHdyaXRldXAgbm90ZXMg4oCcVGhl IHJlcXVpcmVtZW50cyBwdXQgZm9ydGggaW4gdGhpcyBkb2N1bWVudCBtYXkgYmUgdGhlIGJhc2lz IGZvciBmdXR1cmUgZG9jdW1lbnRzLCBzb21lIG9mIHdoaWNoIG1heSBiZSBzaW1wbHkgaW5mb3Jt YXRpb25hbCwgd2hpbGUgb3RoZXJzIG1heSBkZXNjcmliZSBzcGVjaWZpYyBHTVBMUyBwcm90b2Nv bCBleHRlbnNpb25zLiBXaGlsZSBzb21lIG9mIHRoZXNlIHJlcXVpcmVtZW50cyBtYXkgYmUgaGF2 ZSBpbXBsaWNhdGlvbnMgb24gaW1wbGVtZW50YXRpb25zLCB0aGUgaW50ZW50DQppcyBmb3IgdGhl IHJlcXVpcmVtZW50cyB0byBhcHBseSB0byBHTVBMUyBwcm90b2NvbHMgYW5kIHRoZWlyIHN0YW5k YXJkaXplZCBtZWNoYW5pc21zLuKAnQ0KDQpTbyBpdCBpcyB1bmNsZWFyIGF0IHRoaXMgdGltZSBp ZiBvbmx5IGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGlzIG5lZWRlZCAoaW5mb3JtYXRpb25h bCBvbiB0aGUg4oCcY29ycmVjdOKAnSB1c2Ugb2YgR01QTFMgcHJvdG9jb2xzL21lY2hhbmlzbXMg YW5kIGFuIHVuZGVyc3RhbmRpbmcgb2YgdGhlIHNpZ25hbGluZyBhc3BlY3RzIHZzLiB0aGUgcHJv Y2Vzc2luZy9pbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQgYXNwZWN0cykgb3IgaWYgbmV3IGV4dGVu c2lvbnMvbWVjaGFuaXNtcyBhcmUgbmVlZGVkLiBGb3IgdGhlIHNlY3VyaXR5IHNlY3Rpb24sIGl0 IHdhcyB3cml0dGVuIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgZWl0aGVyIHRoaXMgd2ls bCBvbmx5IG5lZWQgYW4gYXBwbGljYWJpbGl0eSBkb2N1bWVudCBhbmQsIGlmIGl0IG5lZWRzIG1v cmUsIHRoYW4gb25lIGhhcyBzb21ldGhpbmcgdG8gYmFzZSBhIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zLiBXaXRoIHRoaXMgYmFja2dyb3VuZCwgZG8geW91IGhhdmUgc3VnZ2VzdGlvbnMgdG8gaGVs cCB0aGUgYXV0aG9ycyBpbXByb3ZlIHRoaXMgc2VjdGlvbj8NCg0KQWdhaW4sIHRoYW5rcyBmb3Ig eW91ciByZXZpZXctDQpEZWJvcmFoDQoNCg0KRnJvbTogQW5kcmV3IEcuIE1hbGlzIFttYWlsdG86 YWdtYWxpc0BnbWFpbC5jb21dDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAyMSwgMjAxNSAxMjoy OSBQTQ0KVG86IFNhbSBIYXJ0bWFuDQpDYzogc2VjZGlyQGlldGYub3JnOyBzZWMtYWRzQGlldGYu b3JnOyBJRVNHOyBkcmFmdC1pZXRmLXRlYXMtZmFzdC1sc3BzLXJlcXVpcmVtZW50cy5hbGxAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBTZWNkaXIgUmV2aWV3IG9mIGRyYWZ0LWlldGYtdGVhcy1mYXN0 LWxzcHMtcmVxdWlyZW1lbnRzLTAxDQoNClNhbSwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRz LiBXZSAodGhlIGF1dGhvcnMpIHdpbGwgYXdhaXQgZnVydGhlciByZXZpZXcgZnJvbSB0aGUgSUVT RyBiZWZvcmUgdGFraW5nIGFueSBwYXJ0aWN1bGFyIGFjdGlvbi4NCg0KQ2hlZXJzLA0KQW5keQ0K DQoNCk9uIE1vbiwgU2VwIDIxLCAyMDE1IGF0IDExOjU1IEFNLCBTYW0gSGFydG1hbiA8aGFydG1h bnMtaWV0ZkBtaXQuZWR1PG1haWx0bzpoYXJ0bWFucy1pZXRmQG1pdC5lZHU+PiB3cm90ZToNCg0K SGkuDQpJIGFtIHRoZSBhc3NpZ25lZCBzZWNkaXIgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQgb24g cmVxdWlyZW1lbnRzIGZvcg0KdmVyeSBmYXN0IEdNUExTIHBhdGggZXN0YWJsaXNobWVudC4NCg0K VGhpcyBkcmFmdCBvdXRsaW5lcyBzY2FsaW5nIHJlcXVpcmVtZW50cyBmb3IgbmV3IGFwcGxpY2F0 aW9ucyBvZiBHTVBMUy4NCg0KSSdkIGxpa2UgdG8gZmxhZyB0aGlzIGRyYWZ0IGZvciBwYXJ0aWN1 bGFyIHJldmlldyBmcm9tIHRoZSBzZWN1cml0eSBBRHMNCmFuZCByZWNvbW1lbmQgdGhhdCB0aGUg SUVTRyBjb25zaWRlciBhIHByb2Nlc3MgcXVlc3Rpb24gYW5kIGdldCBpbnB1dA0KZnJvbSB0aGUg c3BvbnNvcmluZyBBRC4NCg0KU28sIGZvciB0aGUgc2VjdXJpdHkgQURTOg0KVGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gcmVhZHMgaW4gaXRzIGVudGlyZXR5Og0KDQouICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBCZWluZyBhYmxlIHRvIHN1cHBvcnQgdmVyeSBmYXN0 IHNldHVwIGFuZCBhIGhpZ2ggY2h1cm4gcmF0ZSBvZiBHTVBMUw0KICAgTFNQcyBpcyBub3QgZXhw ZWN0ZWQgdG8gYWR2ZXJzZWx5IGFmZmVjdCB0aGUgdW5kZXJseWluZyBzZWN1cml0eQ0KICAgaXNz dWVzIGFzc29jaWF0ZWQgd2l0aCBleGlzdGluZyBHTVBMUyBzaWduYWxpbmcuDQoNCg0KaG93ZXZl ciB0aGUgZHJhZnQgdGFsa3MgYWJvdXQgaW5jcmVhc2luZyB0aGUgbnVtYmVyIG9mIGNhc2VzIHdo ZXJlIEdNUExTDQpwYXRocyBjcm9zcyBhZG1pbmlzdHJhdGl2ZSBib3VuZGFyaWVzIGFuZCBzaWdu aWZpY2FudGx5IGluY3JlYXNpbmcgdGhlDQpzY2FsZSBvZiBHTVBMUyBhcHBsaWNhdGlvbnMuDQoN CkkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSBnb29kIHNlY3VyaXR5IHNvbHV0aW9ucyBmb3IgY2FzZXMg d2hlcmUgd2UncmUNCnRyeWluZyB0byBkbyBQQ0UtbGlrZSB0aGluZ3MgYWNyb3NzIG11dHVhbGx5 IHN1c3BpY2lvdXMgb3IgcG90ZW50aWFsbHkNCmhvc3RpbGUgYWRtaW5pc3RyYXRpdmUgYm91bmRh cmllcy4NCkFuZCB5ZXMgaXQncyByZWFzb25hYmxlIHRvIGFzc3VtZSB0aGF0IHRoZXJlIGFyZSBi dXNpbmVzcyByZWxhdGlvbnNoaXBzDQppbiBwbGFjZSBoZXJlLCBidXQgd2UgYWxzbyB1bmRlcnN0 YW5kIGZyb20gb3VyIGV4cGVyaWVuY2Ugd2l0aCBCR1AgYW5kDQpvdGhlciBpbnRlcm5ldC1zY2Fs ZSBzZXJ2aWNlcyB0aGUgbGltaXRhdGlvbnMgb2YgdGhhdC4NCg0KSSB0aGluayBzaWduaWZpY2Fu dGx5IG1vcmUgc2VjdXJpdHkgd29yayBpcyBjb25zaWRlci4NCg0KT24gYSBnZW5lcmFsIGxldmVs LCB0aGVyZSdzIGJhc2ljYWxseSBubyBqdXN0aWZpY2F0aW9uIGZvciB0aGUNCnJlcXVpcmVtZW50 cyBnaXZlbi4NCkZvciBleGFtcGxlLCB0aGUgZG9jdW1lbnQgdGFsa3MgYWJvdXQgaG93IGNsb3Vk IGNvbXB1dGluZyBpcyBhbg0KYXBwbGljYXRpb24gdGhhdCB3aWxsIGRyaXZlIHRoZXNlIHJlcXVp cmVtZW50cy4gIFRoZSBkb2N1bWVudCBuZWl0aGVyDQp0YWxrcyBhYm91dCBub3IgY2l0ZXMgYW55 IGV4cGxhbmF0aW9uIG9mICB3aGF0IGl0IGlzIGFib3V0IGNsb3VkDQpjb21wdXRpbmcgdGhhdCBj cmVhdGVzIHRoYXQgbmVlZCBub3IgZ2l2ZXMgdGhlIHJlYWRlciBhbnkgYWJpbGl0eSB0bw0KZXZh bHVhdGUgd2hldGhlciB0aGUgbmVlZCBpcyByZWFsLg0KVGhlIGRlcHRoIG9mIGFuYWx5c2lzIGlz IHNpbWlsYXIgZm9yIGFsbCB0aGUgb3RoZXIgY2l0ZWQgYXBwbGljYXRpb25zLg0KV2UganVtcCBm cm9tIHZlcnkgYnJvYWQgc3RhbWVudHMgbGlrZSAiY2xvdWQgY29tcHV0aW5nLCBkYXRhY2VudGVy cyBhbmQNCmRhdGEgdmlzdWFsaXphdGlvbiB3aWxsIG5lZWQgdGhpcywiIHRvIHNwZWNpZmljIHJl cXVpcmVtZW50cyBpbiB0ZXJtcyBvZg0KcmVxdWVzdHMgcGVyIHNlY29uZC4NCg0KSSdkIHBhcnRp Y3VsYXJseSBsaWtlIHRvIGNhbGwgb3V0IHNlY3Rpb24gMjoNCiAgICAyLiAgQmFja2dyb3VuZA0K DQogICAgICAgVGhlIERlZmVuc2UgQWR2YW5jZWQgUmVzZWFyY2ggUHJvamVjdHMgQWdlbmN5IChE QVJQQSkgQ29yZSBPcHRpY2FsDQogICAgICAgICAgTmV0d29ya3MgKENPUk9ORVQpIHByb2dyYW0g W0NoaXVdLCBpcyBhbiBleGFtcGxlIHRhcmdldCBlbnZpcm9ubWVudA0KICAgICAgICAgICAgIHRo YXQgaW5jbHVkZXMgSVAgYW5kIG9wdGljYWwgY29tbWVyY2lhbCBhbmQgZ292ZXJubWVudCBuZXR3 b3Jrcywgd2l0aA0KICAgICAgICAgICAgICAgIGEgZm9jdXMgb24gaGlnaGx5IGR5bmFtaWMgYW5k IHJlc2lsaWVudCBtdWx0aS10ZXJhYml0IGNvcmUgbmV0d29ya3MuDQogICAgICAgICAgICAgICAg ICAgSXQgYW50aWNpcGF0ZXMgdGhlIG5lZWQgZm9yIHJhcGlkIChzdWItc2Vjb25kKSBzZXR1cCBh bmQgU09ORVQvU0RILQ0KICAgICAgICAgICAgICAgICAgICAgIGxpa2UgcmVzdG9yYXRpb24gdGlt ZXMgZm9yIGhpZ2gtY2h1cm4gKHVwIHRvIHRlbnMgb2YgcmVxdWVzdHMgcGVyDQogICAgICAgICAg ICAgICAgICAgICAgICAgc2Vjb25kIG5ldHdvcmstd2lkZSBhbmQgaG9sZGluZyB0aW1lcyBhcyBz aG9ydCBhcyBvbmUgc2Vjb25kKSBvbi0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZW1h bmQgd2F2ZWxlbmd0aCwgc3ViLXdhdmVsZW5ndGggYW5kIHBhY2tldCBzZXJ2aWNlcyBmb3IgYSB2 YXJpZXR5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2YgYXBwbGljYXRpb25zIChl LmcuLCBncmlkIGNvbXB1dGluZywgY2xvdWQgY29tcHV0aW5nLCBkYXRhDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdmlzdWFsaXphdGlvbiwgZmFzdCBkYXRhIHRyYW5zZmVyLCBl dGMuKS4gIFRoaXMgbXVzdCBiZSBkb25lIHdoaWxlDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgbWVldGluZyBzdHJpbmdlbnQgY2FsbCBibG9ja2luZyByZXF1aXJlbWVudHMs IGFuZCB3aGlsZSBtaW5pbWl6aW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdGhlIHVzZSBvZiByZXNvdXJjZXMgc3VjaCBhcyB0aW1lIHNsb3RzLCBzd2l0Y2ggcG9y dHMsIHdhdmVsZW5ndGgNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjb252ZXJzaW9uLCBldGMuDQoNCkkgcmVjb21tZW5kIHRoYXQgc29tZW9uZSB0YWtlIGEgbG9v ayBhdCB0aGUgbWF0ZXJpYWwgb24gdGhhdCBEQVJQQQ0KcHJvamVjdCBhbmQgc2VlIGhvdyB3ZWxs IHRoZSBEQVJQQSByZXF1aXJlbWVudHMgYWxpZ24gd2l0aCB0aGUNCnJlY29tbWVuZGF0aW9ucyBp biB0aGlzIHNwZWMuDQpJJ20gc29tZXdoYXQgY29uY2VybmVkIHRoYXQgREFSUEEgcHV0IHRvZ2V0 aGVyIGEgcmVzZWFyY2ggcHJvamVjdCBhbmQNCnNhaWQgIkhleSB3ZSdkIGxpa2UgdGhlc2UgdGhp bmdzLCIgYW5kIG5vdyB0aGUgSUVURiwgd2l0aG91dCBhbnkNCnNpZ25pZmljYW50IGluZGVwZW5k ZW50IGFuYWx5c2lzIGlzIHJ1YmJlciBzdGFtcGluZyB0aGF0IGFzIG91cg0KcmVxdWlyZW1lbnRz IGluIHRoaXMgc3BhY2UuDQoNCkkgZG9uJ3Qga25vdyB0aGF0J3Mgd2hhdCBoYXBwZW5lZCBoZXJl LCB0aHVzIEkgaGF2ZSBub3QgY29waWVkDQppZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGlldGYu b3JnPi4NCkhvd2V2ZXIsIERBUlBBJ3MgcmVxdWVzdCBzaG91bGQgbm90IHJlcHJlc2VudCBhbiBp bmZvcm1lZCBjb25zZW5zdXMgb2YNCnRoZSBJRVRGLg0KSSdkIGxpa2UgdG8gc2VlIHRoZSBJRVNH IGV2YWx1YXRlIHdoZXRoZXIgd2UgYWN0dWFsbHkgaGF2ZSBkb25lIG91ciBvd24NCmFuYWx5c2lz IGhlcmUgYW5kIHdoZXRoZXIgdGhlcmUgaXMgYW4gaW5mb3JtZWQgY29uc2Vuc3VzICBiZWhpbmQg dGhpcw0KZG9jdW1lbnQuDQoNClRoYW5rcyBmb3IgeW91ciBjb25zaWRlcmF0aW9uLA0KDQotLVNh bQ0KDQo= --_000_F64C10EAA68C8044B33656FA214632C85272FBC1MISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgU2FtLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhhbmtzIGZvciB5b3VyIHJldmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgc2VlIGJhc2ljYWxseSB0d28g Y29uY2VybnMsIG9uZSBxdWVzdGlvbmluZyB0aGUgc2VjdXJpdHkgYXNwZWN0cywgdGhlIG90aGVy IG9uIHRoZSBnZW5lcmFsIGxldmVsIHF1ZXN0aW9uaW5nIHRoZSBkb2N1bWVudCBpdHNlbGYuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5BcyB0aGUgZ2VuZXJhbCBsZXZlbCBjb25jZXJuIGlzIG11Y2ggbW9yZSBzZXJpb3Vz LCBsZXTigJlzIGFkZHJlc3MgaXQgZmlyc3QuIE1heWJlIHNvbWUgYmFja2dyb3VuZCB3b3VsZCBo ZWxwLiBJIHdhcyBjaGFpciBvZiBDQ0FNUCBhbmQgdGhlbiBURUFTIHdoZW4gdGhlIGRvY3VtZW50 DQogdHJhbnNpdGlvbmVkIHRvIFRFQVMuIEF0IGZpcnN0IHRoZSBkb2N1bWVudCB3YXMgd3JpdHRl biBpbiB0aGUgc3R5bGUgb2YgYmVpbmcgcXVpdGUgbmVnYXRpdmUgb24gR01QTFMgYXMgdGhlIGlk ZW50aWZpZWQgcHJvYmxlbXMgd2VyZSBiYXNlZCBvbiBpbmNvcnJlY3QgaW50ZXJwcmV0YXRpb24g b2YgdGhlIFJGQ3MgKGJyb2tlbiBpbXBsZW1lbnRhdGlvbnMpLiBTbyB0aGUgV0cgYXNrZWQgdGhl IGF1dGhvcnMgdG8gZmlyc3QgYmUgcHJlY2lzZSBvbg0KIHRoZWlyIHJlcXVpcmVtZW50cyBiZWZv cmUgYXNzdW1pbmcgbmV3IHNvbHV0aW9ucyB3ZXJlIG5lZWRlZC4gQWZ0ZXIgc2V2ZXJhbCBzcGlu cywgdGhlIFdHIHdhcyBjb21mb3J0YWJsZSB3aXRoIHRoZSByZXF1aXJlbWVudHMuIEZvbGtzIGRp ZG7igJl0IHF1ZXN0aW9uIHRoZSByZXF1aXJlbWVudHMgdGhlbXNlbHZlcyBhcyBHTVBMUyBpcyB0 YXJnZXRlZCBhdCBhcHBsaWNhdGlvbnMgZm9yIGltcHJvdmluZyBjb25uZWN0aW9uIHNldCB1cCB0 aW1lcyBmb3INCiBsYXJnZSBtZXNoIG5ldHdvcmtzIHZzLiB1c2luZyBhIFBDRS9tYW5hZ2VtZW50 IHN5c3RlbS4gQW5kIHdoZW4gYXNrZWQsIHRoZSBhdXRob3JzIHNhaWQgdGhpcyB3YXMgbm90IHRh cmdldGVkIGZvciB3YXZlbGVuZ3RocyAod2hlcmUgdGhlIHBoeXNpY2FsIGNvbm5lY3Rpdml0eSBp cyBtb3JlIGNvbnN0cmFpbmluZyB0aGFuIHRoZSBjb250cm9sIHBsYW5lIHNpZ25hbGluZykgYnV0 IE9UTiAoT3B0aWNhbCBUcmFuc3BvcnQgTmV0d29yayBpcyBhIGRpZ2l0YWwNCiBmcmFtZSkgZS5n LiBmcm9tIE1hcmNoIDIwMTQgQ0NBTVAgTWVldGluZyBOb3Rlczo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+4oCcTG91IEJlcmdlcjogW3BvbGxdIGhvdyBtYW55IGhhdmUgcmVhZCB0aGUg ZG9jdW1lbnQgW10gaG93IG1hbnkgdGhpbmsgdGhpcyBpcyBhbiBpbnRlcmVzdGluZyBwcm9ibGVt IHRvIGRpc2N1c3M/IFthIGdvb2QgbnVtYmVyIGZvciBlYWNoXTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5HZW9yZ2UgU3dhbGxvdzogV2hhdCBpcyBhY2hpZXZhYmxlIGZvciBPVE4gaXMg bXVjaCBjbG9zZXIgdG8geW91ciByZXF1aXJlbWVudHMgdGhhbiB3aGF0IGlzIGFjaGlldmFibGUg Zm9yIG9wdGljYWwuIEkgd2FzIHdvbmRlcmluZyBpZiByZXF1aXJlbWVudHMgYXBwbHkgdG8NCiBi b3RoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmR5IE1hbGlzOiBUaGV5IGFwcGx5 IHRvIGJvdGgsIHdlIGhhdmUgcG9zc2libGUgc29sdXRpb25zIGZvciBib3RoIGJ1dCBiZWZvcmUg Y29taW5nIHdpdGggc29sdXRpb25zIHdlIHdhbnQgYW4gYWdyZWVtZW50IG9uIHJlcXVpcmVtZW50 cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmFqYW4gUmFvOiBJZiB3ZSBoYXZlIHNl cGFyYXRlIGRhdGEgcGxhbmUgYW5kIGNvbnRyb2wgcGxhbmUgcmVxdWlyZW1lbnRzLCBpZiB0aGUg dHJhZmZpYyBkb2VzbuKAmXQgY29tZSBvdXQsIHdoYXQgZG9lcyBpdCByZWFsbHkgbWVhbj88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TG91IEJlcmdlcjogcXVlc3Rpb24gZm9yIHRoZSBs aXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZHJpYW4gRmFycmVsOiBJIGxpa2Ug dGhpcyBzZXQgb2YgcmVxdWlyZW1lbnRzLCBJIGhhdGUgeW91IHNheSB5b3UgY2FuJ3Qgc29sdmUg dGhlbSB3aXRoIGV4aXN0aW5nIHN0dWZmLiBQdXNoIHJlcXVpcmVtZW50cyBhbmQgdGhlbiB3ZSBj YW4gd29yayBvbiBhbiBhcHBsaWNhYmlsaXR5DQogdG8gc2VlIGlmIGV4aXN0aW5nIHNvbHV0aW9u cyBjYW4gbWVldCB0aGVtLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIFNoZXBoZXJkIHdyaXRldXAgcHJvdmlk ZXMgbW9yZSBkZXRhaWwuIEFuZCB0aGlzIGlzIG5vdCB0aGUgZmlyc3QgZG9jdW1lbnQgZGlzY3Vz c2luZyBvcHRpbWl6aW5nIHNldCB1cCB0aW1lcy4gUkZDNjM4MyB3YXMgb24gb3B0aW1pemF0aW9u cyBhbmQgcmVjZW50bHkNCiB0aGUgTVBMUyBXRyBoYXMganVzdCBjb21wbGV0ZWQgZHJhZnQtaWV0 Zi1tcGxzLXNlbGYtcGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHlvdSBzdGlsbCBhcmUgdW5jb21mb3J0YWJs ZSB3aXRoIHRoZXNlIHJlcXVpcmVtZW50cywgaXQgd291bGQgYmUgYmVzdCBpZiB5b3UgZXhwcmVz cyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIFRFQVMgV0cuIEkgbm90ZWQgeW91IGRpZCBub3QgaW5j bHVkZSB0aGVtIG9uDQogeW91ciByZXZpZXcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbiB5b3VyIHNlY29uZCBjb25j ZXJuLCB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zLiBUaGlzIGlzIGFuIGluZm9ybWF0aW9uYWwg ZG9jdW1lbnQuIEFzIHRoZSBzaGVwaGVyZCB3cml0ZXVwIG5vdGVzIOKAnFRoZSByZXF1aXJlbWVu dHMgcHV0IGZvcnRoIGluIHRoaXMgZG9jdW1lbnQNCiBtYXkgYmUgdGhlIGJhc2lzIGZvciBmdXR1 cmUgZG9jdW1lbnRzLCBzb21lIG9mIHdoaWNoIG1heSBiZSBzaW1wbHkgaW5mb3JtYXRpb25hbCwg d2hpbGUgb3RoZXJzIG1heSBkZXNjcmliZSBzcGVjaWZpYyBHTVBMUyBwcm90b2NvbCBleHRlbnNp b25zLiBXaGlsZSBzb21lIG9mIHRoZXNlIHJlcXVpcmVtZW50cyBtYXkgYmUgaGF2ZSBpbXBsaWNh dGlvbnMgb24gaW1wbGVtZW50YXRpb25zLCB0aGUgaW50ZW50PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPmlzIGZvciB0aGUgcmVxdWlyZW1lbnRzIHRvIGFwcGx5IHRvIEdNUExTIHByb3Rv Y29scyBhbmQgdGhlaXIgc3RhbmRhcmRpemVkIG1lY2hhbmlzbXMu4oCdPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBp dCBpcyB1bmNsZWFyIGF0IHRoaXMgdGltZSBpZiBvbmx5IGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVt ZW50IGlzIG5lZWRlZCAoaW5mb3JtYXRpb25hbCBvbiB0aGUg4oCcY29ycmVjdOKAnSB1c2Ugb2Yg R01QTFMgcHJvdG9jb2xzL21lY2hhbmlzbXMgYW5kIGFuIHVuZGVyc3RhbmRpbmcNCiBvZiB0aGUg c2lnbmFsaW5nIGFzcGVjdHMgdnMuIHRoZSBwcm9jZXNzaW5nL2ltcGxlbWVudGF0aW9uIGRlcGVu ZGVudCBhc3BlY3RzKSBvciBpZiBuZXcgZXh0ZW5zaW9ucy9tZWNoYW5pc21zIGFyZSBuZWVkZWQu IEZvciB0aGUgc2VjdXJpdHkgc2VjdGlvbiwgaXQgd2FzIHdyaXR0ZW4gYmFzZWQgb24gdGhlIGFz c3VtcHRpb24gdGhhdCBlaXRoZXIgdGhpcyB3aWxsIG9ubHkgbmVlZCBhbiBhcHBsaWNhYmlsaXR5 IGRvY3VtZW50IGFuZCwgaWYgaXQNCiBuZWVkcyBtb3JlLCB0aGFuIG9uZSBoYXMgc29tZXRoaW5n IHRvIGJhc2UgYSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4gV2l0aCB0aGlzIGJhY2tncm91bmQs IGRvIHlvdSBoYXZlIHN1Z2dlc3Rpb25zIHRvIGhlbHAgdGhlIGF1dGhvcnMgaW1wcm92ZSB0aGlz IHNlY3Rpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BZ2FpbiwgdGhhbmtzIGZvciB5b3VyIHJldmlldy08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVib3JhaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFu ZHJldyBHLiBNYWxpcyBbbWFpbHRvOmFnbWFsaXNAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgU2VwdGVtYmVyIDIxLCAyMDE1IDEyOjI5IFBNPGJyPg0KPGI+VG86PC9iPiBT YW0gSGFydG1hbjxicj4NCjxiPkNjOjwvYj4gc2VjZGlyQGlldGYub3JnOyBzZWMtYWRzQGlldGYu b3JnOyBJRVNHOyBkcmFmdC1pZXRmLXRlYXMtZmFzdC1sc3BzLXJlcXVpcmVtZW50cy5hbGxAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFNlY2RpciBSZXZpZXcgb2YgZHJhZnQtaWV0 Zi10ZWFzLWZhc3QtbHNwcy1yZXF1aXJlbWVudHMtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5TYW0sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFdlICh0aGUgYXV0aG9ycykgd2lsbCBh d2FpdCBmdXJ0aGVyIHJldmlldyBmcm9tIHRoZSBJRVNHIGJlZm9yZSB0YWtpbmcgYW55IHBhcnRp Y3VsYXIgYWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBTZXAgMjEsIDIwMTUgYXQgMTE6NTUgQU0sIFNhbSBI YXJ0bWFuICZsdDs8YSBocmVmPSJtYWlsdG86aGFydG1hbnMtaWV0ZkBtaXQuZWR1IiB0YXJnZXQ9 Il9ibGFuayI+aGFydG1hbnMtaWV0ZkBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpIaS48YnI+DQpJIGFtIHRoZSBhc3NpZ25l ZCBzZWNkaXIgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQgb24gcmVxdWlyZW1lbnRzIGZvcjxicj4N CnZlcnkgZmFzdCBHTVBMUyBwYXRoIGVzdGFibGlzaG1lbnQuPGJyPg0KPGJyPg0KVGhpcyBkcmFm dCBvdXRsaW5lcyBzY2FsaW5nIHJlcXVpcmVtZW50cyBmb3IgbmV3IGFwcGxpY2F0aW9ucyBvZiBH TVBMUy48YnI+DQo8YnI+DQpJJ2QgbGlrZSB0byBmbGFnIHRoaXMgZHJhZnQgZm9yIHBhcnRpY3Vs YXIgcmV2aWV3IGZyb20gdGhlIHNlY3VyaXR5IEFEczxicj4NCmFuZCByZWNvbW1lbmQgdGhhdCB0 aGUgSUVTRyBjb25zaWRlciBhIHByb2Nlc3MgcXVlc3Rpb24gYW5kIGdldCBpbnB1dDxicj4NCmZy b20gdGhlIHNwb25zb3JpbmcgQUQuPGJyPg0KPGJyPg0KU28sIGZvciB0aGUgc2VjdXJpdHkgQURT Ojxicj4NClRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHJlYWRzIGluIGl0cyBl bnRpcmV0eTo8YnI+DQo8YnI+DQouJm5ic3A7IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwO0JlaW5nIGFibGUgdG8gc3VwcG9ydCB2ZXJ5IGZhc3Qgc2V0dXAg YW5kIGEgaGlnaCBjaHVybiByYXRlIG9mIEdNUExTPGJyPg0KJm5ic3A7ICZuYnNwO0xTUHMgaXMg bm90IGV4cGVjdGVkIHRvIGFkdmVyc2VseSBhZmZlY3QgdGhlIHVuZGVybHlpbmcgc2VjdXJpdHk8 YnI+DQombmJzcDsgJm5ic3A7aXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBleGlzdGluZyBHTVBMUyBz aWduYWxpbmcuPGJyPg0KPGJyPg0KPGJyPg0KaG93ZXZlciB0aGUgZHJhZnQgdGFsa3MgYWJvdXQg aW5jcmVhc2luZyB0aGUgbnVtYmVyIG9mIGNhc2VzIHdoZXJlIEdNUExTPGJyPg0KcGF0aHMgY3Jv c3MgYWRtaW5pc3RyYXRpdmUgYm91bmRhcmllcyBhbmQgc2lnbmlmaWNhbnRseSBpbmNyZWFzaW5n IHRoZTxicj4NCnNjYWxlIG9mIEdNUExTIGFwcGxpY2F0aW9ucy48YnI+DQo8YnI+DQpJIGRvbid0 IHRoaW5rIHdlIGhhdmUgZ29vZCBzZWN1cml0eSBzb2x1dGlvbnMgZm9yIGNhc2VzIHdoZXJlIHdl J3JlPGJyPg0KdHJ5aW5nIHRvIGRvIFBDRS1saWtlIHRoaW5ncyBhY3Jvc3MgbXV0dWFsbHkgc3Vz cGljaW91cyBvciBwb3RlbnRpYWxseTxicj4NCmhvc3RpbGUgYWRtaW5pc3RyYXRpdmUgYm91bmRh cmllcy48YnI+DQpBbmQgeWVzIGl0J3MgcmVhc29uYWJsZSB0byBhc3N1bWUgdGhhdCB0aGVyZSBh cmUgYnVzaW5lc3MgcmVsYXRpb25zaGlwczxicj4NCmluIHBsYWNlIGhlcmUsIGJ1dCB3ZSBhbHNv IHVuZGVyc3RhbmQgZnJvbSBvdXIgZXhwZXJpZW5jZSB3aXRoIEJHUCBhbmQ8YnI+DQpvdGhlciBp bnRlcm5ldC1zY2FsZSBzZXJ2aWNlcyB0aGUgbGltaXRhdGlvbnMgb2YgdGhhdC48YnI+DQo8YnI+ DQpJIHRoaW5rIHNpZ25pZmljYW50bHkgbW9yZSBzZWN1cml0eSB3b3JrIGlzIGNvbnNpZGVyLjxi cj4NCjxicj4NCk9uIGEgZ2VuZXJhbCBsZXZlbCwgdGhlcmUncyBiYXNpY2FsbHkgbm8ganVzdGlm aWNhdGlvbiBmb3IgdGhlPGJyPg0KcmVxdWlyZW1lbnRzIGdpdmVuLjxicj4NCkZvciBleGFtcGxl LCB0aGUgZG9jdW1lbnQgdGFsa3MgYWJvdXQgaG93IGNsb3VkIGNvbXB1dGluZyBpcyBhbjxicj4N CmFwcGxpY2F0aW9uIHRoYXQgd2lsbCBkcml2ZSB0aGVzZSByZXF1aXJlbWVudHMuJm5ic3A7IFRo ZSBkb2N1bWVudCBuZWl0aGVyPGJyPg0KdGFsa3MgYWJvdXQgbm9yIGNpdGVzIGFueSBleHBsYW5h dGlvbiBvZiZuYnNwOyB3aGF0IGl0IGlzIGFib3V0IGNsb3VkPGJyPg0KY29tcHV0aW5nIHRoYXQg Y3JlYXRlcyB0aGF0IG5lZWQgbm9yIGdpdmVzIHRoZSByZWFkZXIgYW55IGFiaWxpdHkgdG88YnI+ DQpldmFsdWF0ZSB3aGV0aGVyIHRoZSBuZWVkIGlzIHJlYWwuPGJyPg0KVGhlIGRlcHRoIG9mIGFu YWx5c2lzIGlzIHNpbWlsYXIgZm9yIGFsbCB0aGUgb3RoZXIgY2l0ZWQgYXBwbGljYXRpb25zLjxi cj4NCldlIGp1bXAgZnJvbSB2ZXJ5IGJyb2FkIHN0YW1lbnRzIGxpa2UgJnF1b3Q7Y2xvdWQgY29t cHV0aW5nLCBkYXRhY2VudGVycyBhbmQ8YnI+DQpkYXRhIHZpc3VhbGl6YXRpb24gd2lsbCBuZWVk IHRoaXMsJnF1b3Q7IHRvIHNwZWNpZmljIHJlcXVpcmVtZW50cyBpbiB0ZXJtcyBvZjxicj4NCnJl cXVlc3RzIHBlciBzZWNvbmQuPGJyPg0KPGJyPg0KSSdkIHBhcnRpY3VsYXJseSBsaWtlIHRvIGNh bGwgb3V0IHNlY3Rpb24gMjo8YnI+DQombmJzcDsgJm5ic3A7IDIuJm5ic3A7IEJhY2tncm91bmQ8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgRGVmZW5zZSBBZHZhbmNl ZCBSZXNlYXJjaCBQcm9qZWN0cyBBZ2VuY3kgKERBUlBBKSBDb3JlIE9wdGljYWw8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE5ldHdvcmtzIChDT1JPTkVUKSBwcm9ncmFt IFtDaGl1XSwgaXMgYW4gZXhhbXBsZSB0YXJnZXQgZW52aXJvbm1lbnQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGF0IGluY2x1ZGVzIElQIGFu ZCBvcHRpY2FsIGNvbW1lcmNpYWwgYW5kIGdvdmVybm1lbnQgbmV0d29ya3MsIHdpdGg8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGEg Zm9jdXMgb24gaGlnaGx5IGR5bmFtaWMgYW5kIHJlc2lsaWVudCBtdWx0aS10ZXJhYml0IGNvcmUg bmV0d29ya3MuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SXQgYW50aWNpcGF0ZXMgdGhlIG5lZWQgZm9yIHJh cGlkIChzdWItc2Vjb25kKSBzZXR1cCBhbmQgU09ORVQvU0RILTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgbGlrZSByZXN0b3JhdGlvbiB0aW1lcyBmb3IgaGlnaC1jaHVybiAodXAgdG8gdGVucyBv ZiByZXF1ZXN0cyBwZXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZWNv bmQgbmV0d29yay13aWRlIGFuZCBob2xkaW5nIHRpbWVzIGFzIHNob3J0IGFzIG9uZSBzZWNvbmQp IG9uLTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVtYW5k IHdhdmVsZW5ndGgsIHN1Yi13YXZlbGVuZ3RoIGFuZCBwYWNrZXQgc2VydmljZXMgZm9yIGEgdmFy aWV0eTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO29mIGFwcGxpY2F0aW9ucyAoZS5nLiwgZ3JpZCBjb21wdXRpbmcsIGNsb3VkIGNvbXB1 dGluZywgZGF0YTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdmlzdWFsaXphdGlvbiwgZmFzdCBkYXRhIHRyYW5zZmVyLCBl dGMuKS4mbmJzcDsgVGhpcyBtdXN0IGJlIGRvbmUgd2hpbGU8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDttZWV0aW5nIHN0cmluZ2VudCBjYWxsIGJsb2NraW5nIHJlcXVpcmVtZW50cywgYW5kIHdoaWxl IG1pbmltaXppbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSB1c2Ugb2YgcmVz b3VyY2VzIHN1Y2ggYXMgdGltZSBzbG90cywgc3dpdGNoIHBvcnRzLCB3YXZlbGVuZ3RoPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29udmVyc2lvbiwgZXRjLjxi cj4NCjxicj4NCkkgcmVjb21tZW5kIHRoYXQgc29tZW9uZSB0YWtlIGEgbG9vayBhdCB0aGUgbWF0 ZXJpYWwgb24gdGhhdCBEQVJQQTxicj4NCnByb2plY3QgYW5kIHNlZSBob3cgd2VsbCB0aGUgREFS UEEgcmVxdWlyZW1lbnRzIGFsaWduIHdpdGggdGhlPGJyPg0KcmVjb21tZW5kYXRpb25zIGluIHRo aXMgc3BlYy48YnI+DQpJJ20gc29tZXdoYXQgY29uY2VybmVkIHRoYXQgREFSUEEgcHV0IHRvZ2V0 aGVyIGEgcmVzZWFyY2ggcHJvamVjdCBhbmQ8YnI+DQpzYWlkICZxdW90O0hleSB3ZSdkIGxpa2Ug dGhlc2UgdGhpbmdzLCZxdW90OyBhbmQgbm93IHRoZSBJRVRGLCB3aXRob3V0IGFueTxicj4NCnNp Z25pZmljYW50IGluZGVwZW5kZW50IGFuYWx5c2lzIGlzIHJ1YmJlciBzdGFtcGluZyB0aGF0IGFz IG91cjxicj4NCnJlcXVpcmVtZW50cyBpbiB0aGlzIHNwYWNlLjxicj4NCjxicj4NCkkgZG9uJ3Qg a25vdyB0aGF0J3Mgd2hhdCBoYXBwZW5lZCBoZXJlLCB0aHVzIEkgaGF2ZSBub3QgY29waWVkPGJy Pg0KPGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+Ljxicj4N Ckhvd2V2ZXIsIERBUlBBJ3MgcmVxdWVzdCBzaG91bGQgbm90IHJlcHJlc2VudCBhbiBpbmZvcm1l ZCBjb25zZW5zdXMgb2Y8YnI+DQp0aGUgSUVURi48YnI+DQpJJ2QgbGlrZSB0byBzZWUgdGhlIElF U0cgZXZhbHVhdGUgd2hldGhlciB3ZSBhY3R1YWxseSBoYXZlIGRvbmUgb3VyIG93bjxicj4NCmFu YWx5c2lzIGhlcmUgYW5kIHdoZXRoZXIgdGhlcmUgaXMgYW4gaW5mb3JtZWQgY29uc2Vuc3VzJm5i c3A7IGJlaGluZCB0aGlzPGJyPg0KZG9jdW1lbnQuPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB5b3Vy IGNvbnNpZGVyYXRpb24sPGJyPg0KPGJyPg0KLS1TYW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F64C10EAA68C8044B33656FA214632C85272FBC1MISOUT7MSGUSRDE_-- From nobody Mon Sep 21 16:05:57 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A061ACE94; Mon, 21 Sep 2015 16:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 dEulNzry9cZ7; Mon, 21 Sep 2015 16:05:54 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id B92351ACED5; Mon, 21 Sep 2015 16:05:47 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 4FC85F24143; Mon, 21 Sep 2015 19:05:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id chWIlniXOiTB; Mon, 21 Sep 2015 19:04:20 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 40599F2412F; Mon, 21 Sep 2015 19:05:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-347-713037693 From: Russ Housley In-Reply-To: Date: Mon, 21 Sep 2015 19:05:05 -0400 Message-Id: <1EBBE254-6774-41F9-BD35-E1120B67FCC4@vigilsec.com> References: To: Warren Kumari X-Mailer: Apple Mail (2.1085) Archived-At: Cc: "draft-housley-sow-author-statistics.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-housley-sow-author-statistics-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 23:05:56 -0000 --Apple-Mail-347-713037693 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Warren: As it says in the document, Jari has promised to include the appropriate = redirects. Russ On Sep 21, 2015, at 1:58 PM, Warren Kumari wrote: > I had not seen this draft until now, but I wanted to quickly insert = myself into the conversation to thank Jari again for having provided = these tools for so long.=20 > I have found them to be incredibly helpful - it's about the only way = I know what drafts I have active, and what I need to do next... >=20 > It will be great to have this in the datatracker if Jari cannot = continue to run it on Arkko.net >=20 >=20 > W > On Monday, September 21, 2015, Brian Weis (bew) 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. >=20 > This draft outlines requirements for a statement of work to provide = statistics about RFCs, Internet-Drafts, and their authors. There are no = particular security considerations to the statement of work. There are = also no privacy considerations that I can see, insomuch that the results = will formalize the existing tools that gather statistics, and the = statistics are gathered from previously published documents. >=20 > I consider this draft to be Ready to publish. >=20 > Brian > _______________________________________________ > 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 > --=20 > I don't think the execution is relevant when it was obviously a bad = idea in the first place. > This is like putting rabid weasels in your pants, and later expressing = regret at having chosen those particular rabid weasels and that pair of = pants. > ---maf --Apple-Mail-347-713037693 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I had not = seen this draft until now, but I wanted to quickly insert myself into = the conversation to thank Jari again for having provided these tools for = so long. 
I have found  them to be incredibly helpful - = it's about the only way I know what drafts I have active, and what I = need to do next...

It will be great to have = this in the datatracker if Jari cannot continue to run it on Arkko.net


W
On = Monday, September 21, 2015, Brian Weis (bew) <bew@cisco.com> = 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.

This draft outlines requirements for a statement of work to provide = statistics about RFCs, Internet-Drafts, and their authors. There are no = particular security considerations to the statement of work. There are = also no privacy considerations that I can see, insomuch that the results = will formalize the existing tools that gather statistics, and the = statistics are gathered from previously published documents.

I consider this draft to be Ready to publish.

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


--
I don't think the execution is = relevant when it was obviously a bad idea in the first place.
This is = like putting rabid weasels in your pants, and later expressing regret at = having chosen those particular rabid weasels and that pair of = pants.
   ---maf

= --Apple-Mail-347-713037693-- From nobody Mon Sep 21 17:34:55 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1E31ACDE5 for ; Mon, 21 Sep 2015 17:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 RUF0ZmwRrmuM for ; Mon, 21 Sep 2015 17:34:51 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id DD57D1ACDC3 for ; Mon, 21 Sep 2015 17:34:50 -0700 (PDT) Received: (qmail 7463 invoked by uid 0); 22 Sep 2015 00:34:49 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 22 Sep 2015 00:34:49 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id L0ai1r00U2SSUrH010alu0; Mon, 21 Sep 2015 18:34:47 -0600 X-Authority-Analysis: v=2.1 cv=C6F6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=0RAR5D2yBdQrwp53PsoA:9 a=bCDC00nOpVNyUGZ6:21 a=BcFdZkG3eSuyAsUL:21 a=QEXdDO2ut3YA:10 a=XIqpo32RAAAA:8 a=WwByOlHt4hu4xHjUyu4A:9 a=D5SfZVLvXdNvwCW6:21 a=zMY0fasZuyrZ7ieZ:21 a=SpSLK2-eWlx-8gb-:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=EetcH9YsOCJOq+a9icPv48lgXRYpYGlUj6PBfHqWkXk=; b=jnRHjZc05EY8lpG2+WjpAHSoytN3JlB28pfENRSCtSDx+K7nDValVm0wo5phwNPwwTB63g6oeNSNyMhRxLC8wkVkltl2yppnPPl/vflPPG6y2b8ke4zrUJPHEK9ALxaU; Received: from box313.bluehost.com ([69.89.31.113]:33356 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZeBXf-0008Nt-FN; Mon, 21 Sep 2015 18:34:44 -0600 To: "BRUNGARD, DEBORAH A" , "Andrew G. Malis" , Sam Hartman References: From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <5600A20E.9060607@labn.net> Date: Mon, 21 Sep 2015 20:34:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070209020303010003080806" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "sec-ads@ietf.org" , "draft-ietf-teas-fast-lsps-requirements.all@ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir Review of draft-ietf-teas-fast-lsps-requirements-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 00:34:54 -0000 This is a multi-part message in MIME format. --------------070209020303010003080806 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sam, To add to Deborah's point re requirements. A lot of time was spent discussing the requirements to ensure they were phrased in terms that were generally applicable. Since these were published we have seen a number of documents and other new work which are all focused on scaling and some of the other related requirements. If your concern is that the requirements represent just one organization's viewpoint that have been rubber stamped, rest assured that this was/is not the case. Lou PS Disclaimer: I contributed to getting this document revised from it's original form to what you see now. On 9/21/2015 5:09 PM, BRUNGARD, DEBORAH A wrote: > > Hi Sam, > > > > Thanks for your review. > > > > I see basically two concerns, one questioning the security aspects, > the other on the general level questioning the document itself. > > > > As the general level concern is much more serious, let’s address it > first. Maybe some background would help. I was chair of CCAMP and then > TEAS when the document transitioned to TEAS. At first the document was > written in the style of being quite negative on GMPLS as the > identified problems were based on incorrect interpretation of the RFCs > (broken implementations). So the WG asked the authors to first be > precise on their requirements before assuming new solutions were > needed. After several spins, the WG was comfortable with the > requirements. Folks didn’t question the requirements themselves as > GMPLS is targeted at applications for improving connection set up > times for large mesh networks vs. using a PCE/management system. And > when asked, the authors said this was not targeted for wavelengths > (where the physical connectivity is more constraining than the control > plane signaling) but OTN (Optical Transport Network is a digital > frame) e.g. from March 2014 CCAMP Meeting Notes: > > “Lou Berger: [poll] how many have read the document [] how many think > this is an interesting problem to discuss? [a good number for each] > > George Swallow: What is achievable for OTN is much closer to your > requirements than what is achievable for optical. I was wondering if > requirements apply to both. > > Andy Malis: They apply to both, we have possible solutions for both > but before coming with solutions we want an agreement on requirements. > > Rajan Rao: If we have separate data plane and control plane > requirements, if the traffic doesn’t come out, what does it really mean? > > Lou Berger: question for the list. > > Adrian Farrel: I like this set of requirements, I hate you say you > can't solve them with existing stuff. Push requirements and then we > can work on an applicability to see if existing solutions can meet them.” > > > > The Shepherd writeup provides more detail. And this is not the first > document discussing optimizing set up times. RFC6383 was on > optimizations and recently the MPLS WG has just completed > draft-ietf-mpls-self-ping. > > > > If you still are uncomfortable with these requirements, it would be > best if you express your concerns with the TEAS WG. I noted you did > not include them on your review. > > > > On your second concern, the security implications. This is an > informational document. As the shepherd writeup notes “The > requirements put forth in this document may be the basis for future > documents, some of which may be simply informational, while others may > describe specific GMPLS protocol extensions. While some of these > requirements may be have implications on implementations, the intent > > is for the requirements to apply to GMPLS protocols and their > standardized mechanisms.” > > > > So it is unclear at this time if only an applicability statement is > needed (informational on the “correct” use of GMPLS > protocols/mechanisms and an understanding of the signaling aspects vs. > the processing/implementation dependent aspects) or if new > extensions/mechanisms are needed. For the security section, it was > written based on the assumption that either this will only need an > applicability document and, if it needs more, than one has something > to base a security considerations. With this background, do you have > suggestions to help the authors improve this section? > > > > Again, thanks for your review- > > Deborah > > > > > > *From:*Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Monday, September 21, 2015 12:29 PM > *To:* Sam Hartman > *Cc:* secdir@ietf.org; sec-ads@ietf.org; IESG; > draft-ietf-teas-fast-lsps-requirements.all@ietf.org > *Subject:* Re: Secdir Review of draft-ietf-teas-fast-lsps-requirements-01 > > > > Sam, > > > > Thanks for your comments. We (the authors) will await further review > from the IESG before taking any particular action. > > > > Cheers, > > Andy > > > > > > On Mon, Sep 21, 2015 at 11:55 AM, Sam Hartman > wrote: > > > Hi. > I am the assigned secdir reviewer for this draft on requirements for > very fast GMPLS path establishment. > > This draft outlines scaling requirements for new applications of GMPLS. > > I'd like to flag this draft for particular review from the security ADs > and recommend that the IESG consider a process question and get input > from the sponsoring AD. > > So, for the security ADS: > The security considerations section reads in its entirety: > > . Security Considerations > > Being able to support very fast setup and a high churn rate of GMPLS > LSPs is not expected to adversely affect the underlying security > issues associated with existing GMPLS signaling. > > > however the draft talks about increasing the number of cases where GMPLS > paths cross administrative boundaries and significantly increasing the > scale of GMPLS applications. > > I don't think we have good security solutions for cases where we're > trying to do PCE-like things across mutually suspicious or potentially > hostile administrative boundaries. > And yes it's reasonable to assume that there are business relationships > in place here, but we also understand from our experience with BGP and > other internet-scale services the limitations of that. > > I think significantly more security work is consider. > > On a general level, there's basically no justification for the > requirements given. > For example, the document talks about how cloud computing is an > application that will drive these requirements. The document neither > talks about nor cites any explanation of what it is about cloud > computing that creates that need nor gives the reader any ability to > evaluate whether the need is real. > The depth of analysis is similar for all the other cited applications. > We jump from very broad staments like "cloud computing, datacenters and > data visualization will need this," to specific requirements in terms of > requests per second. > > I'd particularly like to call out section 2: > 2. Background > > The Defense Advanced Research Projects Agency (DARPA) Core Optical > Networks (CORONET) program [Chiu], is an example target > environment > that includes IP and optical commercial and government > networks, with > a focus on highly dynamic and resilient multi-terabit > core networks. > It anticipates the need for rapid (sub-second) > setup and SONET/SDH- > like restoration times for high-churn (up to > tens of requests per > second network-wide and holding times as > short as one second) on- > demand wavelength, sub-wavelength and > packet services for a variety > of applications (e.g., grid computing, > cloud computing, data > visualization, fast data transfer, > etc.). This must be done while > meeting stringent call blocking > requirements, and while minimizing > the use of resources such as > time slots, switch ports, wavelength > conversion, etc. > > I recommend that someone take a look at the material on that DARPA > project and see how well the DARPA requirements align with the > recommendations in this spec. > I'm somewhat concerned that DARPA put together a research project and > said "Hey we'd like these things," and now the IETF, without any > significant independent analysis is rubber stamping that as our > requirements in this space. > > I don't know that's what happened here, thus I have not copied > ietf@ietf.org . > However, DARPA's request should not represent an informed consensus of > the IETF. > I'd like to see the IESG evaluate whether we actually have done our own > analysis here and whether there is an informed consensus behind this > document. > > Thanks for your consideration, > > --Sam > > > --------------070209020303010003080806 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Sam,
    To add to Deborah's point re requirements. A lot of time was spent discussing the requirements to ensure they were phrased in terms that were generally applicable.  Since these were published we have seen a number of documents and other new work which are all focused on scaling and some of the other related requirements.  If your concern is that the requirements represent just one organization's viewpoint that have been rubber stamped, rest assured that this was/is not the case.

Lou

PS Disclaimer: I contributed to getting this document revised from it's original form to what you see now.

On 9/21/2015 5:09 PM, BRUNGARD, DEBORAH A wrote:

Hi Sam,

 

Thanks for your review.

 

I see basically two concerns, one questioning the security aspects, the other on the general level questioning the document itself.

 

As the general level concern is much more serious, let’s address it first. Maybe some background would help. I was chair of CCAMP and then TEAS when the document transitioned to TEAS. At first the document was written in the style of being quite negative on GMPLS as the identified problems were based on incorrect interpretation of the RFCs (broken implementations). So the WG asked the authors to first be precise on their requirements before assuming new solutions were needed. After several spins, the WG was comfortable with the requirements. Folks didn’t question the requirements themselves as GMPLS is targeted at applications for improving connection set up times for large mesh networks vs. using a PCE/management system. And when asked, the authors said this was not targeted for wavelengths (where the physical connectivity is more constraining than the control plane signaling) but OTN (Optical Transport Network is a digital frame) e.g. from March 2014 CCAMP Meeting Notes:

“Lou Berger: [poll] how many have read the document [] how many think this is an interesting problem to discuss? [a good number for each]

George Swallow: What is achievable for OTN is much closer to your requirements than what is achievable for optical. I was wondering if requirements apply to both.

Andy Malis: They apply to both, we have possible solutions for both but before coming with solutions we want an agreement on requirements.

Rajan Rao: If we have separate data plane and control plane requirements, if the traffic doesn’t come out, what does it really mean?

Lou Berger: question for the list.

Adrian Farrel: I like this set of requirements, I hate you say you can't solve them with existing stuff. Push requirements and then we can work on an applicability to see if existing solutions can meet them.”

 

The Shepherd writeup provides more detail. And this is not the first document discussing optimizing set up times. RFC6383 was on optimizations and recently the MPLS WG has just completed draft-ietf-mpls-self-ping.

 

If you still are uncomfortable with these requirements, it would be best if you express your concerns with the TEAS WG. I noted you did not include them on your review.

 

On your second concern, the security implications. This is an informational document. As the shepherd writeup notes “The requirements put forth in this document may be the basis for future documents, some of which may be simply informational, while others may describe specific GMPLS protocol extensions. While some of these requirements may be have implications on implementations, the intent

is for the requirements to apply to GMPLS protocols and their standardized mechanisms.”

 

So it is unclear at this time if only an applicability statement is needed (informational on the “correct” use of GMPLS protocols/mechanisms and an understanding of the signaling aspects vs. the processing/implementation dependent aspects) or if new extensions/mechanisms are needed. For the security section, it was written based on the assumption that either this will only need an applicability document and, if it needs more, than one has something to base a security considerations. With this background, do you have suggestions to help the authors improve this section?

 

Again, thanks for your review-

Deborah

 

 

From: Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: Monday, September 21, 2015 12:29 PM
To: Sam Hartman
Cc: secdir@ietf.org; sec-ads@ietf.org; IESG; draft-ietf-teas-fast-lsps-requirements.all@ietf.org
Subject: Re: Secdir Review of draft-ietf-teas-fast-lsps-requirements-01

 

Sam,

 

Thanks for your comments. We (the authors) will await further review from the IESG before taking any particular action.

 

Cheers,

Andy

 

 

On Mon, Sep 21, 2015 at 11:55 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote:


Hi.
I am the assigned secdir reviewer for this draft on requirements for
very fast GMPLS path establishment.

This draft outlines scaling requirements for new applications of GMPLS.

I'd like to flag this draft for particular review from the security ADs
and recommend that the IESG consider a process question and get input
from the sponsoring AD.

So, for the security ADS:
The security considerations section reads in its entirety:

.  Security Considerations

   Being able to support very fast setup and a high churn rate of GMPLS
   LSPs is not expected to adversely affect the underlying security
   issues associated with existing GMPLS signaling.


however the draft talks about increasing the number of cases where GMPLS
paths cross administrative boundaries and significantly increasing the
scale of GMPLS applications.

I don't think we have good security solutions for cases where we're
trying to do PCE-like things across mutually suspicious or potentially
hostile administrative boundaries.
And yes it's reasonable to assume that there are business relationships
in place here, but we also understand from our experience with BGP and
other internet-scale services the limitations of that.

I think significantly more security work is consider.

On a general level, there's basically no justification for the
requirements given.
For example, the document talks about how cloud computing is an
application that will drive these requirements.  The document neither
talks about nor cites any explanation of  what it is about cloud
computing that creates that need nor gives the reader any ability to
evaluate whether the need is real.
The depth of analysis is similar for all the other cited applications.
We jump from very broad staments like "cloud computing, datacenters and
data visualization will need this," to specific requirements in terms of
requests per second.

I'd particularly like to call out section 2:
    2.  Background

       The Defense Advanced Research Projects Agency (DARPA) Core Optical
          Networks (CORONET) program [Chiu], is an example target environment
             that includes IP and optical commercial and government networks, with
                a focus on highly dynamic and resilient multi-terabit core networks.
                   It anticipates the need for rapid (sub-second) setup and SONET/SDH-
                      like restoration times for high-churn (up to tens of requests per
                         second network-wide and holding times as short as one second) on-
                            demand wavelength, sub-wavelength and packet services for a variety
                               of applications (e.g., grid computing, cloud computing, data
                                  visualization, fast data transfer, etc.).  This must be done while
                                     meeting stringent call blocking requirements, and while minimizing
                                        the use of resources such as time slots, switch ports, wavelength
                                           conversion, etc.

I recommend that someone take a look at the material on that DARPA
project and see how well the DARPA requirements align with the
recommendations in this spec.
I'm somewhat concerned that DARPA put together a research project and
said "Hey we'd like these things," and now the IETF, without any
significant independent analysis is rubber stamping that as our
requirements in this space.

I don't know that's what happened here, thus I have not copied
ietf@ietf.org.
However, DARPA's request should not represent an informed consensus of
the IETF.
I'd like to see the IESG evaluate whether we actually have done our own
analysis here and whether there is an informed consensus  behind this
document.

Thanks for your consideration,

--Sam

 


--------------070209020303010003080806-- From nobody Wed Sep 23 01:11:22 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6691A9023 for ; Wed, 23 Sep 2015 01:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CGVqbXmWqCUW for ; Wed, 23 Sep 2015 01:11:18 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 CD6B81A9006 for ; Wed, 23 Sep 2015 01:11:18 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8N8BHeD025507 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Sep 2015 08:11:18 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t8N8BH3c009119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Sep 2015 08:11:17 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8N8BHSw005064; Wed, 23 Sep 2015 08:11:17 GMT Received: from [10.159.120.65] (/10.159.120.65) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Sep 2015 01:11:16 -0700 Message-ID: <56025EEB.5060602@oracle.com> Date: Wed, 23 Sep 2015 02:12:27 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: secdir@ietf.org References: <559A155B.6080505@oracle.com> In-Reply-To: <559A155B.6080505@oracle.com> X-Forwarded-Message-Id: <559A155B.6080505@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: draft-ietf-pwe3-iccp-stp.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-pwe3-iccp-stp-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 08:11:20 -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. This draft specifies a Spanning Tree Protocol (STP) application for the Inter-Chassis Communication Protocol (ICCP). The security considerations section does exist and refers to the base ICCP specification, RFC 7275, for applicability. 7275 lists the security constraints and limitations sufficiently when considering the reviewed draft. The section goes on to describe potential DoS attacks as described in 7275 and provides a single example to mitigate such an attack. Even though this coverage is fairly sparse, 7275 outlines a more comprehensive list of thwarting potential threats. General comments: None. Editorial comments: PE, PW, AC, CE, and LDP are never expanded. s/need be active/need to be active/ s/such system/such systems/ s/that support ICCP/that supports ICCP/ s/on CE or PE/on the CE or PE/ s/attack on channel/attack on a channel/ s/careful attack on channel/a careful attack on a channel/ Shawn. -- From nobody Wed Sep 23 01:30:38 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6414B1A9097 for ; Wed, 23 Sep 2015 01:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nCn9Fj_pVszK for ; Wed, 23 Sep 2015 01:30:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854361A9094 for ; Wed, 23 Sep 2015 01:30:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXY22949; Wed, 23 Sep 2015 08:30:29 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Sep 2015 09:30:28 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Wed, 23 Sep 2015 16:30:21 +0800 From: Mingui Zhang To: Shawn M Emery , "secdir@ietf.org" Thread-Topic: Review of draft-ietf-pwe3-iccp-stp-04 Thread-Index: AQHQ9deIDMAYKNPE50evs3I3IKG70J5Jx9Sw Date: Wed, 23 Sep 2015 08:30:20 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E787206621@nkgeml512-mbx.china.huawei.com> References: <559A155B.6080505@oracle.com> <56025EEB.5060602@oracle.com> In-Reply-To: <56025EEB.5060602@oracle.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-pwe3-iccp-stp.all@tools.ietf.org" Subject: Re: [secdir] Review of draft-ietf-pwe3-iccp-stp-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 08:30:36 -0000 Hi Shawn, Thanks for the review! The comments will be incorporated in the new version= . Thanks, Mingui=20 > -----Original Message----- > From: Shawn M Emery [mailto:shawn.emery@oracle.com] > Sent: Wednesday, September 23, 2015 4:12 PM > To: secdir@ietf.org > Cc: draft-ietf-pwe3-iccp-stp.all@tools.ietf.org > Subject: Review of draft-ietf-pwe3-iccp-stp-04 >=20 > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security are= a > directors. Document editors and WG chairs should treat these comments jus= t > like any other last call comments. >=20 > This draft specifies a Spanning Tree Protocol (STP) application for the > Inter-Chassis Communication Protocol (ICCP). >=20 > The security considerations section does exist and refers to the base ICC= P > specification, RFC 7275, for applicability. 7275 lists the security cons= traints > and limitations sufficiently when considering the reviewed draft. > The section goes on to describe potential DoS attacks as described in 727= 5 and > provides a single example to mitigate such an attack. Even though this > coverage is fairly sparse, 7275 outlines a more comprehensive list of thw= arting > potential threats. >=20 > General comments: >=20 > None. >=20 > Editorial comments: >=20 > PE, PW, AC, CE, and LDP are never expanded. >=20 > s/need be active/need to be active/ >=20 > s/such system/such systems/ >=20 > s/that support ICCP/that supports ICCP/ >=20 > s/on CE or PE/on the CE or PE/ >=20 > s/attack on channel/attack on a channel/ >=20 > s/careful attack on channel/a careful attack on a channel/ >=20 > Shawn. > -- From nobody Wed Sep 23 10:49:40 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C439F1A88FD; Wed, 23 Sep 2015 10:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=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 v3EwaLTpmRfC; Wed, 23 Sep 2015 10:49:35 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C071E1A88FC; Wed, 23 Sep 2015 10:49:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 00EC1E2035; Wed, 23 Sep 2015 13:49:34 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 10447-10; Wed, 23 Sep 2015 13:49:31 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 6C2C6E2034; Wed, 23 Sep 2015 13:49:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1443030571; bh=8N7EGMEIr/zJZQP3OZ1SodyEgerSOrQd/aCnV+nILk0=; h=From:To:Cc:Subject:Date; b=sOOOmCEKvuN3U1uE4vSUlxfE/MogVlpDdfZ0+O2182I/AgIkLFQde7OTtLWN7BF3w PMfGeNfHWonnTdJZ9ri3TW4pwKc8t0zOKAmaOSutBzvS3Apc8eArdWT7NoFbu2x67M L8pOG/hDVpLDo0uMJvTJ7KTYgHclpVKdHGoEm76Q= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t8NHnUAK010047; Wed, 23 Sep 2015 13:49:30 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Wed, 23 Sep 2015 13:49:30 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: pwouters@redhat.com, ipsecme-chairs@ietf.org Subject: [secdir] sec-dir review of draft-kivinen-ipsecme-oob-pubkey-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 17:49:36 -0000 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 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. Summary: Ready to publish Details: I have no issues with this document as written. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Sep 24 03:45:40 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3941A0371; Thu, 24 Sep 2015 03:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.064 X-Spam-Level: X-Spam-Status: No, score=-96.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=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 fjbfW0f04t5w; Thu, 24 Sep 2015 03:45:36 -0700 (PDT) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF991A0379; Thu, 24 Sep 2015 03:45:35 -0700 (PDT) Received: from [192.168.43.211] (ip-109-40-100-106.web.vodafone.de [109.40.100.106]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 6E4FD63ABC; Thu, 24 Sep 2015 12:45:31 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=kjk1JtO8Ao9EvQFARkO9RXKeZm2IywW+NhNMhqMMY4mO1RHCaJwghZLYhhGPqTxDHrFnKjO527sakS78oEC3FK20H5Q0ebojMfRrkx5BB42/Z1hwcrk7abdajbYmxA9YYzVB6IQsjhFgBxwAiUp19+T08ePVzqrkkYGfqnZWwlk=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type; Message-ID: <5603D448.3060701@gondrom.org> Date: Thu, 24 Sep 2015 03:45:28 -0700 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-v6ops-siit-dc.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------040602090704080503050005" Archived-At: Cc: tore@redpill-linpro.com Subject: [secdir] secdir review of draft-ietf-v6ops-siit-dc-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 10:45:38 -0000 This is a multi-part message in MIME format. --------------040602090704080503050005 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 draft aims for informational status and describes a deployment model for traffic from legacy IPv4-only clients (on the Internet) is translated to IPv6 upon reaching the data centre. The document appears mostly ok for publication with a series of comments. One main question: Technically this document looks to me more like standards and not informational as I think we need to enforce consistent behaviour and restrictions to ensure overall consistency. IMO we need to spell this out more explicitly. This is a repeating element, I encountered in this review across multiple sections of the document (see explanations below). COMMENTS: 0. starting with a personal comment:in general it is nice to move again a step closer to a V6, even though these series of baby transition steps are quite small. Whether we need this in addition to other existing 64 protocols, I leave to the V6ops WG who has much better insight into this one than me. 1. This document has two strong requirements, that should be expressed in 2119 language. 1.1. the SIIT algorithm MUST be used. 1.2. And the security considerations section MUST be followed. 2. Section 7 Security Considerations: 2.1. The listed concern is correct. The listed mitigation step may work, I would suggest to also add a sentence when you do choose this distinct translation prefix, you also must configure your FW/GW at the edge to enforce the integrity of that naming scheme (e.g. by dropping packets from that prefix if not coming from a IPv4) to make sure there is no ambiguity or spoofing. We must avoid a blend of translated and untranslated addresses in the same prefix if you use the prefix as a marker. 2.2. I am not sure you covered all the security concerns in this section. 2.2.1. e.g. we might want to expand more on the risk that the DC does by design not see that we translate this down to V4 at the edge and thereby loose some of the capabilities of V6 beyond the edge. Therefore the DC may assume a fully V6 conformant client, which is not the case. This may lead to the need of further filtering or protection mechanisms at the edge. 2.2.2. the authors should expand more on architecture requirements not to put two of these translators in sequence (see possibly conflicts with 2.2.3. the authors should expand more on restrictions of putting this in a mixed environment with NAT64 3. section "4.4. Choice of Translation Prefix" - states: "Either a Network-Specific Prefix (NSP) from the provider's own IPv6 address space or the IANA-allocated Well-Known Prefix 64:ff9b::/96 (WKP) may be used." I think this needs to be a MUST instead of the "may". Also I do not like the ambiguity of prefixes here. We need to make it clear that this translastion MUST be consistent across all edges to the DC. 4. section 4.5. routing considerations: - do we need to specify that all alternate BRs must use the same algorithm and all MUST be able to support SIIT-DC? 5. section 4.6: we say "This should be understood to include all servers," I am not sure this is only a "should". From a lingual perspective it might be meaning that it "it should be understood that it requires..." but as the word "required" is not used, it is a bit unclear to me, whether that is also understood by the author/WG for this protocol. 6. section 4.8.: we use "To facilitate reliable delivery of such ICMPv6 errors n SIIT-DC operator SHOULD implement the recommendations in [RFC6791] in the BRs." Is there a security consideration on the impact what happens if RFC6791 is not followed and ICMPv6 errors are dropped? What would be the security implications of loosing not transmitting these messages? 7. section 4.9. "MTU and Fragmentation": it is good that we spell out the series of key differences between IPv4 and IPv6 relating to packet sizes and fragmentation that one needs to consider when deploying SIIT-DC. I am not sure a "should" is sufficient here. Furthermore, it would be good to consider whether we need to specify and mandate the specific behaviour when encountering these limitations to avoid inconsistent behaviour from the BR if these parameters are encountered and this might be exploited as an attack vector. Thank you and best regards. Tobias --------------040602090704080503050005 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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 draft aims for informational status and describes a deployment model for traffic from legacy IPv4-only clients (on the Internet) is translated to IPv6 upon reaching the data centre.

The document appears mostly ok for publication with a series of comments.
One main question:
Technically this document looks to me more like standards and not informational as I think we need to enforce consistent behaviour and restrictions to ensure overall consistency. IMO we need to spell this out more explicitly. This is a repeating element, I encountered in this review across multiple sections of the document (see explanations below).

COMMENTS:
0.
starting with a personal comment:in general it is nice to move again a step closer to a V6, even though these series of baby transition steps are quite small. Whether we need this in addition to other existing 64 protocols, I leave to the V6ops WG who has much better insight into this one than me.

1. This document has two strong requirements, that should be expressed in 2119 language.
1.1. the SIIT algorithm MUST be used.
1.2. And the security considerations section MUST be followed.

2. Section 7 Security Considerations:
2.1. The listed concern is correct. The listed mitigation step may work, I would suggest to also add a sentence when you do choose this distinct translation prefix, you also must configure your FW/GW at the edge to enforce the integrity of that naming scheme (e.g. by dropping packets from that prefix if not coming from a IPv4) to make sure there is no ambiguity or spoofing. We must avoid a blend of translated and untranslated addresses in the same prefix if you use the prefix as a marker.
2.2. I am not sure you covered all the security concerns in this section. 
2.2.1. e.g. we might want to expand more on the risk that the DC does by design not see that we translate this down to V4 at the edge and thereby loose some of the capabilities of V6 beyond the edge. Therefore the DC may assume a fully V6 conformant client, which is not the case. This may lead to the need of further filtering or protection mechanisms at the edge.
2.2.2. the authors should expand more on architecture requirements not to put two of these translators in sequence (see possibly conflicts with 2.2.3. the authors should expand more on restrictions of putting this in a mixed environment with NAT64

3. section "4.4. Choice of Translation Prefix"
- states: "Either a Network-Specific Prefix (NSP) from the provider's own IPv6 address space or the IANA-allocated Well-Known Prefix 64:ff9b::/96  (WKP) may be used."
I think this needs to be a MUST instead of the "may". Also I do not like the ambiguity of prefixes here. We need to make it clear that this translastion MUST be consistent across all edges to the DC.

4. section 4.5. routing considerations:
- do we need to specify that all alternate BRs must use the same algorithm and all MUST be able to support SIIT-DC?

5. section 4.6:
we say "This should be understood to include all servers,"
I am not sure this is only a "should". From a lingual perspective it might be meaning that it "it should be understood that it requires..." but as the word "required" is not used, it is a bit unclear to me, whether that is also understood by the author/WG for this protocol.

6. section 4.8.:
we use "To facilitate reliable delivery of such ICMPv6 errors n SIIT-DC operator SHOULD implement the recommendations in [RFC6791] in the BRs." Is there a security consideration on the impact what happens if RFC6791 is not followed and ICMPv6 errors are dropped? What would be the security implications of loosing not transmitting these messages?

7. section 4.9. "MTU and Fragmentation":
it is good that we spell out the series of key differences between IPv4 and IPv6 relating to packet sizes and fragmentation that one needs to consider when deploying SIIT-DC. I am not sure a "should" is sufficient here. Furthermore, it would be good to consider whether we need to specify and mandate the specific behaviour when encountering these limitations to avoid inconsistent behaviour from the BR if these parameters are encountered and this might be exploited as an attack vector.

Thank you and best regards.

Tobias

--------------040602090704080503050005-- From nobody Thu Sep 24 06:12:30 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB611ACED9 for ; Thu, 24 Sep 2015 06:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 wOj9mCmjHo0b for ; Thu, 24 Sep 2015 06:12:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 EF5681ACEDC for ; Thu, 24 Sep 2015 06:12:27 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t8ODCPXa026798 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 24 Sep 2015 16:12:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t8ODCPAQ001042; Thu, 24 Sep 2015 16:12:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22019.63161.744165.150321@fireball.acr.fi> Date: Thu, 24 Sep 2015 16:12:25 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 13:12:29 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Scott Kelly is next in the rotation. For telechat 2015-10-01 Reviewer LC end Draft John Bradley T 2015-09-03 draft-ietf-mpls-lsp-ping-reply-mode-simple-04 Daniel Kahn Gillmor T 2015-09-17 draft-ietf-tzdist-caldav-timezone-ref-04 Dan Harkins T 2015-09-24 draft-ietf-bess-spbm-evpn-01 Christian Huitema T 2015-09-30 draft-ietf-teas-te-express-path-03 Chris Inacio T 2015-07-29 draft-ietf-homenet-dncp-10 Sean Turner TR2015-09-25 draft-ietf-mpls-lsp-ping-relay-reply-10 Tom Yu T 2015-09-08 draft-ietf-dhc-dhcpv4-active-leasequery-06 Dacheng Zhang T 2015-09-04 draft-ietf-dice-profile-16 For telechat 2015-10-15 Steve Hanna T 2015-10-09 draft-blanchet-ccsds-urn-00 Benjamin Kaduk T 2015-10-13 draft-ietf-ospf-node-admin-tag-04 Charlie Kaufman T 2015-10-05 draft-ietf-trill-cmt-08 Last calls and special requests: Donald Eastlake 2015-09-11 draft-ietf-dane-openpgpkey-05 Daniel Kahn Gillmor E None draft-ietf-rtcweb-security-08 Tobias Gondrom E None draft-ietf-rtcweb-security-arch-11 Olafur Gudmundsson 2015-09-22 draft-ietf-v6ops-siit-dc-2xlat-01 Phillip Hallam-Baker 2015-09-22 draft-ietf-v6ops-siit-eam-01 Paul Hoffman 2015-09-24 draft-ietf-teas-rsvp-te-srlg-collect-02 Jeffrey Hutzelman 2015-09-30 draft-ietf-v6ops-pmtud-ecmp-problem-04 Chris Inacio 2015-10-02 draft-ietf-lwig-ikev2-minimal-03 Leif Johansson 2015-10-02 draft-ietf-mpls-self-ping-04 Simon Josefsson 2015-10-07 draft-ietf-netconf-call-home-11 -- kivinen@iki.fi From nobody Thu Sep 24 17:24:53 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F141B42CC for ; Thu, 24 Sep 2015 17:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 cq86hLUzyi_Q for ; Thu, 24 Sep 2015 17:24:50 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::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 BB63E1B33DE for ; Thu, 24 Sep 2015 17:24:49 -0700 (PDT) Received: by lacdq2 with SMTP id dq2so26470868lac.1 for ; Thu, 24 Sep 2015 17:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=O+BxD70blJm/tW95h/TMSaAwktxSoeqL5vtVnsIssIE=; b=rIGTOyCJFUbpK51wferIkd6AOnYjFY9q0cHbhEGvEA6KsPljHthtfz/bRF4Iin1Ivn hxEY3qrv8LwdfyWAbpaxNK9iImNxl2fVOo0DdtsG1PmXE32WfMoBi1KINzLoRqmd9wsm XIwSdeoYF3oLTSAX/U0QnSd2VJAfjcsEyKZk/WfHTxhjHzqME6o+wL0VX+KoGXKgdOPX FUDiPiLnTQZFcWr/9xk9RqY+qAQpV5xNoh0tT0BM5eJbmF4QMsf2RNeyCw5xwdL9KQZr /RUVeIyF50+d0Zn7fl+KtHvZZTL0gtgGcsHWRbs60IZYgL1uivdWv252VJifmd6+Ogho N9/A== MIME-Version: 1.0 X-Received: by 10.112.168.194 with SMTP id zy2mr730808lbb.79.1443140687943; Thu, 24 Sep 2015 17:24:47 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.2.163 with HTTP; Thu, 24 Sep 2015 17:24:47 -0700 (PDT) Date: Thu, 24 Sep 2015 20:24:47 -0400 X-Google-Sender-Auth: pHGcZN2WFLRoLjmrTc30DMDTr_M Message-ID: From: Phillip Hallam-Baker To: "secdir@ietf.org" Content-Type: multipart/alternative; boundary=001a11c333f210e0a205208760a0 Archived-At: Subject: [secdir] Security Review of draft-ietf-v6ops-siit-eam-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 00:24:52 -0000 --001a11c333f210e0a205208760a0 Content-Type: text/plain; charset=UTF-8 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 draft is essentially describing an extension to the IPv4/6 mapping mechanism to allow a mixture of mappings determined by fixed function and mappings determined by an address table. 7 . Security Considerations The EAM algorithm does not introduce any new security issues beyond those that are already discussed in Section 7 of [RFC6145] . Which points to. 7 . Security Considerations The use of stateless IP/ICMP translators does not introduce any new security issues beyond the security issues that are already present in the IPv4 and IPv6 protocols and in the routing protocols that are used to make the packets reach the translator. Both statements are incorrect. If we were to write out a modern Internet architecture we would no doubt decide that addresses have no significance above the transport layer and should not be visible to applications. But that isn't the Internet architecture we have today. Further most Internet services make use of IP addresses for various types of abuse mitigation. This is something that these mapping functions will have a significant impact on. Adding an address table capability provides even more potential to play various types of application layer routing games. This needs a comprehensive analysis. --001a11c333f210e0a205208760a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have = reviewed this document as part of the security directorate's ongoing ef= fort to review all IETF documents being processed by the IESG.=C2=A0 These = comments were written primarily for the benefit of the security area direct= ors.=C2=A0 Document editors and WG chairs should treat these comments just = like any other last call comments.

The draft is essentially describing an extension to= the IPv4/6 mapping mechanism to allow a mixture of mappings determined by = fixed function and mappings determined by an address table.

=

7. Security Considerations

The EAM algorithm does not introduce any new security issues beyond those that are already discussed in Section=C2=A07 of [RFC6145].

Which points to.

7= . Security Considerations

The use of stateless IP/ICMP translators does not introduce any new security issues beyond the security issues that are already present in the IPv4 and IPv6 protocols and in the routing protocols that are used to make the packets reach the translator.

Both statements are=
 incorrect.
If we were to=
 write out a modern Internet architecture we would no doubt decide that add=
resses have no significance above the transport layer and should not be vis=
ible to applications. But that isn't the Internet architecture we have =
today.

Further most Inter=
net services  make use of IP addresses for various types of abuse mitigatio=
n. This is something that these mapping functions will have a significant i=
mpact on.

<= /font>
Adding an addre=
ss table capability provides even more potential to play various types of a=
pplication layer routing games.


Thi=
s needs a comprehensive analysis.
--001a11c333f210e0a205208760a0-- From nobody Sun Sep 27 15:36:46 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA301B2FE3 for ; Sun, 27 Sep 2015 15:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553] autolearn=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 eE3zZ41-rrI9 for ; Sun, 27 Sep 2015 15:36:44 -0700 (PDT) Received: from hoffman.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 485031B2FE2 for ; Sun, 27 Sep 2015 15:36:44 -0700 (PDT) Received: from [10.32.60.60] (142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8RMage1065170 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 Sep 2015 15:36:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123] claimed to be [10.32.60.60] From: "Paul Hoffman" To: secdir Date: Sun, 27 Sep 2015 15:36:42 -0700 Message-ID: <7BA110B0-7550-45EB-BA79-192551043742@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: [secdir] Secdir review of draft-ietf-teas-rsvp-te-srlg-collect X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 22:36:45 -0000 Greetings. This draft defines a new extension for RSVP-TE for collecting additional information. I could not see any security issues with the collection process or the proposed uses. The Security Considerations section is short, mostly hand-waving "you should be careful when doing this", but I couldn't think of anything better to say about any perceived threats. --Paul Hoffman From nobody Sun Sep 27 17:03:14 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396D81A1BCF for ; Sun, 27 Sep 2015 17:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 wiczf54iEica for ; Sun, 27 Sep 2015 17:03:12 -0700 (PDT) Received: from smtp90.iad3a.emailsrvr.com (smtp90.iad3a.emailsrvr.com [173.203.187.90]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A141A1BCA for ; Sun, 27 Sep 2015 17:03:12 -0700 (PDT) Received: from smtp20.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp20.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0548F18024B; Sun, 27 Sep 2015 20:03:11 -0400 (EDT) Received: by smtp20.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 5B8BA180237; Sun, 27 Sep 2015 20:03:10 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [192.168.0.11] (c-98-210-197-105.hsd1.ca.comcast.net [98.210.197.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Mon, 28 Sep 2015 00:03:11 GMT From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_34AEB11C-E102-4143-8938-5F083E4B1A23" Date: Sun, 27 Sep 2015 20:03:08 -0400 Message-Id: To: draft-ietf-v6ops-siit-dc-2xlat@ietf.org, vg6ops@ietf.org, The IESG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: secdir@ietf.org Subject: [secdir] sec-dir review of draft-ietf-v6ops-siit-dc-2xlat X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 00:03:13 -0000 --Apple-Mail=_34AEB11C-E102-4143-8938-5F083E4B1A23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have read the draft and it is well written.=20 I was not able to see any security issues with this draft that are not = covered in the security considerations or in the security considerations = of its accompanying draft ietf-v6ops-siit-dc Olafur --Apple-Mail=_34AEB11C-E102-4143-8938-5F083E4B1A23 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

I have read the draft and it is well written. 
I was not able to see any security issues with this draft that are not covered in the security considerations or in the security considerations of its accompanying draft ietf-v6ops-siit-dc

Olafur

--Apple-Mail=_34AEB11C-E102-4143-8938-5F083E4B1A23-- From nobody Mon Sep 28 07:18:21 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BFC1A9245 for ; Mon, 28 Sep 2015 07:18:19 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 MHMz4PSDkDo3 for ; Mon, 28 Sep 2015 07:18:18 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::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 33AAC1A9231 for ; Mon, 28 Sep 2015 07:18:18 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so103787974wic.1 for ; Mon, 28 Sep 2015 07:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TnS1tsuZ4O0PWe+OzWndLx3RsK5ehSMQGBybT1twedY=; b=Qxc7BHitJ+dULPqr+kQLCyzSe9RYw5lBWIlOgyrDVzzLTIYtNOyMk8Y93lmp5qVoZK gUF5STLgEF+NolMNugwL2zGTjewBSEOD+xVDPheQr2Jrl6jscK0x5nSx9+fkBtHHqj2N 63g44MmqBre+IZjREFV7yFf8MKmOW0xtRq83U3xRmqnIwbxntIzE0QS9r+O4/vmnxr0S 2peEFnb7oh4OBGNvv55hGnpP+KKnsPQ2mTwiQwy2DAcmAJ40PN9lYvhABy4R50J61UT0 +K2ru7KR0iiWOa2WjZyE29bARy51XT91UZvcfmVijL7yaUnEf61fdBzi11iYKNbVyno0 X5ZA== MIME-Version: 1.0 X-Received: by 10.180.75.38 with SMTP id z6mr17890099wiv.36.1443449896756; Mon, 28 Sep 2015 07:18:16 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Mon, 28 Sep 2015 07:18:16 -0700 (PDT) Date: Mon, 28 Sep 2015 10:18:16 -0400 Message-ID: From: Kathleen Moriarty To: "secdir@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Promoting a draft - tweet X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 14:18:19 -0000 Hi, If anyone else tweets, I think it would be good to raise awareness on this draft that is in IESG review this week: https://datatracker.ietf.org/doc/draft-ietf-dice-profile/ It is a very well-written draft that should go a long way in helping IoT/constrained device vendors integrate session encryption with DTLS/TLS. I tweeted already if you just want to retweet. @KathleeMoriarty -- Best regards, Kathleen From nobody Mon Sep 28 21:57:42 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1AE1A03AA for ; Mon, 28 Sep 2015 21:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 gr1iRobg1G1T for ; Mon, 28 Sep 2015 21:57:37 -0700 (PDT) Received: from xsmtp12.mail2web.com (xsmtp12.mail2web.com [168.144.250.177]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B851A03A5 for ; Mon, 28 Sep 2015 21:57:37 -0700 (PDT) Received: from internal.xmail02.myhosting.com ([10.5.2.12] helo=xmail02.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1Zgmys-0006Yo-8I for secdir@ietf.org; Tue, 29 Sep 2015 00:57:36 -0400 Received: (qmail 18569 invoked from network); 29 Sep 2015 04:57:32 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Sep 2015 04:57:32 -0000 From: "Christian Huitema" To: , "'secdir'" , Date: Mon, 28 Sep 2015 21:57:36 -0700 Message-ID: <00c301d0fa73$5d0053f0$1700fbd0$@huitema.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C4_01D0FA38.B0A17BF0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdD6cUGBKeVv7UUNSbGaXvmeokPjrg== Content-Language: en-us Archived-At: Subject: [secdir] Secdir review of draft-ietf-teas-te-express-path-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 04:57:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C4_01D0FA38.B0A17BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. =20 This document is ready for publication as an informational RFC. =20 Draft-ietf-teas-te-express-path provides considerations on the use of performance criteria such as delay, loss and jitter when performing path selection when using routing protocols IS-IS or OSPF. The document = warns developers against using poor criteria and causing oscillation. It = provides guidance on the handling of paths whose measured criteria have changed. =20 The security section states that =93This document is not currently = believed to introduce new security concerns.=94 Well, I currently believe that the = authors may be correct about that. The only potential attack that I can think of would involve subtle manipulations of the criteria measurements in order = to induce path oscillations. Such attack scenario does not feel very = realistic or very serious. In any case that would not be a =93new=94 attack due to = this specific draft, but rather an existing attack on IS-IS or OSPF. =20 -- Christian Huitema =20 =20 =20 =20 ------=_NextPart_000_00C4_01D0FA38.B0A17BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the = security directorate's

ongoing effort to review all IETF documents = being processed by the

IESG.=A0 These comments were written = primarily for the benefit of the

security area directors.=A0 Document editors = and WG chairs should treat

these comments just like any other last call = comments.

 

This document is ready for publication as an = informational RFC.

 

Draft-ietf-teas-te-express-path provides = considerations on the use of performance criteria such as delay, loss = and jitter when performing path selection when using routing protocols = IS-IS or OSPF. The document =A0warns developers against using poor = criteria and causing oscillation. It provides guidance on the handling = of paths whose measured criteria have = changed.

 

The security section states that “This = document is not currently believed to introduce new security = concerns.” Well, I currently believe that the authors may be = correct about that. The only potential attack that I can think of would = involve subtle manipulations of the criteria measurements in order to = induce path oscillations. Such attack scenario does not feel very = realistic or very serious. In any case that would not be a = “new” attack due to this specific draft, but rather an = existing attack on IS-IS or OSPF.

 

-- Christian = Huitema

 

 

 

 

------=_NextPart_000_00C4_01D0FA38.B0A17BF0-- From nobody Tue Sep 29 19:44:21 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1513C1B5A00; Tue, 29 Sep 2015 19:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1okQHwf-ri3N; Tue, 29 Sep 2015 19:44:16 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCEE1B2D4C; Tue, 29 Sep 2015 19:44:16 -0700 (PDT) X-AuditID: 12074423-f793f6d000007fc1-2e-560b4c7e815e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 22.48.32705.E7C4B065; Tue, 29 Sep 2015 22:44:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t8U2iENh012081; Tue, 29 Sep 2015 22:44:14 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t8U2iCGZ024382; Tue, 29 Sep 2015 22:44:13 -0400 From: Tom Yu To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dhc-dhcpv4-active-leasequery.all@tools.ietf.org Date: Tue, 29 Sep 2015 22:44:12 -0400 Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixG6nolvnwx1mMPepiUXPriXMFjP+TGS2 +LDwIYsDs8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlbF/Tz97wU72imd/DrE1MLawdTFy ckgImEi0LP/DBGGLSVy4tx4ozsUhJLCYSWLB2X0sIAkhgY2MEt+asiESbxglOt/vYgVJsAlI Sxy/vAusW0QgXeLy9u2MXYwcHMICLhLbNxmBhFkEVCX+TvoGVs4roCvxYdIFdhCbR4BTomfD L6i4oMTJmU/AdjELaEnc+PeSaQIj7ywkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbp munlZpbopaaUbmIEB5SL8g7GPweVDjEKcDAq8fC+EOAOE2JNLCuuzD3EKMnBpCTKe80LKMSX lJ9SmZFYnBFfVJqTWnyIUYKDWUmE96kFUI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZq akFqEUxWhoNDSYI33RuoUbAoNT21Ii0zpwQhzcTBCTKcB2i4O0gNb3FBYm5xZjpE/hSjLseC H7fXMgmx5OXnpUqJ80aDFAmAFGWU5sHNAScCIcZ9rxjFgd4S5p0PUsUDTCJwk14BLWECWjJX lwtkSUkiQkqqgXHCxX1vp9mznXsW5+awsPLR3H/T54ef1G/6X+F+W+eA26Iwtk+mCS+Ljl1p 4dTbaql85OHOo9sCTN9UvQqat6f/vbcHx8fXM/Wl5wQVCzc/OBozz/6LRxN31Y4qD4YV/rf+ sXULH+2//n/jkgDRnM8qE4xFdh46+okzTOaerMKZ+TJ16Vm3GMKVWIozEg21mIuKEwH9xotg 3wIAAA== Archived-At: Subject: [secdir] secdir review of draft-ietf-dhc-dhcpv4-active-leasequery-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 02:44:18 -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. Summary: ready with nits The Security Considerations of the draft seem reasonably complete. There could be a minor traffic analysis risk in some environments due to the real-time nature of Active Leasequery -- if the connection between an authorized requester and the DHCP server traverses network paths monitored by an adversary, the adversary could learn about the timing of DHCP events, and might be able distinguish among different types of events by the relative sizes of the messages. This could be true even if TLS is in use. I suspect that the risk is minimal in typical deployments. -Tom