From nobody Thu Sep 1 01:58:52 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2C212D879 for ; Thu, 1 Sep 2016 01:58:49 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhIhPP1eszSc for ; Thu, 1 Sep 2016 01:58:47 -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 305F312D895 for ; Thu, 1 Sep 2016 01:58:47 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u818wfG7011935 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 1 Sep 2016 11:58:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u818wfkQ016375; Thu, 1 Sep 2016 11:58:41 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22471.60865.932244.150965@fireball.acr.fi> Date: Thu, 1 Sep 2016 11:58:41 +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.17 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, 01 Sep 2016 08:58:49 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Charlie Kaufman is next in the rotation. For telechat 2016-09-01 Reviewer LC end Draft Eric Osterweil T 2016-08-26 draft-ietf-httpauth-extension-08 For telechat 2016-09-15 Shaun Cooley T 2016-08-25 draft-ietf-hip-rfc5206-bis-12 Steve Hanna T 2016-09-06 draft-ietf-pals-mc-pon-04 Christian Huitema T 2016-09-06 draft-ietf-pce-pcep-service-aware-12 Leif Johansson T 2016-09-13 draft-ietf-mptcp-experience-06 For telechat 2016-09-29 Olafur Gudmundsson T 2016-08-25 draft-ietf-softwire-unified-cpe-05 Dan Harkins T 2016-09-21 draft-ietf-pals-rfc4447bis-05 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Phillip Hallam-Baker 2016-09-07 draft-ietf-core-etch-02 Paul Hoffman 2016-09-09 draft-ietf-taps-transports-11 Simon Josefsson 2016-09-22 draft-harkins-salted-eap-pwd-06 Benjamin Kaduk 2016-09-08 draft-ietf-tsvwg-diffserv-intercon-09 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-11 Sandy Murphy 2016-08-12 draft-ietf-tsvwg-gre-in-udp-encap-13 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-14 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-05 Tina TSOU 2016-08-15 draft-ietf-ospf-two-part-metric-09 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-09 Paul Wouters 2016-09-02 draft-moriarty-pkcs1-01 Dacheng Zhang 2016-08-22 draft-ietf-core-http-mapping-13 -- kivinen@iki.fi From nobody Thu Sep 1 04:57:16 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E0312D924; Thu, 1 Sep 2016 04:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.468 X-Spam-Level: X-Spam-Status: No, score=-7.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrofdj92XbrU; Thu, 1 Sep 2016 04:57:09 -0700 (PDT) Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F69812D911; Thu, 1 Sep 2016 04:57:07 -0700 (PDT) X-SBRS: None Received: from unknown (HELO mucxv003.muc.infineon.com) ([172.23.11.20]) by smtp2.infineon.com with ESMTP/TLS/AES256-SHA; 01 Sep 2016 13:57:05 +0200 Received: from MUCSE607.infineon.com (unknown [172.23.7.108]) by mucxv003.muc.infineon.com (Postfix) with ESMTPS; Thu, 1 Sep 2016 13:57:05 +0200 (CEST) Received: from MUCSE613.infineon.com (172.23.7.84) by MUCSE607.infineon.com (172.23.7.108) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 13:57:05 +0200 Received: from MUCSE609.infineon.com (172.23.7.110) by MUCSE613.infineon.com (172.23.7.84) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 13:57:04 +0200 Received: from MUCSE609.infineon.com ([172.23.103.71]) by MUCSE609.infineon.com ([172.23.103.71]) with mapi id 15.00.1178.000; Thu, 1 Sep 2016 13:57:04 +0200 From: To: , , Thread-Topic: secdir review of draft-ietf-pals-mc-pon-04 Thread-Index: AdIERGNJ4u3omnmWQ2+8lMLF4/56GQ== Date: Thu, 1 Sep 2016 11:57:04 +0000 Message-ID: <9ca53ebc0523442d9be8ab8a1bc3b45e@MUCSE609.infineon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.23.8.247] Content-Type: multipart/alternative; boundary="_000_9ca53ebc0523442d9be8ab8a1bc3b45eMUCSE609infineoncom_" MIME-Version: 1.0 Archived-At: Subject: [secdir] secdir review of draft-ietf-pals-mc-pon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 11:57:11 -0000 --_000_9ca53ebc0523442d9be8ab8a1bc3b45eMUCSE609infineoncom_ Content-Type: text/plain; charset="us-ascii" 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. Summary: Ready with issues The security considerations section of this document seems reasonable and c= orrect. However, I'm concerned that bringing ICCP into the PON has some sec= urity risks that have not been properly called out and mitigated. As the Se= curity Considerations section says: In many passive optical networks the optical paths between OLT and ONTs traverse publicly accessible facilities including public attachments (e.g. telephone poles) Note that I'm pretty sure that ONT should be ONU here and in several other = places in the Security Considerations. My concern is that section 4.2 says that "When a fault is detected on its w= orking PW (e.g., by VCCV BFD), a working OLT SHOULD turn off its associated= PON interface and then send an ICCP message with PON State TLV with local = PON Port State being set to notify the protection OLT of the PON fault." Si= nce the working PW has failed, the working OLT will presumably send this IC= CP message to the protection PW over the PON. That means that any other aut= horized or unauthorized party on the PON could also send such a message. I'= m not very familiar with ICCP but the Security Considerations section of RF= C 7275 seems to say that ICCP messages are frequently authenticated only by= looking at the source IP address, which is an exceedingly weak method of a= uthentication susceptible to easy forgery. Using MD5 (as permitted by RFC 7= 275) isn't much better. The impact of permitting attackers to easily forge = ICCP messages on the PON is not clear to me but it seems that the attacker = could at least prevent proper failover and maybe force failover or even for= ce failure. Of course, an attacker on the PON could also just jam the PON b= y setting their laser always on but ICCP attacks would be much trickier to = detect. I would suggest that TCP-AO be required at least for ICCP messages = sent or received on the PON. Two minor typos: 1) In section 3, "protect OLTs" should be "protection OLTs". 2) In the Security Considerations, "ONT" should be "ONU". At least, I = assume so. If not, ONT should be defined. Thanks for your consideration, Steve --_000_9ca53ebc0523442d9be8ab8a1bc3b45eMUCSE609infineoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

Summary: Ready with issues

 

The security considerations section of this docum= ent seems reasonable and correct. However, I’m concerned that bringin= g ICCP into the PON has some security risks that have not been properly cal= led out and mitigated. As the Security Considerations section says:

 

   In many passive optical networks the= optical paths between

   OLT and ONTs traverse publicly acces= sible facilities including

   public attachments (e.g. telephone p= oles)

 

Note that I’m pretty sure that ONT should b= e ONU here and in several other places in the Security Considerations.=

 

My concern is that section 4.2 says that “W= hen a fault is detected on its working PW (e.g., by VCCV BFD), a working OL= T SHOULD turn off its associated PON interface and then send an ICCP messag= e with PON State TLV with local PON Port State being set to notify the protection OLT of the PON fault.” Sinc= e the working PW has failed, the working OLT will presumably send this ICCP= message to the protection PW over the PON. That means that any other autho= rized or unauthorized party on the PON could also send such a message. I’m not very familiar with ICCP but = the Security Considerations section of RFC 7275 seems to say that ICCP mess= ages are frequently authenticated only by looking at the source IP address,= which is an exceedingly weak method of authentication susceptible to easy forgery. Using MD5 (as permitted by RFC= 7275) isn’t much better. The impact of permitting attackers to easil= y forge ICCP messages on the PON is not clear to me but it seems that the a= ttacker could at least prevent proper failover and maybe force failover or even force failure. Of course, an att= acker on the PON could also just jam the PON by setting their laser always = on but ICCP attacks would be much trickier to detect. I would suggest that = TCP-AO be required at least for ICCP messages sent or received on the PON.

 

Two minor typos:

 

1)      In section 3, “protect OLTs” should be = “protection OLTs”.

 

2)      In the Security Considerations, “ONT” s= hould be “ONU”. At least, I assume so. If not, ONT should be de= fined.

 

Thanks for your consideration,

 

Steve

 

--_000_9ca53ebc0523442d9be8ab8a1bc3b45eMUCSE609infineoncom_-- From nobody Thu Sep 1 05:16:18 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D37712D986; Thu, 1 Sep 2016 05:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeDVKr0BqwRR; Thu, 1 Sep 2016 05:16:08 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 8D76A12D942; Thu, 1 Sep 2016 05:15:19 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id l2so82219007qkf.3; Thu, 01 Sep 2016 05:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=w8/xsxhi2rLVr9rGRAJH1W+AAGaWC0ijHE5X2yCEwI0=; b=jVbjNYjILvKwgVF9LWpNfr0lJZeulJxBOiAM7F1MJD+ZH/hGkYl7nYInNiBstl8qip bACbXOCBI1Cfos9iYtuiuI7qWHLjl5Gigz7FaODAbeHPfWYOz3UiJcU4bi4XhBw+qfuQ jj6ig3m5RbW+i1hFGHLWAb58nBVogqXHEKg2Vm+Opvzw7WD0KLI722SYLFJb7v/Jg8I4 BUGxSbzd7I14Mf3sqoguYkyDef/GDfEiLXa4Pj2PHLwWRL+9OekBW+Yo2I4pSpR+tBE9 R2rE9/5yjcutnnXh0GU9KyrIEZoaULBC3hRUzXX3zvBJ5uDbhNmysQABNI+q7liuYiqn vQhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=w8/xsxhi2rLVr9rGRAJH1W+AAGaWC0ijHE5X2yCEwI0=; b=KeagxgXMUL1riQKpQXjxHxcjixkqQ3SiLcamDHsHqmM5MuWzMtwlDii5VabdrukKIs ZW5SHDFSBNnOQF0sDUixteEOADr/I7iZ2jufcSObMUIQRtMKlX3W2s+oAyBz/daSfHDX Iuz3bfJ9Ge23LnANuUaoH9qEIcarXEeZv6diIfG76Q6rnhyv9A3aC7bWvgsdvIw1PsbE P6JLqjSKHKEBQwciYrW1TSyAAdxoGHRNn9wIt9b354/pat7BoYXMS1qcqdfWazaVyLZn d4f3KpTm8ED6T0bk5QU87m1XSOWvUY1uy6wK9ajy6xKqCzAbPp51CtuYLqsHGRXbSO1/ 4sxQ== X-Gm-Message-State: AE9vXwOy0BsEvIqxcnhW4EXrr1zKCSJfRXnWM0vifQJS+2Zn55DAws44X9uJ1IofNMO4tlGgdLlmtDYREg2QcQ== X-Received: by 10.55.186.65 with SMTP id k62mr17222472qkf.204.1472732118456; Thu, 01 Sep 2016 05:15:18 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.158.211 with HTTP; Thu, 1 Sep 2016 05:15:17 -0700 (PDT) From: Phillip Hallam-Baker Date: Thu, 1 Sep 2016 08:15:17 -0400 X-Google-Sender-Auth: JP4c7Wvd5wb2l0Khd00XPKnOooU Message-ID: To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-core-etch-02.all@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0441cec52709053b712a23 Archived-At: Subject: [secdir] Secdir review of draft-ietf-core-etch-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 12:16:13 -0000 --94eb2c0441cec52709053b712a23 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. Summary: Ready with one minor issue The only problem I had was working out what the authors meant by idempotent because the term is unfortunately used to mean different things. So the fact it is being used correctly here doesn't necessarily help the reader. The term is explained in rfc7252 but doesn't have an entry in the terms and definitions section. Where it is explained (sec 5.4) the explanation is consistent with HTTP practice. But I think it would help a lot if besides saying that the effect of doing the operation repeatedly, it was stated that the effect is that message replay doesn't have effect. Since it isn't defined in rfc7252 terms and definitions, it needs an entry in this draft and there should probably be an errata on rfc7252 so that it can be fixed on the next rev. It would be useful to point that out in the security considerations section as well. --94eb2c0441cec52709053b712a23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

=C2=A0

Summary: Ready with one minor issue

T= he only problem I had was working out what the authors meant by idempotent = because the term is unfortunately used to mean different things. So the fac= t it is being used correctly here doesn't necessarily help the reader.<= /p>

The term is explained in=C2=A0rfc7252 but = doesn't have an entry in the terms and definitions section. Where it is= explained (sec 5.4) the explanation is consistent with HTTP practice. But = I think it would help a lot if besides saying that the effect of doing the = operation repeatedly, it was stated that the effect is that message replay = doesn't have effect.

Since it isn'= t defined in=C2=A0rfc7252 terms and definitions, it needs an entry in this = draft and there should probably be an errata on=C2=A0rfc7252 so that it can= be fixed on the next rev.

It would be use= ful to point that out in the security considerations section as well.

--94eb2c0441cec52709053b712a23-- From nobody Thu Sep 1 07:07:16 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD4A12D0C1; Thu, 1 Sep 2016 07:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.168 X-Spam-Level: X-Spam-Status: No, score=-3.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb3LXRwMAb4s; Thu, 1 Sep 2016 07:07:12 -0700 (PDT) Received: from smtp11.infineon.com (smtp11.infineon.com [217.10.52.105]) (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 9F26112D96B; Thu, 1 Sep 2016 06:54:55 -0700 (PDT) X-SBRS: None Received: from unknown (HELO mucxv001.muc.infineon.com) ([172.23.11.16]) by smtp11.infineon.com with ESMTP/TLS/AES256-GCM-SHA384; 01 Sep 2016 15:54:54 +0200 Received: from MUCSE607.infineon.com (unknown [172.23.7.108]) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Thu, 1 Sep 2016 15:54:53 +0200 (CEST) Received: from MUCSE614.infineon.com (172.23.7.85) by MUCSE607.infineon.com (172.23.7.108) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 15:54:53 +0200 Received: from MUCSE609.infineon.com (172.23.7.110) by MUCSE614.infineon.com (172.23.7.85) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 15:54:52 +0200 Received: from MUCSE609.infineon.com ([172.23.103.71]) by MUCSE609.infineon.com ([172.23.103.71]) with mapi id 15.00.1178.000; Thu, 1 Sep 2016 15:54:52 +0200 From: To: , , Thread-Topic: secdir review of draft-ietf-pals-mc-pon-04 Thread-Index: AdIERGNJ4u3omnmWQ2+8lMLF4/56GQAE89FQ Date: Thu, 1 Sep 2016 13:54:52 +0000 Message-ID: <71cbf9b3372247f297987d0bb1acdd67@MUCSE609.infineon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.23.8.247] Content-Type: multipart/alternative; boundary="_000_71cbf9b3372247f297987d0bb1acdd67MUCSE609infineoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-pals-mc-pon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 14:07:16 -0000 --_000_71cbf9b3372247f297987d0bb1acdd67MUCSE609infineoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resending with correct draft alias. Steve From: Hanna Steve (IFAM CCS SMD AMR) Sent: Thursday, September 01, 2016 7:57 AM To: 'iesg@ietf.org'; 'secdir@ietf.org'; 'draft-ietf-pals-mc-pon-04.all@ietf= .org' Subject: secdir review of draft-ietf-pals-mc-pon-04 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. Summary: Ready with issues The security considerations section of this document seems reasonable and c= orrect. However, I'm concerned that bringing ICCP into the PON has some sec= urity risks that have not been properly called out and mitigated. As the Se= curity Considerations section says: In many passive optical networks the optical paths between OLT and ONTs traverse publicly accessible facilities including public attachments (e.g. telephone poles) Note that I'm pretty sure that ONT should be ONU here and in several other = places in the Security Considerations. My concern is that section 4.2 says that "When a fault is detected on its w= orking PW (e.g., by VCCV BFD), a working OLT SHOULD turn off its associated= PON interface and then send an ICCP message with PON State TLV with local = PON Port State being set to notify the protection OLT of the PON fault." Si= nce the working PW has failed, the working OLT will presumably send this IC= CP message to the protection PW over the PON. That means that any other aut= horized or unauthorized party on the PON could also send such a message. I'= m not very familiar with ICCP but the Security Considerations section of RF= C 7275 seems to say that ICCP messages are frequently authenticated only by= looking at the source IP address, which is an exceedingly weak method of a= uthentication susceptible to easy forgery. Using MD5 (as permitted by RFC 7= 275) isn't much better. The impact of permitting attackers to easily forge = ICCP messages on the PON is not clear to me but it seems that the attacker = could at least prevent proper failover and maybe force failover or even for= ce failure. Of course, an attacker on the PON could also just jam the PON b= y setting their laser always on but ICCP attacks would be much trickier to = detect. I would suggest that TCP-AO be required at least for ICCP messages = sent or received on the PON. Two minor typos: 1) In section 3, "protect OLTs" should be "protection OLTs". 2) In the Security Considerations, "ONT" should be "ONU". At least, I = assume so. If not, ONT should be defined. Thanks for your consideration, Steve --_000_71cbf9b3372247f297987d0bb1acdd67MUCSE609infineoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Resending with correct= draft alias.

 

Steve

 

From: Hanna St= eve (IFAM CCS SMD AMR)
Sent: Thursday, September 01, 2016 7:57 AM
To: 'iesg@ietf.org'; 'secdir@ietf.org'; 'draft-ietf-pals-mc-pon-04.a= ll@ietf.org'
Subject: secdir review of draft-ietf-pals-mc-pon-04

 

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

 

Summary: Ready with issues

 

The security considerations section of this docum= ent seems reasonable and correct. However, I’m concerned that bringin= g ICCP into the PON has some security risks that have not been properly cal= led out and mitigated. As the Security Considerations section says:

 

   In many passive optical networks the= optical paths between

   OLT and ONTs traverse publicly acces= sible facilities including

   public attachments (e.g. telephone p= oles)

 

Note that I’m pretty sure that ONT should b= e ONU here and in several other places in the Security Considerations.=

 

My concern is that section 4.2 says that “W= hen a fault is detected on its working PW (e.g., by VCCV BFD), a working OL= T SHOULD turn off its associated PON interface and then send an ICCP messag= e with PON State TLV with local PON Port State being set to notify the protection OLT of the PON fault.” Sinc= e the working PW has failed, the working OLT will presumably send this ICCP= message to the protection PW over the PON. That means that any other autho= rized or unauthorized party on the PON could also send such a message. I’m not very familiar with ICCP but = the Security Considerations section of RFC 7275 seems to say that ICCP mess= ages are frequently authenticated only by looking at the source IP address,= which is an exceedingly weak method of authentication susceptible to easy forgery. Using MD5 (as permitted by RFC= 7275) isn’t much better. The impact of permitting attackers to easil= y forge ICCP messages on the PON is not clear to me but it seems that the a= ttacker could at least prevent proper failover and maybe force failover or even force failure. Of course, an att= acker on the PON could also just jam the PON by setting their laser always = on but ICCP attacks would be much trickier to detect. I would suggest that = TCP-AO be required at least for ICCP messages sent or received on the PON.

 

Two minor typos:

 

1)      In section 3, “protect OLTs” should be = “protection OLTs”.

 

2)      In the Security Considerations, “ONT” s= hould be “ONU”. At least, I assume so. If not, ONT should be de= fined.

 

Thanks for your consideration,

 

Steve

 

--_000_71cbf9b3372247f297987d0bb1acdd67MUCSE609infineoncom_-- From nobody Thu Sep 1 08:15:17 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B346112DA2C for ; Thu, 1 Sep 2016 08:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3W0RpWfVv7d1 for ; Thu, 1 Sep 2016 08:15:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A760312DA38 for ; Thu, 1 Sep 2016 08:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6800; q=dns/txt; s=iport; t=1472742908; x=1473952508; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=k4OLA8SSXPMNaj9IyURCVj9A+mt1E27NpZSt0GTYtPs=; b=bvIn75pQW0fKsUOeI9T/htWqggQcDwYvSmopbitni/O0RYDtlWRReFym q9pdHyLei6LHOr9PEry/wV3ECq48lfMcabOUYgQI6YdA37mbfFFiuU6AU 84/Y1SnSuFqQ5XgTR0LxTqSfjPfOBtkXPSrGPtkUOjYPxIB0dXgnvTw2B A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAgCXRchX/4QNJK1dg1ABAQEBAR6BU?= =?us-ascii?q?werbocohQ2CAoYcAhyBMzgUAQIBAQEBAQEBXieEYgEFI0gOEAIBCAQ7AwICAh8?= =?us-ascii?q?RFBECBA4FiC4DF64CiTkNgy8BAQEBAQEBAQEBAQEBAQEBAQEBAQEchi+BeIJVg?= =?us-ascii?q?kOEfyuCLwWUCYUTNAGMXYJTj1eIP4QJg3gBHjaEMXCFbX8BAQE?= X-IronPort-AV: E=Sophos;i="5.30,268,1470700800"; d="scan'208,217";a="142442824" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Sep 2016 15:15:07 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u81FF72G001145 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Sep 2016 15:15:07 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Sep 2016 11:15:06 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Thu, 1 Sep 2016 11:15:06 -0400 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" Thread-Topic: Review of draft-ietf-mpls-entropy-lsp-ping-04 Thread-Index: AQHSAjNlgOV36X1rzE2hxO8HBsuHYaBh0kEAgAMzowA= Date: Thu, 1 Sep 2016 15:15:06 +0000 Message-ID: References: <5770C231.9060301@oracle.com> <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.21.184] Content-Type: multipart/alternative; boundary="_000_D82BC29335C148C69AB38E71F22985E6ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mpls-entropy-lsp-ping.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-mpls-entropy-lsp-ping-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 15:15:15 -0000 --_000_D82BC29335C148C69AB38E71F22985E6ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBTaGF3biwNCg0KVGhhbmtzIGFnYWluIOKAlCBqdXN0IGNsb3NpbmcgdGhlIGxvb3AsIGFs bCBmaXhlZCBpbiBvdXIgd29ya2luZyBjb3B5Lg0KDQrigJQgQ2FybG9zLg0KDQpPbiBBdWcgMzAs IDIwMTYsIGF0IDEwOjIxIEFNLCBBbmRyZXcgRy4gTWFsaXMgPGFnbWFsaXNAZ21haWwuY29tPG1h aWx0bzphZ21hbGlzQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpTaGF3biwNCg0KTWFueSB0aGFua3Mg Zm9yIHlvdXIgcmV2aWV3LiBXZeKAmWxsIGZpeCB0aGUgZWRpdG9yaWFsIGNvbW1lbnQuIFJlZ2Fy ZGluZyBMU1Agc3RpdGNoaW5nLCB0aGlzIGlzIHdlbGwga25vd24gdG8gTVBMUyBleHBlcnRzLCBi dXQgeW914oCZcmUgcmlnaHQsIHRoaXMgc2hvdWxkIGJlIHJlZmVyZW5jZWQuIFJGQyA2NDI0LCB3 aGljaCB3ZSBhbHJlYWR5IGhhdmUgaW4gdGhlIHJlZmVyZW5jZXMsIGlzIGFuIGV4Y2VsbGVudCBy ZWZlcmVuY2UgZm9yIExTUCBzdGl0Y2hpbmcgYW5kIHVzaW5nIExTUCBQaW5nIGFuZCBUcmFjZXJv dXRlIG92ZXIgc3RpdGNoZWQgTFNQcy4gV2XigJlsbCBhZGQgW1JGQzY0MjRdIGluIHRoZSBhcHBy b3ByaWF0ZSBsb2NhdGlvbnMuDQoNClRoYW5rcyBhZ2FpbiwNCkFuZHkNCg0KDQpPbiBUdWUsIEF1 ZyAzMCwgMjAxNiBhdCA0OjI2IEFNLCBTaGF3biBNIEVtZXJ5IDxzaGF3bi5lbWVyeUBvcmFjbGUu Y29tPG1haWx0bzpzaGF3bi5lbWVyeUBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCkkgaGF2ZSByZXZp ZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MN Cm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vz c2VkIGJ5IHRoZSBJRVNHLg0KVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBm b3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5DQphcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQg ZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZQ0KY29tbWVudHMganVzdCBs aWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoaXMgZHJhZnQgc3BlY2lmaWVz IG11bHRpcGF0aCBzdXBwb3J0IGluIGVudmlyb25tZW50cyB3aGVyZSBFbnRyb3B5IExhYmVscw0K KEVMcykgYXJlIHVzZWQgc28gdGhhdCBMYWJlbCBTd2l0Y2hlZCBQYXRoIChMU1ApIFBpbmcgYW5k IFRyYWNlcm91dGUNCm9wZXJhdGlvbnMgYXJlIHBvc3NpYmxlLg0KDQpUaGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgc2VjdGlvbiBkb2VzIGV4aXN0IGFuZCByZWZlcnMgdG8gdGhlIHNlY3VyaXR5 DQpjb25zaWRlcmF0aW9ucyBpbiBiYXNlIHNwZWNpZmljYXRpb25zIGZvciBhcHBsaWNhYmlsaXR5 LiAgVGhlIHNlY3Rpb25zDQpjb250aW51ZXMgdGhhdCB0aGVyZSBhcmUgbm8gbmV3IHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHdpdGgNCnRoaXMgc3BlY2lmaWNhdGlvbi4gIEkgYWdyZWUgd2l0aCB0 aGlzIGFzc2VydGlvbi4NCg0KR2VuZXJhbCBjb21tZW50czoNCg0KTm9uZS4NCg0KRWRpdG9yaWFs IGNvbW1lbnRzOg0KDQpzL2luaXRpYXRvciB0byBub3QgYmUgYWJsZSB0by9pbml0aWF0b3IgdGhh dCBpcyB1bmFibGUgdG8vDQoNCiJMU1BzIHN0aXRjaGVkIHRvZ2V0aGVyIjogbm90IGZvciBzdXJl IHdoYXQgInN0aXRjaGVkIiBtZWFucyBhbmQgd2Fzbid0DQpkZWZpbmVkIGluIHRoZSBUZXJtaW5v bG9neSBzZWN0aW9uLg0KDQpTaGF3bi4NCi0tDQoNCg0KDQo= --_000_D82BC29335C148C69AB38E71F22985E6ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9BFEF35E22266C48A104DF5D0D9A1EBB@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGVhciBTaGF3biwNCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBhZ2FpbiDi gJQganVzdCBjbG9zaW5nIHRoZSBsb29wLCBhbGwgZml4ZWQgaW4gb3VyIHdvcmtpbmcgY29weS48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PuKAlCBDYXJsb3MuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXVnIDMw LCAyMDE2LCBhdCAxMDoyMSBBTSwgQW5kcmV3IEcuIE1hbGlzICZsdDs8YSBocmVmPSJtYWlsdG86 YWdtYWxpc0BnbWFpbC5jb20iIGNsYXNzPSIiPmFnbWFsaXNAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPlNoYXduLA0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TWFueSB0aGFua3MgZm9yIHlvdXIg cmV2aWV3LiBXZeKAmWxsIGZpeCB0aGUgZWRpdG9yaWFsIGNvbW1lbnQuIFJlZ2FyZGluZyBMU1Ag c3RpdGNoaW5nLCB0aGlzIGlzIHdlbGwga25vd24gdG8gTVBMUyBleHBlcnRzLCBidXQgeW914oCZ cmUgcmlnaHQsIHRoaXMgc2hvdWxkIGJlIHJlZmVyZW5jZWQuIFJGQyA2NDI0LCB3aGljaCB3ZSBh bHJlYWR5IGhhdmUgaW4gdGhlIHJlZmVyZW5jZXMsIGlzIGFuIGV4Y2VsbGVudCByZWZlcmVuY2UN CiBmb3IgTFNQIHN0aXRjaGluZyBhbmQgdXNpbmcgTFNQIFBpbmcgYW5kIFRyYWNlcm91dGUgb3Zl ciBzdGl0Y2hlZCBMU1BzLiBXZeKAmWxsIGFkZCBbUkZDNjQyNF0gaW4gdGhlIGFwcHJvcHJpYXRl IGxvY2F0aW9ucy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPlRoYW5rcyBhZ2Fpbiw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QW5keTwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5P biBUdWUsIEF1ZyAzMCwgMjAxNiBhdCA0OjI2IEFNLCBTaGF3biBNIEVtZXJ5IDxzcGFuIGRpcj0i bHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86c2hhd24uZW1lcnlAb3JhY2xlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnNoYXduLmVtZXJ5QG9yYWNsZS5jb208L2E+Jmd0 Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAi IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0iIj48L3ByZT4NCjxkaXYgY2xhc3M9IiI+DQo8cHJlIGNs YXNzPSIiPkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRlJ3MNCm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1 bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLg0KVGhlc2UgY29tbWVudHMgd2VyZSB3 cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5DQphcmVhIGRp cmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVz ZQ0KY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRo aXMgZHJhZnQgc3BlY2lmaWVzIG11bHRpcGF0aCBzdXBwb3J0IGluIGVudmlyb25tZW50cyB3aGVy ZSBFbnRyb3B5IExhYmVscw0KKEVMcykgYXJlIHVzZWQgc28gdGhhdCBMYWJlbCBTd2l0Y2hlZCBQ YXRoIChMU1ApIFBpbmcgYW5kIFRyYWNlcm91dGUNCm9wZXJhdGlvbnMgYXJlIHBvc3NpYmxlLg0K DQpUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBkb2VzIGV4aXN0IGFuZCByZWZl cnMgdG8gdGhlIHNlY3VyaXR5DQpjb25zaWRlcmF0aW9ucyBpbiBiYXNlIHNwZWNpZmljYXRpb25z IGZvciBhcHBsaWNhYmlsaXR5LiAgVGhlIHNlY3Rpb25zDQpjb250aW51ZXMgdGhhdCB0aGVyZSBh cmUgbm8gbmV3IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdpdGgNCnRoaXMgc3BlY2lmaWNhdGlv bi4gIEkgYWdyZWUgd2l0aCB0aGlzIGFzc2VydGlvbi4NCg0KR2VuZXJhbCBjb21tZW50czoNCg0K Tm9uZS4NCg0KRWRpdG9yaWFsIGNvbW1lbnRzOg0KDQpzL2luaXRpYXRvciB0byBub3QgYmUgYWJs ZSB0by9pbml0aWF0b3IgdGhhdCBpcyB1bmFibGUgdG8vDQoNCiZxdW90O0xTUHMgc3RpdGNoZWQg dG9nZXRoZXImcXVvdDs6IG5vdCBmb3Igc3VyZSB3aGF0ICZxdW90O3N0aXRjaGVkJnF1b3Q7IG1l YW5zIGFuZCB3YXNuJ3QNCmRlZmluZWQgaW4gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24uDQoNClNo YXduLg0KLS0NCjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D82BC29335C148C69AB38E71F22985E6ciscocom_-- From nobody Fri Sep 2 00:36:57 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF8812D0C6 for ; Fri, 2 Sep 2016 00:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.768 X-Spam-Level: X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHoiEu1H9xdX for ; Fri, 2 Sep 2016 00:36:52 -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 47C4F12D0E2 for ; Fri, 2 Sep 2016 00:36:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CVN67153; Fri, 02 Sep 2016 07:36:48 +0000 (GMT) Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 2 Sep 2016 08:36:47 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.6]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Fri, 2 Sep 2016 15:36:40 +0800 From: "Xialiang (Frank)" To: "Rusch, Andreas" , "Kaliski, Burt" Thread-Topic: secdir review of draft-moriarty-pkcs5-v2dot1-01 Thread-Index: AdIDbtQMbJEl3m8/Q2qkTlutw9fhVABHl6EAABIQepAABcMwEA== Date: Fri, 2 Sep 2016 07:36:40 +0000 Message-ID: References: <6686A3AC7EA3FF479DACDDDD98B4A62D83007D2E@MX201CL03.corp.emc.com> In-Reply-To: <6686A3AC7EA3FF479DACDDDD98B4A62D83007D2E@MX201CL03.corp.emc.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.99.221] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AFBC287SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.57C92C11.00E0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.6, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e61c7995b6ca769d0f16e83dcfecdc7e Archived-At: Cc: "draft-moriarty-pkcs5-v2dot1.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-moriarty-pkcs5-v2dot1-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 07:36:56 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12AFBC287SZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Thanks for your response and clarification. I have no more comments right now. B.R. Frank From: Rusch, Andreas [mailto:andreas.rusch@rsa.com] Sent: Friday, September 02, 2016 12:53 PM To: Kaliski, Burt; Xialiang (Frank); draft-moriarty-pkcs5-v2dot1.all@tools.= ietf.org Subject: RE: secdir review of draft-moriarty-pkcs5-v2dot1-01 Hi Frank, I don't have any additional things, I completely agree with Burt's response= s. I will do the changes today and post a new version (v02). Thanks a lot for the great review, very much appreciated! Cheers, Andreas From: Kaliski, Burt [mailto:bkaliski@verisign.com] Sent: 02 September 2016 06:40 To: Xialiang (Frank); draft-moriarty-pkcs5-v2dot1.all@tools.ietf.org Subject: RE: secdir review of draft-moriarty-pkcs5-v2dot1-01 Thanks for the detailed review, Frank. My responses are included below, pr= efixed [BK]. I appreciate your taking the time to review this document. The RSA/EMC co-authors may have additional responses. n Burt From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com] Sent: Wednesday, August 31, 2016 6:03 AM To: 'iesg@ietf.org'; 'secdir@ietf.org'; draft-moriarty-pkcs5-v2dot1.all@too= ls.ietf.org Subject: secdir review of draft-moriarty-pkcs5-v2dot1-01 Hello, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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 provides recommendations for the implementation of password-b= ased cryptography, covering key derivation functions, encryption schemes, m= essage-authentication schemes, and ASN.1 syntax identifying the techniques.= And this document represents a republication of PKCS #5 v2.1 from RSA Labo= ratories' Public-Key Cryptography Standards (PKCS) series. By publishing th= is RFC, change control is transferred to the IETF. In general, this draft is based on [RFC2898] (PKCS #5) and RSA new released= PKCS #5 V2.1 specification, and includes some minor updates to them. So, i= t has a solid security basis. Regarding to the new introduced contents, the= re are no more new security threats identified. Summary: this document appears in reasonably good shape, with minor issues = that should be addressed before publication. Below is a series of my comments, nits for your consideration. comments: Section 5.1 "S salt, an eight-octet string": This sentence is not accurate. The Salt= used in the PBKDF1 algorithm should be an octet string with more than 8 by= tes length here; [BK] The text appears in both the source document* and RFC 2898. However,= in both places, the guidance on salt is that it should be "at least eight = octets" long. In other words, it should be at least eight octets long, but= it could be exactly eight octets or shorter. In any case, the error is an= old one. Although the authors' intent is to republish the source document= essentially as is, I'd recommend to drop "eight-octet" here since it confl= icts with the internal guidance. * http://www.emc.com/collateral/white-papers/h11302-pkcs5v2-1-password-base= d-cryptography-standard-wp.pdf section 5.2 "applied to the password P and the concatenation of the salt S and the bloc= k index i:": this sentence seems to be not clear to explain the following s= eries of equations, for example: 1. how to use "i" in them? 2. how to use "Salt" in them? Would you please clarify the issue and improve the content to be more clear= ? [BK] The password P is input to every iteration. The salt S and the block = index i are only input to the first iteration. However, P and S || INT(i) = are collectively the inputs to the process of computing all the iterates. = Better text would be: "first c iterates of the underlying pseudorandom func= tion PRF under the password P, where the first iterate is applied to the co= ncatenation of the salt S and the block index i:" However, I'm inclined to= keep it as is because it is not incorrect, and the intent is to republish. [BK] As you've noted below, the text was missing the line "F (P, S, c, i) = =3D U_1 \xor U_2 \xor ... \xor U_c". This covers the "exclusive-or sum of = the iterates". nits: Abstract 1. PKCS #8 should have a reference of [PKCS8][RFC5958]; [BK] Agreed. 2. The second "-" in "password-based-key" should be removed; [BK] Good catch. 3. If there is PKCS #5 V2.1 specification, the reference of it should be ad= ded after the content of "PKCS #5 V2.1"; [BK] OK. The source document can be added as a final reference. Section 1 Please split the last two words of "compatibletechniques.". [BK] OK. Section 2 Miss "\xor" before "bit-wise exclusive-or of two octet strings". [BK] Good catch. Section 5.1 "DK =3D Tc<0..dkLen-1>": Tc should be T_c. [BK] Another good one. Section 5.2 1. The title of Section 5.2 should be "PBKDF2"; [BK] Thanks. 2. A calculation equation is missed here: "F (P, S, c, i) =3D U_1 \xor U_2 = \xor ... \xor U_c". [BK] Good catch. Section 6.1.1 The title of the Section should be "PBES1 Encryption Operation". [BK] Yes. In table of contents as well. Appendix A.1 "for PBES1" should be changed to "for PBKDF1". [BK] PBKDF1 doesn't need an algorithm identifier because PBES1 defines a d= ifferent algorithm identifier for each underlying password-based key deriva= tion function. PBKDF2, in contrast, needs one because PBES2's algorithm id= entifier is modularized. This is the reason the text says "the object ide= ntifiers for PBES1 are sufficient." So no change is needed (and the change= would be incorrect). Thanks! B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12AFBC287SZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,=

Thanks = for your response and clarification.

I have = no more comments right now.

&n= bsp;

B.R.

Frank

&n= bsp;

From: Rusch, Andre= as [mailto:andreas.rusch@rsa.com]
Sent: Friday, September 02, 2016 12:53 PM
To: Kaliski, Burt; Xialiang (Frank); draft-moriarty-pkcs5-v2dot1.all= @tools.ietf.org
Subject: RE: secdir review of draft-moriarty-pkcs5-v2dot1-01

 

Hi Frank,

 

I don’t have any additional things, I completely agree with= Burt’s responses.

 

I will do the changes today and post a new version (v02).

 

Thanks a lot for the great review, very much appreciated!

 

Cheers,

Andreas

 

 

 

Thanks for the detailed review, Frank.  My responses are inc= luded below, prefixed [BK].

 

I appreciate your taking the time to review this document.

 

The RSA/EMC co-authors may have additional responses.<= /span>

 

n  Burt

 

From: Xialiang (Fr= ank) [mailto:frank.xialiang@hu= awei.com]
Sent: Wednesday, August 31, 2016 6:03 AM
To: 'iesg@ietf.org'; 'secdir@ietf.org'; draft-moriarty-pkcs5-v2dot1.all@tools.ietf.org
Subject: secdir review of draft-moriarty-pkcs5-v2dot1-01<= /span>

 

Hello,

 

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

 

 

This document provides recommen= dations for the implementation of password-based cryptography, covering key= derivation functions, encryption schemes, message-authentication schemes, = and ASN.1 syntax identifying the techniques. And this document represents a republication of PKCS #5 v2.1 from RSA Labo= ratories’ Public-Key Cryptography Standards (PKCS) series. By publish= ing this RFC, change control is transferred to the IETF.<= /p>

 

 

In general, this draft is based= on [RFC2898] (PKCS #5) and RSA new released PKCS #5 V2.1 specification, an= d includes some minor updates to them. So, it has a solid security basis. R= egarding to the new introduced contents, there are no more new security threats identified.

 

 

Summary: this document appears = in reasonably good shape, with minor issues that should be addressed before= publication.

 

 

Below is a series of my comment= s, nits for your consideration.

 

 

comments:

 

Section 5.1

"S    salt,= an eight-octet string": This sentence is not accurate. The Salt used = in the PBKDF1 algorithm should be an octet string with more than 8 bytes le= ngth here;

&n= bsp;

[BK]  The text appears in both the source document* and RFC = 2898.  However, in both places, the guidance on salt is that it should= be “at least eight octets” long.  In other words, it should be at least eight octets long, but it could be exactly eight oct= ets or shorter.  In any case, the error is an old one.  Although = the authors’ intent is to republish the source document essentially a= s is, I’d recommend to drop “eight-octet” here since it conflicts with the internal guidance.

 

* http://www.emc.com/collateral/white-papers/h11302-pkcs5v2-1-password-based-= cryptography-standard-wp.pdf

 

section 5.2

"applied to the password P= and the concatenation of the salt S and the block index i:": this sen= tence seems to be not clear to explain the following series of equations, f= or example:

1. how to use "i" in = them?

2. how to use "Salt" = in them?

Would you please clarify the is= sue and improve the content to be more clear?

&n= bsp;

[BK] The password P is input to every iteration.  The salt S= and the block index i are only input to the first iteration.  However= , P and S || INT(i) are collectively the inputs to the process of computing all the iterates.  Better text would be: = “first c iterates of the underlying pseudorandom function PRF under t= he password P, where the first iterate is applied to the concatenation of t= he salt S and the block index i:”  However, I’m inclined to keep it as is because it is not incorrect, and the i= ntent is to republish.

 

[BK] As you’ve noted below, the text was missing the line &= quot;F (P, S, c, i) =3D U_1 \xor U_2 \xor ... \xor U_c".  This co= vers the “exclusive-or sum of the iterates”.<= /p>

 

nits:

 

Abstract

1. PKCS #8 should have a refere= nce of [PKCS8][RFC5958];

 

 

[BK] Agreed.

&n= bsp;

2. The second "-" in = "password-based-key" should be removed;

 

[BK] Good catch.

&n= bsp;

3. If there is PKCS #5 V2.1 spe= cification, the reference of it should be added after the content of "= PKCS #5 V2.1";

 

[BK] OK.  The source document can be added as a final refere= nce.

&n= bsp;

Section 1

Please split the last two words= of "compatibletechniques.".

 

[BK] OK.

&n= bsp;

Section 2

Miss "\xor" before &q= uot;bit-wise exclusive-or of two octet strings".

 

[BK]  Good catch.

&n= bsp;

Section 5.1

"DK =3D Tc<0..dkLen-1&g= t;": Tc should be T_c.

 

[BK]  Another good one.

&n= bsp;

Section 5.2

1. The title of Section 5.2 sho= uld be "PBKDF2";

&n= bsp;

[BK]  Thanks.

 

2. A calculation equation is mi= ssed here: "F (P, S, c, i) =3D U_1 \xor U_2 \xor ... \xor U_c".

&n= bsp;

[BK] Good catch.

 

Section 6.1.1=

The title of the Section should= be "PBES1 Encryption Operation".

&n= bsp;

[BK] Yes.  In table of contents as well.

 

Appendix A.1<= /p>

"for PBES1" should be= changed to "for PBKDF1".

 

[BK]  PBKDF1 doesn’t need an algorithm identifier beca= use PBES1 defines a different algorithm identifier for each underlying pass= word-based key derivation function.  PBKDF2, in contrast, needs one because PBES2’s algorithm identifier is modularized. =   This is the reason the text says “the object identifiers for P= BES1 are sufficient.”  So no change is needed (and the change wo= uld be incorrect).

 

Thanks!

 

B.R.

Frank

 

--_000_C02846B1344F344EB4FAA6FA7AF481F12AFBC287SZXEMA502MBSchi_-- From nobody Fri Sep 2 03:48:46 2016 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 A8F3E12D79D; Fri, 2 Sep 2016 01:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1472805570; bh=nk3GX67f1eIPfEH0Y/l6Zg4oB/643J28dv1CoIZYiSk=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=LJEU9YiuIJ7r39kn8qLd+ToUEZuMoOxhZRgxY6MFoM/T8ytHzBb1/40dtr2X+z5BE BS9gxdqLxbDkMHKahdrBhEYweNAyUsz4IZLl34gA4SKI3rtfyjv8dLycgwL6IfxeMQ IQfJ11wREqVXCfIHj47LZZ4S5T8StlFQ17UwT3tM= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909D912D7A5 for ; Fri, 2 Sep 2016 01:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXv707w_7uWW for ; Fri, 2 Sep 2016 01:39:26 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7334E12D7A4 for ; Fri, 2 Sep 2016 01:39:26 -0700 (PDT) Received: from suzuki.awa.sfc.keio.ac.jp ([133.27.18.149] helo=[10.11.35.12]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1bfk0S-0005x8-P9 for new-work@ietf.org; Fri, 02 Sep 2016 08:39:25 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: Date: Fri, 2 Sep 2016 16:39:42 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 02 Sep 2016 03:48:45 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web Platform Working Group (until 2016-09-30) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 08:39:31 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Web Platform Working Group: https://www.w3.org/2016/08/web-platform-charter-draft.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2016-09-30 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact the Team Contacts: Xiaoqian Wu or Yves Lafon . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Sep 2 06:02:20 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842A312D81B; Fri, 2 Sep 2016 06:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jmX9TISNY7V; Fri, 2 Sep 2016 06:02:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6ED12D805; Fri, 2 Sep 2016 06:02:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sQfR35fZ8zJt7; Fri, 2 Sep 2016 15:02:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1472821327; bh=F4Ep3+B7O7t6dn7t5N1LrZuXflgBTdAeZ34ymMmTbMM=; h=Date:From:To:cc:Subject; b=HpDBObUFaBudt8H38d6Z7w664Sa6CeZtu3FG9KRr5JpJFk3H9OdVa3cTq6Yf7AnxQ IB1wj/D4L96VZL+bqh6rBKmz4RD/qmOjLwjbBgREmMbzDHdV0JVVfkuTHaAgnITDjg DkMmPo/LM8JrHGs77lY6+HFJEe1ZwQ/Q4atTKcuU= 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 TvuYeODjlvsk; Fri, 2 Sep 2016 15:02:06 +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; Fri, 2 Sep 2016 15:02:06 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 740DD2ED945; Fri, 2 Sep 2016 09:02:05 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 740DD2ED945 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5E31A410929E; Fri, 2 Sep 2016 09:02:05 -0400 (EDT) Date: Fri, 2 Sep 2016 09:02:05 -0400 (EDT) From: Paul Wouters To: iesg@ietf.org, secdir Message-ID: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Cc: draft-moriarty-pkcs1.all@ietf.org Subject: [secdir] SecDir review of draft-moriarty-pkcs1-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:02:15 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. [Note this document describes various RSA modes. I am not a cryptographer] This document is Ready with nits This document describes various RSA methods. It explains and describes various attacks and why certain decisions are made for security reasons throughout the document. Therefore, the Security Considerations section simply states: Security considerations are discussed throughout this memo. Which I think is correct. (Although I would use the word "document" instead of "memo" which I think is more common witin IETF) The only real question I have is regarding this paragraph: While RSAES-PKCS1-v1_5 (Section 7.2) and RSASSA-PKCS1-v1_5 (Section 8.2) have traditionally been employed together without any known bad interactions (indeed, this is the model introduced by PKCS #1 v1.5), such a combined use of an RSA key pair is NOT RECOMMENDED for new applications. I thought that issuing malicious encryption commands to a RSASSA-PKCS1-v1_5 based (software) device could lead to compromise of the private key, and that this was the Bleichenbacher attack? and that forbidding encryption for a signing-only service would have a security advantage? Nits: u distinct odd primes Do you mean an odd number of primes? As primes are always odd, unless you mean odd in the English sense :) Four types of primitive are Add "s" to primitive ? Paul From nobody Fri Sep 2 11:57:17 2016 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 D538C12D54B; Fri, 2 Sep 2016 11:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1472842510; bh=BzY5LaWog79d/XYzoM4TVuTnGM/9lLlmu+xzS67CDq0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=k6dgCoH6zBluXdgthF/EDTl4splJv4Hf1Khyxy6m0uFMDkOeiQa+/dJpocGlJeF53 9ef+KwVgq2/8opsRh6XbcnLZ5M/h4tWF6t4fFZk+e017oY4npF1TtEHiOKTPN2qX+y 8TJ6DQgBkDMDeJoQFGmcCSoyQpLDUCSveoOq5gbU= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9F012D19E for ; Fri, 2 Sep 2016 11:55:04 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <147284250411.24754.3877163198670263683.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2016 11:55:04 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 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, 02 Sep 2016 11:57:16 -0700 Subject: [secdir] [new-work] WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 18:55:11 -0000 The IP Security Maintenance and Extensions (ipsecme) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-09-12. IP Security Maintenance and Extensions (ipsecme) ----------------------------------------------------------------------- Current status: Active WG Chairs: David Waltermire Tero Kivinen Assigned Area Director: Kathleen Moriarty Security Area Directors: Stephen Farrell Kathleen Moriarty Mailing list: Address: ipsec@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv2 contains the cookie mechanism to protect against denial of service attacks. However this mechanism cannot protect an IKE end-point (typically, a large gateway) from "distributed denial of service", a coordinated attack by a large number of "bots". The working group will analyze the problem and propose a solution, by offering best practices and potentially by extending the protocol. IKEv2 utilizes a number of cryptographic algorithms in order to provide security services. To support interoperability a number of mandatory-to-implement (MTI) algorithms are defined in RFC4307 for IKEv2 and in RFC7321 for ESP/AH. There is interest in updating the MTIs in RFC4307 and RFC7321 based on new algorithms, changes to the understood security strength of existing algorithms, and the degree of adoption of previously introduced algorithms. The group will revise RFC4307 and RFC7321 proposing updates to the MTI algorithms used by IKEv2 and IPsec to address these changes. There is interest in supporting Curve25519 and Curve448 for ephemeral key exchange and EdDSA for authentication in the IKEv2 protocol. The group will extend the IKEv2 protocol to support key agreement using these curves and their related functions. IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify IKEv2 to have similar quantum resistant properties than IKEv1 had. There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE and ESP packets need to be transmitted over TCP. Therefore the group will define a mechanism to use IKE and IPsec over TCP. The group will also provide guidance on how to detect when IKE cannot be negotiated over UDP, and TCP should be used as a fallback Split-DNS is a common configuration for VPN deployments, in which only one or a few private DNS domains are accessible and resolvable via the tunnel. Adding new configuration attributes to IKEv2 for configuring Split-DNS would allow more deployments to adopt IKEv2. This configuration should also allow verification of the domains using DNSSEC. Working group will specify needed configuration attributes for IKEv2. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in form of counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. This charter will expire in December 2017. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Mar 2016 - IETF Last Call on DDoS protection Mar 2016 - IETF Last Call on cryptographic algorithms for IKEv2 Mar 2016 - IETF Last Call on Curve25519 and Curve448 for IKEv2 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sun Sep 4 17:16:44 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8501812B0E0; Sun, 4 Sep 2016 17:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_DEKATGRCIg; Sun, 4 Sep 2016 17:16:34 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0088.outbound.protection.outlook.com [104.47.42.88]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C1D12B034; Sun, 4 Sep 2016 17:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vI7SmDry1pfup7Jm2kogoGj1FIM6gg6KEn1UmaN1atA=; b=EUABfZHjQIQsmTS/TqFThcC9yl8IGEf+FSH7geFQD8/qk/7kGf3J9ABgY8pRDwEZMKXbaFyoC+h8HqTdKH0iml+PsUqSUWptxEodlyGvuWYCd4rh0WJGIBELO+RxnxQlEO+bG4yJ0se6jYSH5cb9ZMbkxea5fq8qSNMIDdE7tTE= Received: from CY4PR02MB2566.namprd02.prod.outlook.com (10.173.41.13) by CY4PR02MB2568.namprd02.prod.outlook.com (10.173.41.15) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Mon, 5 Sep 2016 00:16:33 +0000 Received: from CY4PR02MB2566.namprd02.prod.outlook.com ([10.173.41.13]) by CY4PR02MB2566.namprd02.prod.outlook.com ([10.173.41.13]) with mapi id 15.01.0599.016; Mon, 5 Sep 2016 00:16:33 +0000 From: Larry Masinter To: John C Klensin Thread-Topic: [secdir] SecDir Review of https://tools.ietf.org/html/draft-hardy-pdf-mime-02#page-8 Thread-Index: AQHSBwrBaIB7vCzq1UaRBVbebiCcGw== Date: Mon, 5 Sep 2016 00:16:33 +0000 Message-ID: <36612F03-C66A-44B1-ACDE-DACDB2844CA5@adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.19.0.160817 authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.184.24.49] x-ms-office365-filtering-correlation-id: 46ca3c11-3846-491c-57ad-08d3d521e4a4 x-microsoft-exchange-diagnostics: 1; CY4PR02MB2568; 6:+Bvhw65Ie3LAioNFWcXYcDTqWLyRSFvpqs5m8PgYTVdT55Dj7t68rAKUT5v+rwbrhROEdNIwanvQJjKshIDkCN9rAyRIPi81RI+ln3eIsa5W75wrq6keRJwFEsxdClEyUIdsc+ALugWd2a2Fcct6vwK5U4Ayr/vaX30DTTalp8XRDmBv706mRCFKlLJQeV3TwD52fmvvGS7otZWLNcDb+tkMhyYBS4WVek8FM06irrVDVn2k7AfHV1GB5c8maBCRp/Igdas+nc1BXKM54CEPbNxRyQONxRPbhzNZjfr57T/Znidg7nrVetIZT2pixecfi2aQL2mU96vZuJCK8xXH6w==; 5:H55hvh78xvrVWv/+i4AxOhR1+5Bxrc59CrE+nDO+6kLRilYKIRjZqo9nUn4bZi1B8gcLUG7deQbn3O64acfQlXotvH+ZF043p69J50OJYsnaX07QeIrZIo7/X08Wt1cLlHov1wbGaBvB7eIIBVaE4Q==; 24:VTpCONsLsUCeESssNxrLmkeT4xcmo+EV+GJxktGIBFnWHpSZz9gmzU4uIkHwjWw/3NdEXR5cb2C109HVQQSU2ZnaO+NzKNd7gxQjWFbC32g=; 7:dqBdf4UxyYRrXwH1MMwqjVgmLVXY+GXkeLFkKnwFHhwgSg/nDgkCh9aEMosZ3+gnIEzGbCQP9npmqxGNybZOuDTaji/TsyETXy9yfGQdKaKgknpjBea+Tlh+z9PCk6FFUsArS0LdYGP5fig002jHQZEBAXGMaOZafw/fftuDtFrCsSxaIBXgo2o6P9RpQOhTn2tu5bsgoxOa9m1kHEtOViJ56DuDYWVnJta/EjlMUJEwzz/BNmCcIen0AOQcN4i1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY4PR02MB2568; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY4PR02MB2568; BCL:0; PCL:0; RULEID:; SRVR:CY4PR02MB2568; x-forefront-prvs: 005671E15D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(122556002)(66066001)(83506001)(77096005)(2900100001)(3846002)(102836003)(586003)(3660700001)(68736007)(8676002)(189998001)(15975445007)(3280700002)(6116002)(2906002)(4001350100001)(7846002)(97736004)(92566002)(230783001)(81166006)(81156014)(99286002)(106356001)(83716003)(7736002)(106116001)(105586002)(305945005)(4326007)(5660300001)(8936002)(10400500002)(86362001)(19580395003)(11100500001)(10090500001)(110136002)(36756003)(345774005)(87936001)(82746002)(5002640100001)(101416001)(50986999)(33656002)(54356999)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR02MB2568; H:CY4PR02MB2566.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2016 00:16:33.3402 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR02MB2568 Archived-At: Cc: "draft-hardy-pdf-mime.all@tools.ietf.org" , Phillip Hallam-Baker , "iesg@ietf.org" , "secdir@ietf.org" , "Ietf@Ietf. Org" Subject: Re: [secdir] SecDir Review of https://tools.ietf.org/html/draft-hardy-pdf-mime-02#page-8 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 00:16:36 -0000 Sm9obiwNClRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cyBvZiAwOCBKdWwgMjAxNiBpbiByZXBs eSB0byBQaGlsbGlwIEhhbGxhbS1CYWtlcuKAmXMgbWVzc2FnZS4NCg0KU2VlIGh0dHBzOi8vbWFp bGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvaWV0Zi95S2JqTFlVY3hISGRqNjNQYnJXYnRlMTJq QkUNCg0KU2VlIOKAnEhpc3RvcnnigJ0gKGFwcGxpY2F0aW9uL3BkZiB3YXMgZmlyc3QgcmVnaXN0 ZXJlZCBpbiA5MykNCuKAnFNlY3VyaXR5IENvbnNpZGVyYXRpb25z4oCdIChpdCB3YXNu4oCZdCBh IHN1cnByaXNlKQ0KYW5kIOKAnEFkb2JlIFBERiB2cyBJU08gU3BlY3PigJ0gKHRlY2huaWNhbGx5 IGlkZW50aWNhbCBwZXIgRmFzdCBUcmFjayBydWxlcykNCg0KTGFycnkNCi0tDQpodHRwOi8vbGFy cnkubWFzaW50ZXIubmV0DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg== From nobody Mon Sep 5 00:04:41 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A2112B09E; Mon, 5 Sep 2016 00:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwVWQyKvIF3f; Mon, 5 Sep 2016 00:04: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 99943128E18; Mon, 5 Sep 2016 00:04:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQT11143; Mon, 05 Sep 2016 07:04:29 +0000 (GMT) Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 5 Sep 2016 08:03:52 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.50]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Mon, 5 Sep 2016 15:03:42 +0800 From: Jiangyuanlong To: "Steve.Hanna@infineon.com" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-pals-mc-pon@ietf.org" Thread-Topic: secdir review of draft-ietf-pals-mc-pon-04 Thread-Index: AdIERGNJ4u3omnmWQ2+8lMLF4/56GQAE89FQALQA5lA= Date: Mon, 5 Sep 2016 07:03:41 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B91732D86@szxema506-mbs.china.huawei.com> References: <71cbf9b3372247f297987d0bb1acdd67@MUCSE609.infineon.com> In-Reply-To: <71cbf9b3372247f297987d0bb1acdd67@MUCSE609.infineon.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.203.119] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B91732D86szxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.57CD18FE.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.50, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 181776cf2ccb1e8546a00f9b9a6fc472 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-pals-mc-pon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 07:04:37 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B91732D86szxema506mbschi_ Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: quoted-printable Hi Steve, Thank a lot for your review. Please see my replies with +AFs-JY+AF0-. Kind regards, Yuanlong From: Steve.Hanna+AEA-infineon.com +AFs-mailto:Steve.Hanna+AEA-infineon.com= +AF0- Sent: Thursday, September 01, 2016 9:55 PM To: iesg+AEA-ietf.org+ADs- secdir+AEA-ietf.org+ADs- draft-ietf-pals-mc-pon+= AEA-ietf.org Subject: RE: secdir review of draft-ietf-pals-mc-pon-04 Resending with correct draft alias. Steve From: Hanna Steve (IFAM CCS SMD AMR) Sent: Thursday, September 01, 2016 7:57 AM To: 'iesg+AEA-ietf.org'+ADs- 'secdir+AEA-ietf.org'+ADs- 'draft-ietf-pals-mc= -pon-04.all+AEA-ietf.org' Subject: secdir review of draft-ietf-pals-mc-pon-04 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. Summary: Ready with issues The security considerations section of this document seems reasonable and c= orrect. However, I+IBk-m concerned that bringing ICCP into the PON has some= security risks that have not been properly called out and mitigated. As th= e Security Considerations section says: In many passive optical networks the optical paths between OLT and ONTs traverse publicly accessible facilities including public attachments (e.g. telephone poles) Note that I+IBk-m pretty sure that ONT should be ONU here and in several ot= her places in the Security Considerations. +AFs-JY+AF0- ONT (Optical Network Terminal) is a similar term of ONU (Optic= al Network Unit), both of them are used widely and almost interchangeably i= n the PON network. But I agree with you that we don+IBk-t need to introduce a new term in the = +IBw-Security considerations+IB0- and we will use ONU consistently in the n= ext revision. My concern is that section 4.2 says that +IBw-When a fault is detected on i= ts working PW (e.g., by VCCV BFD), a working OLT SHOULD turn off its associ= ated PON interface and then send an ICCP message with PON State TLV with lo= cal PON Port State being set to notify the protection OLT of the PON fault.= +IB0- Since the working PW has failed, the working OLT will presumably send= this ICCP message to the protection PW over the PON. That means that any o= ther authorized or unauthorized party on the PON could also send such a mes= sage. I+IBk-m not very familiar with ICCP but the Security Considerations s= ection of RFC 7275 seems to say that ICCP messages are frequently authentic= ated only by looking at the source IP address, which is an exceedingly weak= method of authentication susceptible to easy forgery. Using MD5 (as permit= ted by RFC 7275) isn+IBk-t much better. The impact of permitting attackers = to easily forge ICCP messages on the PON is not clear to me but it seems th= at the attacker could at least prevent proper failover and maybe force fail= over or even force failure. Of course, an attacker on the PON could also ju= st jam the PON by setting their laser always on but ICCP attacks would be m= uch trickier to detect. I would suggest that TCP-AO be required at least fo= r ICCP messages sent or received on the PON. +AFs-JY+AF0- The assumption that +IBw-the working OLT will presumably send = this ICCP message to the protection PW over the PON+IB0- does not parse, do= you mean +IBw-the working OLT will presumably send this ICCP message to th= e protection OLT over the PON+IB0-? But this case will never happen if the = protection mechanism works as described in this document, since the Protect= ion trunk link will not be activated until the PON switching protection is = finished (that is, after the Working trunk link is off and an ICCP message = is received). Maybe the confusion is caused by a lack of interconnection b= etween the OLTs in Figure 1. But this document assumes that there is an ICC= P interconnect between the OLTs. Please also be aware that Section 3.2 +IBw= -ICCP Interconnect Scenarios+IB0- of RFC 7275 discusses the details of how = to interconnect the PEs (i.e., the OLTs) in a redundancy group, thus all th= ese ICCP interconnect scenarios are applicable to draft-ietf-pals-mc-pon-04= too. Furthermore, the ONUs are out of the MPLS network domain where OLTs reside,= LDP protocol (ICCP is one sub-type) session will not be established betwee= n any ONU and any OLT, therefore, ICCP attack from the PON side is not rega= rded as an issue. Two minor typos: 1) In section 3, +IBw-protect OLTs+IB0- should be +IBw-protection OLTs= +IB0-. +AFs-JY+AF0- Good catch. We will update it. 2) In the Security Considerations, +IBw-ONT+IB0- should be +IBw-ONU+IB= 0-. At least, I assume so. If not, ONT should be defined. +AFs-JY+AF0- Agreed. Thanks for your consideration, Steve --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B91732D86szxema506mbschi_ Content-Type: text/html; charset="utf-7" Content-Transfer-Encoding: quoted-printable +ADw-html xmlns:v+AD0AIg-urn:schemas-microsoft-com:vml+ACI- xmlns:o+AD0AIg-= urn:schemas-microsoft-com:office:office+ACI- xmlns:w+AD0AIg-urn:schemas-mic= rosoft-com:office:word+ACI- xmlns:m+AD0AIg-http://schemas.microsoft.com/off= ice/2004/12/omml+ACI- xmlns+AD0AIg-http://www.w3.org/TR/REC-html40+ACIAPg- +ADw-head+AD4- +ADw-meta name+AD0AIg-Generator+ACI- content+AD0AIg-Microsoft Word 12 (filt= ered medium)+ACIAPg- +ADw-style+AD4- +ADwAIQ--- /+ACo- Font Definitions +ACo-/ +AEA-font-face +AHs-font-family:+W4tPUwA7- panose-1:2 1 6 0 3 1 1 1 1 1+ADsAfQ- +AEA-font-face +AHs-font-family:+ACI-Cambria Math+ACIAOw- panose-1:2 4 5 3 5 4 6 3 2 4+ADsAfQ- +AEA-font-face +AHs-font-family:Calibri+ADs- panose-1:2 15 5 2 2 2 4 3 2 4+ADsAfQ- +AEA-font-face +AHs-font-family:+ACIAXABAW4tPUwAiADs- panose-1:2 1 6 0 3 1 1 1 1 1+ADsAfQ- +AEA-font-face +AHs-font-family:Tahoma+ADs- panose-1:2 11 6 4 3 5 4 4 2 4+ADsAfQ- /+ACo- Style Definitions +ACo-/ p.MsoNormal, li.MsoNormal, div.MsoNormal +AHs-margin:0cm+ADs- margin-bottom:.0001pt+ADs- font-size:11.0pt+ADs- font-family:+ACI-Calibri+ACI-,+ACI-sans-serif+ACIAOwB9- a:link, span.MsoHyperlink +AHs-mso-style-priority:99+ADs- color:blue+ADs- text-decoration:underline+ADsAfQ- a:visited, span.MsoHyperlinkFollowed +AHs-mso-style-priority:99+ADs- color:purple+ADs- text-decoration:underline+ADsAfQ- p.MsoPlainText, li.MsoPlainText, div.MsoPlainText +AHs-mso-style-priority:99+ADs- mso-style-link:+ACJ+r2WHZyw- Char+ACIAOw- margin:0cm+ADs- margin-bottom:.0001pt+ADs- font-size:11.0pt+ADs- font-family:+ACI-Calibri+ACI-,+ACI-sans-serif+ACIAOwB9- p.MsoAcetate, li.MsoAcetate, div.MsoAcetate +AHs-mso-style-priority:99+ADs- mso-style-link:+ACJieWzoaEZlh2cs- Char+ACIAOw- margin:0cm+ADs- margin-bottom:.0001pt+ADs- font-size:9.0pt+ADs- font-family:+ACI-Calibri+ACI-,+ACI-sans-serif+ACIAOwB9- p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph +AHs-mso-style-priority:34+ADs- margin-top:0cm+ADs- margin-right:0cm+ADs- margin-bottom:0cm+ADs- margin-left:36.0pt+ADs- margin-bottom:.0001pt+ADs- font-size:11.0pt+ADs- font-family:+ACI-Calibri+ACI-,+ACI-sans-serif+ACIAOwB9- span.Char +AHs-mso-style-name:+ACJ+r2WHZyw- Char+ACIAOw- mso-style-priority:99+ADs- mso-style-link:+fq9lh2csADs- font-family:+W4tPUwA7AH0- p.PlainText, li.PlainText, div.PlainText +AHs-mso-style-name:+ACI-Plain Text+ACIAOw- mso-style-link:+ACI-Plain Text Char+ACIAOw- margin:0cm+ADs- margin-bottom:.0001pt+ADs- font-size:11.0pt+ADs- font-family:+ACI-Calibri+ACI-,+ACI-sans-serif+ACIAOwB9- span.PlainTextChar +AHs-mso-style-name:+ACI-Plain Text Char+ACIAOw- mso-style-priority:99+ADs- mso-style-link:+ACI-Plain Text+ACIAOw- font-family:+ACI-Calibri+ACI-,+ACI-sans-serif+ACIAOwB9- span.EmailStyle22 +AHs-mso-style-type:personal+ADs- font-family:+ACI-Calibri+ACI-,+ACI-sans-serif+ACIAOw- color:windowtext+ADsAfQ- span.EmailStyle23 +AHs-mso-style-type:personal+ADs- font-family:+ACI-Calibri+ACI-,+ACI-sans-serif+ACIAOw- color:+ACM-1F497D+ADsAfQ- span.Char0 +AHs-mso-style-name:+ACJieWzoaEZlh2cs- Char+ACIAOw- mso-style-priority:99+ADs- mso-style-link:+Ynls6GhGZYdnLAA7- font-family:+ACI-Calibri+ACI-,+ACI-sans-serif+ACIAOwB9- span.EmailStyle26 +AHs-mso-style-type:personal-reply+ADs- font-family:+ACI-Calibri+ACI-,+ACI-sans-serif+ACIAOw- color:+ACM-1F497D+ADsAfQ- .MsoChpDefault +AHs-mso-style-type:export-only+ADs- font-size:10.0pt+ADsAfQ- +AEA-page WordSection1 +AHs-size:612.0pt 792.0pt+ADs- margin:72.0pt 72.0pt 72.0pt 72.0pt+ADsAfQ- div.WordSection1 +AHs-page:WordSection1+ADsAfQ- /+ACo- List Definitions +ACo-/ +AEA-list l0 +AHs-mso-list-id:11424535+ADs- mso-list-type:hybrid+ADs- mso-list-template-ids:827492486 67698705 67698713 67698715 67698703 676987= 13 67698715 67698703 67698713 67698715+ADsAfQ- +AEA-list l0:level1 +AHs-mso-level-text:+ACIAJQ-1+AFw-)+ACIAOw- mso-level-tab-stop:none+ADs- mso-level-number-position:left+ADs- text-indent:-18.0pt+ADsAfQ- +AEA-list l0:level2 +AHs-mso-level-number-format:alpha-lower+ADs- mso-level-tab-stop:none+ADs- mso-level-number-position:left+ADs- text-indent:-18.0pt+ADsAfQ- +AEA-list l0:level3 +AHs-mso-level-number-format:roman-lower+ADs- mso-level-tab-stop:none+ADs- mso-level-number-position:right+ADs- text-indent:-9.0pt+ADsAfQ- +AEA-list l0:level4 +AHs-mso-level-tab-stop:none+ADs- mso-level-number-position:left+ADs- text-indent:-18.0pt+ADsAfQ- +AEA-list l0:level5 +AHs-mso-level-number-format:alpha-lower+ADs- mso-level-tab-stop:none+ADs- mso-level-number-position:left+ADs- text-indent:-18.0pt+ADsAfQ- +AEA-list l0:level6 +AHs-mso-level-number-format:roman-lower+ADs- mso-level-tab-stop:none+ADs- mso-level-number-position:right+ADs- text-indent:-9.0pt+ADsAfQ- +AEA-list l0:level7 +AHs-mso-level-tab-stop:none+ADs- mso-level-number-position:left+ADs- text-indent:-18.0pt+ADsAfQ- +AEA-list l0:level8 +AHs-mso-level-number-format:alpha-lower+ADs- mso-level-tab-stop:none+ADs- mso-level-number-position:left+ADs- text-indent:-18.0pt+ADsAfQ- +AEA-list l0:level9 +AHs-mso-level-number-format:roman-lower+ADs- mso-level-tab-stop:none+ADs- mso-level-number-position:right+ADs- text-indent:-9.0pt+ADsAfQ- ol +AHs-margin-bottom:0cm+ADsAfQ- ul +AHs-margin-bottom:0cm+ADsAfQ- --+AD4- +ADw-/style+AD4APAAh---+AFs-if gte mso 9+AF0APgA8-xml+AD4- +ADw-o:shapedefaults v:ext+AD0AIg-edit+ACI- spidmax+AD0AIg-1026+ACI- /+AD4= - +ADw-/xml+AD4APAAhAFs-endif+AF0---+AD4APAAh---+AFs-if gte mso 9+AF0APgA8-xm= l+AD4- +ADw-o:shapelayout v:ext+AD0AIg-edit+ACIAPg- +ADw-o:idmap v:ext+AD0AIg-edit+ACI- data+AD0AIg-1+ACI- /+AD4- +ADw-/o:shapelayout+AD4APA-/xml+AD4APAAhAFs-endif+AF0---+AD4- +ADw-/head+AD4- +ADw-body lang+AD0AIg-ZH-CN+ACI- link+AD0AIg-blue+ACI- vlink+AD0AIg-purple+= ACIAPg- +ADw-div class+AD0AIg-WordSection1+ACIAPg- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPg-Hi Steve,+ADw-o:p+AD4APA= -/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA= -/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPg-Thank a lot for your rev= iew. +ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPg-Please see my replies wi= th +AFs-JY+AF0-.+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA= -/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPg-Kind regards,+ADw-o:p+AD= 4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPg-Yuanlong+ADw-o:p+AD4APA-= /o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA= -/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA= -/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-div+AD4- +ADw-div style+AD0AIg-border:none+ADs-border-top:solid +ACM-B5C4DF 1.0pt+AD= s-padding:3.0pt 0cm 0cm 0cm+ACIAPg- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-b+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.0pt+ADs-font-family: +ACY-quot+ADs-Tahoma+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAIg= A+-From:+ADw-/span+AD4APA-/b+AD4APA-span lang+AD0AIg-EN-US+ACI- style+AD0AI= g-font-size:10.0pt+ADs- font-family:+ACY-quot+ADs-Tahoma+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY= -quot+ADsAIgA+- Steve.Hanna+AEA-infineon.com +AFs-mailto:Steve.Hanna+AEA-in= fineon.com+AF0- +ADw-br+AD4- +ADw-b+AD4-Sent:+ADw-/b+AD4- Thursday, September 01, 2016 9:55 PM+ADw-br+AD= 4- +ADw-b+AD4-To:+ADw-/b+AD4- iesg+AEA-ietf.org+ADs- secdir+AEA-ietf.org+ADs- = draft-ietf-pals-mc-pon+AEA-ietf.org+ADw-br+AD4- +ADw-b+AD4-Subject:+ADw-/b+AD4- RE: secdir review of draft-ietf-pals-mc-pon= -04+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-/div+AD4- +ADw-/div+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-o:p+= AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-color:+ACM-1F497D+ACIAPg-Resending with correct draft alias.+ADw-o:p+A= D4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD= 4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-color:+ACM-1F497D+ACIAPg-Steve+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA= -/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD= 4APA-/p+AD4- +ADw-div+AD4- +ADw-div style+AD0AIg-border:none+ADs-border-top:solid +ACM-B5C4DF 1.0pt+AD= s-padding:3.0pt 0cm 0cm 0cm+ACIAPg- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-b+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.0pt+ADs-font-family: +ACY-quot+ADs-Tahoma+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAIg= A+-From:+ADw-/span+AD4APA-/b+AD4APA-span lang+AD0AIg-EN-US+ACI- style+AD0AI= g-font-size:10.0pt+ADs- font-family:+ACY-quot+ADs-Tahoma+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY= -quot+ADsAIgA+- Hanna Steve (IFAM CCS SMD AMR) +ADw-br+AD4- +ADw-b+AD4-Sent:+ADw-/b+AD4- Thursday, September 01, 2016 7:57 AM+ADw-br+AD= 4- +ADw-b+AD4-To:+ADw-/b+AD4- 'iesg+AEA-ietf.org'+ADs- 'secdir+AEA-ietf.org'+A= Ds- 'draft-ietf-pals-mc-pon-04.all+AEA-ietf.org'+ADw-br+AD4- +ADw-b+AD4-Subject:+ADw-/b+AD4- secdir review of draft-ietf-pals-mc-pon-04+= ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-/div+AD4- +ADw-/div+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-o:p+= AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPg-I h= ave reviewed this document as part of the security directorate's ongoing ef= fort to review all IETF documents being processed by the IESG.+ACY-nbsp+ADs= - These comments were written primarily for the benefit of the security are= a directors.+ACY-nbsp+ADs- Document editors and WG chairs should treat these= comments just like any other last call comments.+ADw-o:p+AD4APA-/o:p+AD4AP= A-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-o= :p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPg-Sum= mary: Ready with issues+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-o= :p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPg-The= security considerations section of this document seems reasonable and corr= ect. However, I+IBk-m concerned that bringing ICCP into the PON has some se= curity risks that have not been properly called out and mitigated. As the Security Considerations section says:+ADw-o:p+AD4APA-/o:p+AD4APA-/s= pan+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-o= :p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgAm-n= bsp+ADsAJg-nbsp+ADs- In many passive optical networks the optical paths bet= ween+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgAm-n= bsp+ADsAJg-nbsp+ADs- OLT and ONTs traverse publicly accessible facilities i= ncluding+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgAm-n= bsp+ADsAJg-nbsp+ADs- public attachments (e.g. telephone poles)+ADw-o:p+AD4A= PA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-o= :p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPg-Not= e that I+IBk-m pretty sure that ONT should be ONU here and in several other= places in the Security Considerations.+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD= 4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style= +AD0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPgBb-JY+AF0- ONT (Optica= l Network Terminal) is a similar term of ONU (Optical Network Unit), both o= f them are used widely and almost interchangeably in the PON network.+ADw-o= :p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style= +AD0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPg-But I agree with you = that we don+IBk-t need to introduce a new term in the +IBw-Security conside= rations+IB0- and we will use ONU consistently in the next revision.+ADw-o:p= +AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-o= :p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPg-My = concern is that section 4.2 says that +IBw-When a fault is detected on its = working PW (e.g., by VCCV BFD), a working OLT SHOULD turn off its associate= d PON interface and then send an ICCP message with PON State TLV with local PON Port State being set to notify the protection OLT of the PO= N fault.+IB0- Since the working PW has failed, the working OLT will presuma= bly send this ICCP message to the protection PW over the PON. That means th= at any other authorized or unauthorized party on the PON could also send such a message. I+IBk-m not very familiar= with ICCP but the Security Considerations section of RFC 7275 seems to say= that ICCP messages are frequently authenticated only by looking at the sou= rce IP address, which is an exceedingly weak method of authentication susceptible to easy forgery. Using MD5 (as p= ermitted by RFC 7275) isn+IBk-t much better. The impact of permitting attac= kers to easily forge ICCP messages on the PON is not clear to me but it see= ms that the attacker could at least prevent proper failover and maybe force failover or even force failure. Of= course, an attacker on the PON could also just jam the PON by setting thei= r laser always on but ICCP attacks would be much trickier to detect. I woul= d suggest that TCP-AO be required at least for ICCP messages sent or received on the PON.+ADw-o:p+AD4APA-/o:= p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style= +AD0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPgBb-JY+AF0- The assumpt= ion that +IBw-the working OLT will presumably send this ICCP message to the= protection PW over the PON+IB0- does not parse, do you mean +IBw-the worki= ng OLT will presumably send this ICCP message to the protection +ADw-span style+AD0AIg-background= :yellow+ADs-mso-highlight:yellow+ACIAPg- OLT+ADw-/span+AD4- over the PON+IB0-? But this case will never happen if th= e protection mechanism works as described in this document, since the Prote= ction trunk link will not be activated until the PON switching protection i= s finished (that is, after the Working trunk link is off and an ICCP message is received). +ACY-nbsp+ADs-Maybe the conf= usion is caused by a lack of interconnection between the OLTs in Figure 1. = But this document assumes that there is an ICCP interconnect between the OL= Ts. Please also be aware that Section 3.2 +IBw-ICCP Interconnect Scenarios+IB0- of RFC 7275 discusses the details of how to in= terconnect the PEs (i.e., the OLTs) in a redundancy group, thus all these I= CCP interconnect scenarios are applicable to draft-ietf-pals-mc-pon-04 too.= +ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style= +AD0AIg-color:+ACM-1F497D+ACIAPg-Furthermore, the ONUs are out of the MPLS = network domain where OLTs reside, LDP protocol (ICCP is one sub-type) sessi= on will not be established between any ONU and any OLT, therefore, ICCP att= ack from the PON side is not regarded as an issue. +ADw-o:p+AD4APA-/o:p+AD4APA= -/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style= +AD0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADs= APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPg-Two mi= nor typos:+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-o:p+= AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoListParagraph+ACI- style+AD0AIg-text-indent:-18.0pt+= ADs-mso-list:l0 level1 lfo2+ACIAPgA8ACEAWw-if +ACE-supportLists+AF0APgA8-sp= an lang+AD0AIg-EN-US+ACIAPgA8-span style+AD0AIg-mso-list:Ignore+ACIAPg-1)+A= Dw-span style+AD0AIg-font:7.0pt +ACY-quot+ADs-Times New Roman+ACY-quot+ADsA= IgA+ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +ADw-/span+AD4APA-/span+AD4APA-/span+AD4APAAhAFs-endif+AF0APgA8-span lang+A= D0AIg-EN-US+ACIAPg-In section 3, +IBw-protect OLTs+IB0- should be +IBw-prot= ection OLTs+IB0-.+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style= +AD0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADs= APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style= +AD0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPgBb-JY+AF0- Good catch.= We will update it.+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-o:p+= AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoListParagraph+ACI- style+AD0AIg-text-indent:-18.0pt+= ADs-mso-list:l0 level1 lfo2+ACIAPgA8ACEAWw-if +ACE-supportLists+AF0APgA8-sp= an lang+AD0AIg-EN-US+ACIAPgA8-span style+AD0AIg-mso-list:Ignore+ACIAPg-2)+A= Dw-span style+AD0AIg-font:7.0pt +ACY-quot+ADs-Times New Roman+ACY-quot+ADsA= IgA+ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +ADw-/span+AD4APA-/span+AD4APA-/span+AD4APAAhAFs-endif+AF0APgA8-span lang+A= D0AIg-EN-US+ACIAPg-In the Security Considerations, +IBw-ONT+IB0- should be = +IBw-ONU+IB0-. At least, I assume so. If not, ONT should be defined.+ADw-o:= p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoPlainText+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style= +AD0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPgBb-JY+AF0- Agreed.+ADw= -o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD= 4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA= -/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPg-Thanks= for your consideration,+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-o:p+= AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPg-Steve+= ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACIAPgA8-o:p+= AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-/div+AD4- +ADw-/body+AD4- +ADw-/html+AD4- --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B91732D86szxema506mbschi_-- From nobody Mon Sep 5 16:28:30 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E235F12B444; Mon, 5 Sep 2016 16:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nackFOqcH3r5; Mon, 5 Sep 2016 16:28:28 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B7712B012; Mon, 5 Sep 2016 16:28:28 -0700 (PDT) Received: from [192.168.114.1] (50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u85NSQX7094212 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Sep 2016 16:28:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230] claimed to be [192.168.114.1] From: "Paul Hoffman" To: secdir Date: Mon, 05 Sep 2016 16:28:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-taps-transports-usage.all@ietf.org Subject: [secdir] SecDir review of draft-ietf-taps-transports-usage X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 23:28:29 -0000 Greetings. draft-ietf-taps-transports-usage, "On the Usage of Transport Service Features Provided by IETF Transport Protocols" is an informational overview of how TCP, MCTCP, and SCTP interact with applications. It is strictly descriptive and doesn't define anything new. Because this is just describes existing protocols, there are no new security considerations. However, the current Security Considerations section says: Security will be considered in future versions of this document. It is not clear if the authors meant to have this be a null section, or whether they really intend to create a Security Considerations section that repeats or points to the security considerations for the three transports. I think the latter is better, given the lack of anything new in this document. Regardless, they need to fill this in before the SecDir review can be complete. --Paul Hoffman From nobody Tue Sep 6 00:53:21 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34E712B0C8; Tue, 6 Sep 2016 00:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.938 X-Spam-Level: X-Spam-Status: No, score=-4.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub89YSGxV5OE; Tue, 6 Sep 2016 00:53:17 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 975AE127A90; Tue, 6 Sep 2016 00:53:14 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bhBBw-0000Sc-7J; Tue, 06 Sep 2016 09:53:12 +0200 Received: from [62.217.47.18] (helo=[172.20.50.33]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bhBBv-0000i3-KX; Tue, 06 Sep 2016 09:53:12 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Tue, 6 Sep 2016 09:53:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5ECBD87E-92AA-42FA-B2D4-3067B2A1A2DB@ifi.uio.no> References: To: Paul Hoffman X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 7 sum msgs/h 4 total rcpts 45997 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 34A27AE1528863F61D987B911BAA23455110E11D X-UiO-SPAM-Test: remote_host: 62.217.47.18 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 33 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: draft-ietf-taps-transports-usage.all@ietf.org, secdir Subject: Re: [secdir] SecDir review of draft-ietf-taps-transports-usage X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 07:53:20 -0000 Hi, Thank you very much for this review; as an author, I=E2=80=99ll just say = =E2=80=9Cack=E2=80=9D. I agree with what you say. We=E2=80=99ll do our = best to do this ASAP. Cheers, Michael > On 6. sep. 2016, at 01.28, Paul Hoffman wrote: >=20 > Greetings. draft-ietf-taps-transports-usage, "On the Usage of = Transport Service Features Provided by IETF Transport Protocols" is an = informational overview of how TCP, MCTCP, and SCTP interact with = applications. It is strictly descriptive and doesn't define anything = new. >=20 > Because this is just describes existing protocols, there are no new = security considerations. However, the current Security Considerations = section says: > Security will be considered in future versions of this document. > It is not clear if the authors meant to have this be a null section, = or whether they really intend to create a Security Considerations = section that repeats or points to the security considerations for the = three transports. I think the latter is better, given the lack of = anything new in this document. Regardless, they need to fill this in = before the SecDir review can be complete. >=20 > --Paul Hoffman From nobody Thu Sep 8 02:05:34 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC01B12B3BD for ; Thu, 8 Sep 2016 02:05:32 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLnhrXgKCwke for ; Thu, 8 Sep 2016 02:05:29 -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 A04AE12B26F for ; Thu, 8 Sep 2016 02:05:28 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8895Nv5023998 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 8 Sep 2016 12:05:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8895Nvv027149; Thu, 8 Sep 2016 12:05:23 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22481.10706.702051.89714@fireball.acr.fi> Date: Thu, 8 Sep 2016 12:05:22 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 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, 08 Sep 2016 09:05:33 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Charlie Kaufman is next in the rotation. For telechat 2016-09-15 Reviewer LC end Draft Shaun Cooley T 2016-08-25 draft-ietf-hip-rfc5206-bis-12 Christian Huitema T 2016-09-06 draft-ietf-pce-pcep-service-aware-12 Leif Johansson T 2016-09-13 draft-ietf-mptcp-experience-06 For telechat 2016-09-29 Olafur Gudmundsson T 2016-08-25 draft-ietf-softwire-unified-cpe-05 Dan Harkins T 2016-09-21 draft-ietf-pals-rfc4447bis-05 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Paul Hoffman 2016-09-09 draft-ietf-taps-transports-11 Simon Josefsson 2016-09-22 draft-harkins-salted-eap-pwd-06 Benjamin Kaduk 2016-09-08 draft-ietf-tsvwg-diffserv-intercon-09 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-11 Sandy Murphy 2016-08-12 draft-ietf-tsvwg-gre-in-udp-encap-18 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-14 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-05 Tina TSOU 2016-08-15 draft-ietf-ospf-two-part-metric-09 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-09 Dacheng Zhang 2016-08-22 draft-ietf-core-http-mapping-13 -- kivinen@iki.fi From nobody Thu Sep 8 11:20:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EB412B258 for ; Thu, 8 Sep 2016 11:20:16 -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, RCVD_IN_SORBS_SPAM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJXDP3x8Jd3S for ; Thu, 8 Sep 2016 11:20:15 -0700 (PDT) Received: from xsmtp11.mail2web.com (xsmtp31.mail2web.com [168.144.250.234]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5719612B22A for ; Thu, 8 Sep 2016 11:20:15 -0700 (PDT) Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bi3vp-0002UX-3q for secdir@ietf.org; Thu, 08 Sep 2016 14:20:14 -0400 Received: (qmail 11409 invoked from network); 8 Sep 2016 18:20:12 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Sep 2016 18:20:11 -0000 From: "Christian Huitema" To: , , Date: Thu, 8 Sep 2016 11:20:09 -0700 Message-ID: <079401d209fd$a2e86200$e8b92600$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdIJ+Pl2g+g4ww7xQtWNGqZcoaLQqQ== Content-Language: en-us Archived-At: Subject: [secdir] SecDir review of draft-ietf-pce-pcep-service-aware-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 18:20:17 -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 is ready. The draft (draft-ietf-pce-pcep-service-aware-12), as the title indicates, describes "Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP)." The extensions include to the path metric object and to the bandwidth Utilization The enable computation of latency, delay variation, packet loss and bandwidth utilization constraints for a path, and the selection of paths accordingly. The draft defines code points for various types of computations, as well as new error types. The security section states that these extensions do "not add any new security concerns beyond those discussed in [RFC5440] and [RFC5541] in itself." That's a true statement. This draft does not change the problem much, except for the addition of more and more potentially sensitive data in the routing messages. We could have a long and heated discussion on the appropriateness of the mitigations described in the security sections of these [RFC5440] and [RFC5541], such as TCP MD5, an optional use of IPSEC and IKE, and some forms of access control. In fact, we could have that discussion for most routing related drafts. I am not suggesting that we have this discussion right now. -- Christian Huitema From nobody Sat Sep 10 16:47:10 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D1012B1B2; Sat, 10 Sep 2016 16:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 927lSfFwLX6B; Sat, 10 Sep 2016 16:47:08 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7B8126579; Sat, 10 Sep 2016 16:47:07 -0700 (PDT) Received: from [10.32.60.33] (50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u8ANl39k026584 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Sep 2016 16:47:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230] claimed to be [10.32.60.33] From: "Paul Hoffman" To: secdir Date: Sat, 10 Sep 2016 16:47:03 -0700 Message-ID: <26279EC7-C98E-4BED-8205-46C21D4DA370@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-taps-transports.all@ietf.org Subject: [secdir] Secdir review of draft-ietf-taps-transports-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2016 23:47:08 -0000 Greetings. draft-ietf-taps-transports, "Services provided by IETF transport protocols and congestion control mechanisms", is an informational overview of a large number of transport protocols. It does not change any of the protocols, just compares them. The Security Considerations section says "This document does not specify any new features or mechanisms for providing these features", which is appropriate and correct. In addition, Section 5, which collects some of the comparisons of features, lists security features and says which of the transport protocols support them. In that list, it says that replay protection is offered by FLUTE/ALC and DTLS, but does not list TLS. That seems like an oversight because DTLS and TLS offer similar replay semantics. (The rest of the list seems sensible.) --Paul Hoffman From nobody Sun Sep 11 10:48:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EC612B0B7; Sun, 11 Sep 2016 10:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPg-LJB1lPiE; Sun, 11 Sep 2016 10:48:37 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 1C46812B09A; Sun, 11 Sep 2016 10:48:36 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id m11so261604635oif.1; Sun, 11 Sep 2016 10:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BLPFONIpXFg9j7du5W+2T2f+ck/RMz7mHil/+MaDwZg=; b=vkkOiEEbV2V6q0tT9WbjUr+bNWUGHLm80z2G51IMx231z5JccUYXKggPk9X5hy6dbA 0G2CAaSgh0qOAMUQYALkTskdiRzpMQWpRtxVu7PfsAEpHtUuhnnmLO5ggfRmHPV9iquv LSYdkk0EQLHRkOJdM7UtNTreP8gUS4ttKJCZ8KGiLvFUX3naakwsGcsCroxCANoDELVl GL3bngTZYfeIPg1q8UR8O9wynnJ43lpfd/Z8ptfglQGSdT3EdpVBtJ7rhPHgItGGo8m8 JgNUFM2RpNQAimurMcuYSR4tGqt3bgWw00fvPKjfcszf6YrXraoeTGEObxsAtroZ005w Htng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BLPFONIpXFg9j7du5W+2T2f+ck/RMz7mHil/+MaDwZg=; b=Zgow4spYOx1Fm+HEQKtU9pvVPXPBKpADl0GuBth6ZdOD95Bg6CSofEjlOu/N9WwA6o c74W7heEz88lWBSIXAsEVjbs657i5Sp610KVzcnBO1TuvOmpxyEFxfBOUsg3YZA2f6Bk i5pyGOhAr0gj5Q1Mu9SW+owYwT8CYi/taHlwIsA4U23DnrXkGtjIUGJEI/PwrOhetj2F o7jDMst/vBDIfCtRR6R/8QkWKkEZhrNXOJdMrw//Ed2SWrmn8Xk2bOkFam7qx4SXVGAf zSEsRJlQYvuc/f0uV8FczONLjMwz4Nf71LDtoNgbPwT+lsphsQg+QkMV+xEIIRM15I0d aqyQ== X-Gm-Message-State: AE9vXwPj2WfMIssh7ntGiMCOywo0vA66NEk9eOm0K+grJ9l5NN5IaABWChGl/il+udw9rHcptbzyBN13hPw2sA== X-Received: by 10.202.58.9 with SMTP id h9mr21530551oia.19.1473616116321; Sun, 11 Sep 2016 10:48:36 -0700 (PDT) MIME-Version: 1.0 Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.227.43 with HTTP; Sun, 11 Sep 2016 10:48:35 -0700 (PDT) In-Reply-To: <079401d209fd$a2e86200$e8b92600$@huitema.net> References: <079401d209fd$a2e86200$e8b92600$@huitema.net> From: Dhruv Dhody Date: Sun, 11 Sep 2016 23:18:35 +0530 X-Google-Sender-Auth: fE3zipgLyB-Z3JF_rlt73AG88yI Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a113cd1ee26172f053c3efd24 Archived-At: Cc: draft-ietf-pce-pcep-service-aware.all@ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-pce-pcep-service-aware-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2016 17:48:39 -0000 --001a113cd1ee26172f053c3efd24 Content-Type: text/plain; charset=UTF-8 Hi Christian, Thanks for your review. I concur with your message. I intend to make no change based on the sec dir review. Thanks! Dhruv On Thu, Sep 8, 2016 at 11:50 PM, Christian Huitema 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 is ready. > > The draft (draft-ietf-pce-pcep-service-aware-12), as the title indicates, > describes "Extensions to the Path Computation Element Communication > Protocol (PCEP) to compute service aware Label Switched Path (LSP)." > The extensions include to the path metric object and to the bandwidth > Utilization The enable computation of latency, delay variation, packet loss > and bandwidth utilization constraints for a path, and the selection of > paths accordingly. The draft defines code points for various types of > computations, as well as new error types. > > The security section states that these extensions do "not add any new > security concerns beyond those discussed in [RFC5440] and [RFC5541] > in itself." That's a true statement. This draft does not change the problem > much, except for the addition of more and more potentially sensitive data > in the routing messages. We could have a long and heated > discussion on the appropriateness of the mitigations described in the > security sections of these [RFC5440] and [RFC5541], such as TCP MD5, > an optional use of IPSEC and IKE, and some forms of access control. In > fact, > > we could have that discussion for most routing related drafts. I am not > suggesting that we have this discussion right now. > > -- Christian Huitema > > > --001a113cd1ee26172f053c3efd24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christian,

T= hanks for your review. I concur with=C2=A0your message. I intend to make no= change based on the=C2=A0sec dir review.=C2=A0

Thanks!=C2=A0
Dhruv

On Thu, Sep 8, 2016 at 11:50 PM, Christia= n Huitema <huitema@huitema.net> wrote:
I have reviewed this document as part of the security direct= orate's
ongoing effort to review all IETF documents being processed by the
IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

This draft is ready.

The draft (draft-ietf-pce-pcep-service-aware-12), as the title indicat= es,
describes "Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP)." The extensions include to the path metric object and to the bandwidth
Utilization The enable computation of latency, delay variation, packet loss=
and bandwidth utilization constraints for a path, and the selection of
paths accordingly. The draft defines code points for various types of
computations, as well as new error types.

The security section states that these extensions do "not add any new<= br> security concerns beyond those discussed in [RFC5440] and [RFC5541]
in itself." That's a true statement. This draft does not change th= e problem
much, except for the addition of more and more potentially sensitive data in the routing messages. We could have a long and heated
discussion on the appropriateness of the mitigations described in the
security sections of these [RFC5440] and [RFC5541], such as TCP MD5,
an optional use of IPSEC and IKE, and some forms of access control. In fact= ,

we could have that discussion for most routing related drafts. I am not
suggesting that we have this discussion right now.

-- Christian Huitema



--001a113cd1ee26172f053c3efd24-- From nobody Tue Sep 13 06:33:30 2016 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 B30A612B410; Tue, 13 Sep 2016 06:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1473772966; bh=MwuKqxBXiFgwsCrE6LJ0/UYt4s20FrMIUQ5H6u1tYNw=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=EhCFVjjobFitKeGAve0S8Rg8Mh6ndMZYWl7C4U50HiqndrGlWS80HIf0hDBGIxUuB Q4xCkHa44cqCnWwcq5to3YvLUjn2sHFdclTdMjqxjwG5q2egNv7YgFinpsZPzrCKJH VgusEvXmxc2Fc9PLFXc0XhAM5AjmGgaDY6yGHwq4= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F04612B56C for ; Tue, 13 Sep 2016 06:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT0K93wFQTpd for ; Tue, 13 Sep 2016 06:22:39 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3293912B410 for ; Tue, 13 Sep 2016 06:14:37 -0700 (PDT) Received: from [2001:da8:203:80:d87f:f392:aabf:5b31] by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1bjnXn-000CCa-EJ for new-work@ietf.org; Tue, 13 Sep 2016 13:14:35 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: Date: Tue, 13 Sep 2016 21:14:56 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 13 Sep 2016 06:33:29 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web of Things Working Group (until 2016-10-14) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 13:22:47 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Web of Things Working Group: https://www.w3.org/2016/09/wot-wg-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2016-10-14 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Kazuyuki Ashimura, W3C Staff Contact . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Tue Sep 13 20:55:30 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D37612B19A; Tue, 13 Sep 2016 20:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpK7uYMZ3mhH; Tue, 13 Sep 2016 20:55:23 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 77D0312B1AF; Tue, 13 Sep 2016 20:55:22 -0700 (PDT) X-AuditID: 1209190f-58fff70000006995-9c-57d8ca29bd7d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 57.67.27029.92AC8D75; Tue, 13 Sep 2016 23:55:21 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u8E3tKda010075; Tue, 13 Sep 2016 23:55:21 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u8E3tHA2021260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2016 23:55:20 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8E3tHaT014301; Tue, 13 Sep 2016 23:55:17 -0400 (EDT) Date: Tue, 13 Sep 2016 23:55:17 -0400 (EDT) From: Benjamin Kaduk To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tsvwg-diffserv-intercon@MIT.EDU Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUixCmqrKt56ka4wbJpKhYz/kxktviw8CGL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgy7rRuYStYIVdx6u16xgbGmxJdjJwcEgImEhfuvWbr YuTiEBJoY5L40X+GFcLZyCix9uEMKOcQk8ST9sfMEE4Do8S9qV+YQfpZBLQldjW3s4HYbAIq EjPfbASzRQT8JGZf+w9WIyxgL/G3ZzlYnFfAQaL5yVZGEFtUQEdi9f4pLBBxQYmTM5+A2cwC WhLLp29jmcDIOwtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6Jnq5mSV6qSmlmxjB ISTJv4NxToP3IUYBDkYlHt6AH9fDhVgTy4orcw8xSnIwKYny9vrfCBfiS8pPqcxILM6ILyrN SS0+xCjBwawkwit/CCjHm5JYWZValA+TkuZgURLn7ZpxIFxIID2xJDU7NbUgtQgmK8PBoSTB K38SqFGwKDU9tSItM6cEIc3EwQkynAdoOD9IDW9xQWJucWY6RP4Uo6KUOG84SEIAJJFRmgfX C47x3UyqrxjFgV4R5hUGqeIBpge47ldAg5mABm9Zcx1kcEkiQkqqgbGsYobvzYeVEfbym1OW dzP6Oqzcn1t5/77nr80367mlbkxddaL9stzNvg7FXbaqW0xSFr6ZwDKRifP5l2PPTJ7NnK5z 3znCfmnNh5pde/6qy2xsP2yxvvLUz02bIr/cXff4q9/2v0mzdjy3dl5T27Ij+EPR8ic/Kw6b WYq+YLJ6GMa5ksVdZcEOJZbijERDLeai4kQA056SS8wCAAA= Archived-At: Subject: [secdir] secdir review of draft-ietf-tsvwg-diffserv-intercon-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 03:55:25 -0000 Hi 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. This draft is Ready. I had to do some background reading (RFC 2475, mostly, and skimming some other references) to really understand what's going on here; I'll probably use some wrong terminology as a result. This draft describes a standard set of 4 Treatment Aggregates that can be used by MPLS networks using the Short-Pipe tunnel mode to preserve IP Differentiated Service code point markings and the corresponding per-hop behaviors as traffic traverses the network boundary. DSCP translation is expected to be done both at entry and exit from the network (as applicable; not all traffic is through traffic, of course) betwen the standard DSCPs and network-internal DSCPs used to apply PHBs, but the benfit of this scheme is the standardized interface, much as how it is easier for a user to accept a two-clause BSD software license that is well-known than it is for that user to accept a software EULA that was custom written by a company's lawyers. Otherwise, everything described in this document could be done already by two peered networks that negotiate an SLA. With this document, they still must negotiate an SLA, but there are standard terms to simplify the process. The security considerations accordingly note (correctly) that this document does not introduce new features; rather, it describes how to use existing ones. It refers to the security considerations in RFCs 2475 and 4594, which seem to be complete, noting that differentiated services introduce the possibility of fasely marked/prioritized traffic and the potential for denial of service. Only calling out IPsec as the example is a bit dated, but the general principles still seem fine -- the physical network has to be protected and traffic sanitized on entry. However, I do think it's worth giving a little bit of new thought to the potential privacy considerations -- a new way of marking traffic, in abstract, has the potential to leak classification information about the traffic in question (e.g., is this IP address doing telephony?). That said, the classification added by this document is something that could be done by any party with access to the raw network traffic, so I don't think there are actually any new considerations in play; it's just something to keep in mind. A few editorial comments follow: Please expand PHBs in the abstract, not just in the introduction Introduction, first paragraph, space between ')' and 'and'. Just a few words later, is it clearer to s/at/for use at/? Top of page 3, last sentence of first paragraph ("This draft assumes that latter approach by defining additional DSCPs that are known and expected at network interconnection interfaces.") -- I think maybe "subsumes" is a better verb than "assumes", as it is true that unknown/unexpected DSCPs are remarked to zero, but there is additional functionality in the known/expected DSCPs that are preserved. Across the page 3/page 4 boundary, the part after the semicolon is a sentence fragment ... I can't even tell what it's trying to say. Maybe, "remarking to zero is performed in the absence of [...]" (but put a comma before "for"). Section 1.1, first paragraph, is this work really intended to *complement* RFC 5160? It seems to me that rather it is building upon 5160, or implementing its suggestions, or something like that. Section 4, Telephony Service Treatment Aggregate, it looks like the convention would have the DSCP be formatted as "101 100" with a space. -Ben From nobody Tue Sep 13 21:00:57 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75AF12B19A; Tue, 13 Sep 2016 21:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lKhbhW1LBmD; Tue, 13 Sep 2016 21:00:54 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 A94BB12B1B1; Tue, 13 Sep 2016 21:00:50 -0700 (PDT) X-AuditID: 1209190d-ec7ff700000035fe-12-57d8cb7156cb Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 94.19.13822.17BC8D75; Wed, 14 Sep 2016 00:00:49 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u8E40mNT010535; Wed, 14 Sep 2016 00:00:49 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u8E40jpC022606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Sep 2016 00:00:48 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8E40jS3014989; Wed, 14 Sep 2016 00:00:45 -0400 (EDT) Date: Wed, 14 Sep 2016 00:00:44 -0400 (EDT) From: Benjamin Kaduk To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tsvwg-diffserv-intercon@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUixCmqrFt4+ka4wdp3yhZP1v1gs5jxZyKz xYeFD1kcmD2WLPnJFMAYxWWTkpqTWZZapG+XwJXR0biQteCtXMXOdwdZGxgnSXYxcnJICJhI LLiznr2LkYtDSKCNSWLp435GCGcjo0T73mVQmUNMEjd6P7BBOA2MEo/unGQF6WcR0JZoe7IP zGYTUJGY+WYjG4gtIhAhsXZiH1hcWMBe4m/PcrA4r4CDxKMVG5lBbFEBHYnV+6ewQMQFJU7O fAJmMwtoSSyfvo1lAiPvLCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuka6eVmluil ppRuYgQHkyTvDsZ/d70OMQpwMCrx8Ab8uB4uxJpYVlyZe4hRkoNJSZS31/9GuBBfUn5KZUZi cUZ8UWlOavEhRgkOZiUR3p8ngXK8KYmVValF+TApaQ4WJXHerhkHwoUE0hNLUrNTUwtSi2Cy MhwcShK8DaeAGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGHwQbXlyQmFucmQ6RP8WoKCXOGw6SEABJ ZJTmwfWCo303k+orRnGgV4R594Ks4AEmCrjuV0CDmYAGb1lzHWRwSSJCSqqBsTrhT1rqiTiz i8t33tIV3rhzBlt30W1HBTvuvMPP4st28nxuLufmrl44h9vS4nvfpsrtJdEGmbMjX55+F+jG v/msn8M+twKmifd/JfneneqsXqv48shlTWOPyZNn6L1599Js5QONcxdjOntv7+ieY32n/5ux 6ZuslIJWEfdrmwU1dkzaPJXtlhJLcUaioRZzUXEiAL+Ma/vRAgAA Archived-At: Subject: [secdir] secdir review of draft-ietf-tsvwg-diffserv-intercon-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 04:00:56 -0000 [re-sending with proper recipients list; sorry for the duplicate] Hi 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. This draft is Ready. I had to do some background reading (RFC 2475, mostly, and skimming some other references) to really understand what's going on here; I'll probably use some wrong terminology as a result. This draft describes a standard set of 4 Treatment Aggregates that can be used by MPLS networks using the Short-Pipe tunnel mode to preserve IP Differentiated Service code point markings and the corresponding per-hop behaviors as traffic traverses the network boundary. DSCP translation is expected to be done both at entry and exit from the network (as applicable; not all traffic is through traffic, of course) betwen the standard DSCPs and network-internal DSCPs used to apply PHBs, but the benfit of this scheme is the standardized interface, much as how it is easier for a user to accept a two-clause BSD software license that is well-known than it is for that user to accept a software EULA that was custom written by a company's lawyers. Otherwise, everything described in this document could be done already by two peered networks that negotiate an SLA. With this document, they still must negotiate an SLA, but there are standard terms to simplify the process. The security considerations accordingly note (correctly) that this document does not introduce new features; rather, it describes how to use existing ones. It refers to the security considerations in RFCs 2475 and 4594, which seem to be complete, noting that differentiated services introduce the possibility of fasely marked/prioritized traffic and the potential for denial of service. Only calling out IPsec as the example is a bit dated, but the general principles still seem fine -- the physical network has to be protected and traffic sanitized on entry. However, I do think it's worth giving a little bit of new thought to the potential privacy considerations -- a new way of marking traffic, in abstract, has the potential to leak classification information about the traffic in question (e.g., is this IP address doing telephony?). That said, the classification added by this document is something that could be done by any party with access to the raw network traffic, so I don't think there are actually any new considerations in play; it's just something to keep in mind. A few editorial comments follow: Please expand PHBs in the abstract, not just in the introduction Introduction, first paragraph, space between ')' and 'and'. Just a few words later, is it clearer to s/at/for use at/? Top of page 3, last sentence of first paragraph ("This draft assumes that latter approach by defining additional DSCPs that are known and expected at network interconnection interfaces.") -- I think maybe "subsumes" is a better verb than "assumes", as it is true that unknown/unexpected DSCPs are remarked to zero, but there is additional functionality in the known/expected DSCPs that are preserved. Across the page 3/page 4 boundary, the part after the semicolon is a sentence fragment ... I can't even tell what it's trying to say. Maybe, "remarking to zero is performed in the absence of [...]" (but put a comma before "for"). Section 1.1, first paragraph, is this work really intended to *complement* RFC 5160? It seems to me that rather it is building upon 5160, or implementing its suggestions, or something like that. Section 4, Telephony Service Treatment Aggregate, it looks like the convention would have the DSCP be formatted as "101 100" with a space. -Ben From nobody Thu Sep 15 04:48:30 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA1912B258 for ; Thu, 15 Sep 2016 04:48:28 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgYyz8xzW6Pz for ; Thu, 15 Sep 2016 04:48:27 -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 35D8312B03F for ; Thu, 15 Sep 2016 04:48:27 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8FBmP1M016258 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 15 Sep 2016 14:48:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8FBmPXO010148; Thu, 15 Sep 2016 14:48:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22490.35465.222.262058@fireball.acr.fi> Date: Thu, 15 Sep 2016 14:48:25 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 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, 15 Sep 2016 11:48:29 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Matt Lepinski is next in the rotation. For telechat 2016-09-15 Reviewer LC end Draft Shaun Cooley T 2016-08-25 draft-ietf-hip-rfc5206-bis-12 Leif Johansson T 2016-09-13 draft-ietf-mptcp-experience-06 For telechat 2016-09-29 Olafur Gudmundsson T 2016-08-25 draft-ietf-softwire-unified-cpe-06 Dan Harkins T 2016-09-21 draft-ietf-pals-rfc4447bis-05 Charlie Kaufman T 2016-09-27 draft-ietf-6lo-paging-dispatch-04 Stephen Kent T 2016-09-28 draft-ietf-cose-msg-18 Warren Kumari T 2016-09-28 draft-ietf-ipsecme-ddos-protection-09 Watson Ladd T 2016-09-28 draft-ietf-tictoc-multi-path-synchronization-05 Sandy Murphy T 2016-08-12 draft-ietf-tsvwg-gre-in-udp-encap-18 Radia Perlman TR2016-08-15 draft-ietf-i2rs-protocol-security-requirements-10 Carl Wallace TR2016-08-11 draft-ietf-radext-ip-port-radius-ext-11 Dacheng Zhang T 2016-08-22 draft-ietf-core-http-mapping-14 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Simon Josefsson 2016-09-22 draft-harkins-salted-eap-pwd-06 Scott Kelly 2016-09-22 draft-ietf-avtcore-5761-update-01 Tero Kivinen 2016-09-28 draft-ietf-ippm-6man-pdm-option-05 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-11 Ben Laurie 2016-10-10 draft-levine-herkula-oneclick-04 Barry Leiba 2016-10-10 draft-murchison-nntp-compress-05 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-14 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-05 Tina TSOU 2016-08-15 draft-ietf-ospf-two-part-metric-09 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-09 -- kivinen@iki.fi From nobody Thu Sep 15 07:29:38 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387F712B54F; Thu, 15 Sep 2016 07:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmwdTggFFlJB; Thu, 15 Sep 2016 07:29:32 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 EE0EA12B899; Thu, 15 Sep 2016 06:43:23 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id m11so69369417oif.1; Thu, 15 Sep 2016 06:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=mv7ZLuhf7nBWK7zZqY88SJG8O8Q1sr2yotAeVf5Hw7w=; b=EFppS9yFovw3TQRMtYDweUHbfK9UEKryZPt8RkYV41qe7jWyyypGQ22nI3vRil3pQ9 PUnw+Ed9PSxt7IWvikDGgZtt18O4xJCFcMWPJeX2RjDkL2pTRXT05vWGCeVaRs9J7Bjh A21912rx3h2HZX7buozQkK7fBy4dU+64Z44mA6Wvhg13otadmEsxtsWz1H+qhle/aYE9 OONHDG7i4RzRE+1SDKa5MhYGbmSW97zW2yTzoew4FJUGdlyd0TgFC22LAoYPlJaCJ5dV r4isO+Da90XJ9kC0gOishJ+ba6BBf6S+uT5UcqVbnSWiRBEslPZI9F9EJhO8OZHRiYuj G5pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mv7ZLuhf7nBWK7zZqY88SJG8O8Q1sr2yotAeVf5Hw7w=; b=COHowaCTV5JuY3GAHhCdGCBzshd9KbMKnHunU/Eq5wFFIEH3wvh2WRpfY/36kwFYTp ck++IW1z4paeMkP6YbZGaIGZBWGWNUKBbINuPnInHAs/QU1X5gXmdNTIoWKLY6nrgHFB 2N1MhnNQwW9sbG9/hxIZrtx/q1gC8vzE8bzkI2zsrJ+UTNolqY4c0sdt28SwDgidlVp5 TQ1lH2D5PTBh7JFpcnvS//QKMofDn+PQloBTVtWdSP+etkzAetXF6M2pcXx6cNRZwWyB CqhbYk9M0Ee+33SCpZzRqv7ZKNuUNsC9im9jOmFdcainlK6ooeAuhn4DG+sog96sgycs 0ZlQ== X-Gm-Message-State: AE9vXwNBA7QxHW3kLe+BEJQWP19o38AM1ra02D//sm/Unj6icVG0sC/QHfYboq2k5wL+LJz8rX40y5V2ckQeXA== X-Received: by 10.202.190.85 with SMTP id o82mr7846996oif.72.1473947003313; Thu, 15 Sep 2016 06:43:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.120.201 with HTTP; Thu, 15 Sep 2016 06:43:22 -0700 (PDT) From: Radia Perlman Date: Thu, 15 Sep 2016 09:43:22 -0400 Message-ID: To: "secdir@ietf.org" , The IESG , draft-ietf-i2rs-protocol-security-requirements.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a113d67588d1042053c8c07c0 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-i2rs-protocol-security-requirements-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 14:29:37 -0000 --001a113d67588d1042053c8c07c0 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. I previously reviewed version 6, and they addressed my concerns, so I don't have too much to say, but here are some comments that are just editorial, and so fine to ignore. --------- Section 3.2 is called "New Security Features", though I'm not sure all the features specified in the section are really secure features, such as priority. Or "an insecure protocol for read-only data constrained to specific standard usages". Is that a security feature? Perhaps "New features related to security" ------------ In section 4.6 " The I2RS Architecture [RFC7921] defines a role or security role as specifying read, write, or notification access by a I2RS client to data within an agent's data model." I'm not sure I'd say that the definition of a role is "specifying type of access". Perhaps a definition of a role might be "a method of making access control more manageable by creating a grouping of users, so that the access controls can be specified for the role rather than for each of the individuals." Though perhaps it's the word "defines" that's troubling me, and instead it could be "RFC7921 specifies access control for a group as being read, write, or notification...." Radia --001a113d67588d1042053c8c07c0 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 effort to review all IETF docume= nts 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 just like any other last call co= mments.


= I previously reviewed version 6, and they addressed my concerns, so I don&#= 39;t have too much to say, but here are some comments that are just editori= al, and so fine to ignore.


---------


Section 3.2 is called "New Security Features&quo= t;, though I'm not sure all the features specified in the section are r= eally secure features, such as priority. =C2=A0 Or "an insecure pr= otocol for read-only data constrained to specific standard usages". = Is that a security feature? Perhaps "New features related to securit= y"


<= /p>

------------


In section 4.6 " The I2RS Architecture [R= FC7921] defines a role or security role as specifying read, write, or not= ification access by a I2RS client to data within an agent's data mode= l."


=

I'm not sure I'd s= ay that the definition of a role is "specifying type of access". = Perhaps a definition of a role might be "a method of making access con= trol more manageable by creating a grouping of users, so that the access co= ntrols can be specified for the role rather than for each of the individual= s." Though perhaps it's the word "defines" that's t= roubling me, and instead it could be "RFC7921 specifies access control= for a group as being read, write, or notification...."


Radia


<= /p>

=C2=A0

--001a113d67588d1042053c8c07c0-- From nobody Thu Sep 15 11:02:24 2016 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 933F612B2D1; Thu, 15 Sep 2016 11:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1473962421; bh=M4bn3Zevjojyf7WhCh7+IqvcyafxrfTuqX3LdytERgs=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=V6wqrDguj8VSvGfHDjP5iJ0sWP+SkBasb3U9yXX7PwtLZ8awejcPG7/Tk1ft6/t74 PybphAlgVABUzlMVpBZ9CcWImBmziFZAgim/Ea/mfXHVf4SOJgQ/fV7+RfMU6glKqO jxkh4sfMg6hS7+z7C9IT0DQsrkoks+g7SzlAyxVE= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC27112B27C for ; Thu, 15 Sep 2016 11:00:14 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <147396241476.26958.6057014111852501032.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2016 11:00:14 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Content-Type: multipart/mixed; boundary="===============8037390384808192771==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 15 Sep 2016 11:02:23 -0700 Subject: [secdir] [new-work] WG Review: QUIC (quic) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 18:00:22 -0000 --===============8037390384808192771== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit A new IETF WG has been proposed in the Transport Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-09-25. QUIC (quic) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Spencer Dawkins Transport Area Directors: Spencer Dawkins Mirja Kühlewind Mailing list: Address: quic@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/quic Archive: https://mailarchive.ietf.org/arch/browse/quic/ Charter: https://datatracker.ietf.org/doc/charter-ietf-quic/ The QUIC working group will provide a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol, based on pre-standardization implementation and deployment experience, and generalizing the design described in draft-hamilton-quic-transport-protocol, draft-iyengar-quic-loss-recovery, draft-shade-quic-http2-mapping, and draft-thomson-quic-tls. Key goals for QUIC are: - Minimizing connection establishment and overall transport latency for applications, starting with HTTP/2; - Providing multiplexing without head-of-line blocking; - Requiring only changes to path endpoints to enable deployment; - Enabling multipath and forward error correction extensions; and - Providing always-secure transport, using TLS 1.3 by default. The work of the group will have five main focus areas, corresponding to five core deliverables. The first of these is the core transport work, which will describe the wire format, along with the mechanisms for connection establishment, stream multiplexing, data reliability, loss detection and recovery, congestion control, version negotiation, and options negotiation. Work on congestion control will describe use of a standardized congestion controller as a default scheme for QUIC. Defining new congestion control schemes is explicitly out of scope for this group. QUIC is expected to support rapid, distributed development and testing of features. The second of these focus areas is security. This work will describe how the protocol uses TLS 1.3 for key negotiation and will also describe how those keys are used to provide confidentiality and integrity protection of both application data and QUIC headers. This work will ensure that QUIC has security and privacy properties that are at least as good as a stack composed of TLS 1.3 using TCP (or MPTCP when using multipath). The third focus area will describe mappings between specific application protocols and the transport facilities of QUIC. The first mapping will be a description of HTTP/2 semantics using QUIC, specifically with the goal of minimizing web latency using QUIC. This mapping will accommodate the extension mechanisms defined in the HTTP/2 specification. Upon completion of that mapping, additional protocols may be added by updating this charter to include them. The fourth focus area will extend core protocol facilities to enable multipath capabilities for connection migration between paths and load sharing across multiple paths. The fifth focus area will provide an Applicability and Manageability Statement, describing how, and under what circumstances, QUIC may be safely used, and describing deployment and manageability implications of the protocol. Current practices for network management of transport protocols include the ability to apply access control lists (ACLs), hashing of flows for equal-cost multipath routing (ECMP), directional signaling of flows, signaling of flow setup and teardown, and the ability to export information about flows for accounting purposes. The QUIC protocol need not be defined to enable each of these abilities, or enable them in the same way as they are enabled by TCP when used with TLS 1.3, but the working group must consider the impact of the protocol on network management practices, in line with RFC 7258. Extensions that will support partial reliability, and negotiation and use of Forward Error Correction schemes, are out of scope in this version of the working group charter. Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified. The QUIC working group will work closely with the HTTPbis working group, especially on the QUIC mapping for HTTP/2. In order to achieve the milestones set out below, the group expects to make extensive use of interim meetings, especially in its first year. Milestones: Feb 2017 - Working group adoption of Core Protocol document Feb 2017 - Working group adoption of Loss detection and Congestion Control document Feb 2017 - Working group adoption of TLS 1.3 mapping document Feb 2017 - Working group adoption of HTTP/2 mapping document Feb 2017 - Working group adoption of QUIC Applicability and Manageability Statement Nov 2017 - Working group adoption of Multipath extension document Mar 2018 - Core Protocol document to IESG Mar 2018 - Loss detection and Congestion Control document to IESG Mar 2018 - TLS 1.3 Mapping document to IESG Nov 2018 - HTTP/2 mapping document to IESG Nov 2018 - QUIC Applicability and Manageability Statement to IESG May 2019 - Multipath extension document to IESG --===============8037390384808192771== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============8037390384808192771==-- From nobody Sat Sep 17 15:15:45 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5EB12B181 for ; Sat, 17 Sep 2016 15:15: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=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SERBoy9DhlC7 for ; Sat, 17 Sep 2016 15:15:38 -0700 (PDT) Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C6512B023 for ; Sat, 17 Sep 2016 15:15:37 -0700 (PDT) Received: from smtp21.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 176D340178; Sat, 17 Sep 2016 18:15:29 -0400 (EDT) X-Auth-ID: ogud@ogud.com Received: by smtp21.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 02BB6400C4; Sat, 17 Sep 2016 18:15:27 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-71-191-33-181.washdc.fios.verizon.net [71.191.33.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Sat, 17 Sep 2016 18:15:29 -0400 From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_1F5A08B1-D790-4DEC-9A7C-F73F8922F0E1" Date: Sat, 17 Sep 2016 18:15:27 -0400 Message-Id: <2CB5D784-5EE9-4AC9-A3D5-31A3DEBC899C@ogud.com> To: draft-ietf-softwire-unified-cpe.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: softwire@ietf.org, The IESG , secdir@ietf.org Subject: [secdir] SEC-DIR review of draft-ietf-softwire-unified-cpe-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2016 22:15:40 -0000 --Apple-Mail=_1F5A08B1-D790-4DEC-9A7C-F73F8922F0E1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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 is READY for publication. Olafur --Apple-Mail=_1F5A08B1-D790-4DEC-9A7C-F73F8922F0E1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii 
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 is READY  for publication.

Olafur

--Apple-Mail=_1F5A08B1-D790-4DEC-9A7C-F73F8922F0E1-- From nobody Sun Sep 18 09:07:25 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E97C12B125 for ; Sun, 18 Sep 2016 09:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.317 X-Spam-Level: X-Spam-Status: No, score=-4.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS74EqJsMYTn for ; Sun, 18 Sep 2016 09:07:22 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300A612B124 for ; Sun, 18 Sep 2016 09:07:22 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id d69so68776609ybf.2 for ; Sun, 18 Sep 2016 09:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=rJbNRffbDPpkUJwajpDO1oB+R2BJxt77OcdBnFDS5q8=; b=Y5PdNg/AI+Q13qx4oaqrJ/PHfbiste+ZE0DsxHIqkd7YaoHmwSuTNfiMPqHt7Pmh2o mfafUgZ6UrItJYm/uXEcSNxFjpPmCkT0IA/crEb3tZGKMl/R6k0GWgQleWb7wUoGPluv NLdKTFPL33yVtsiH9ZuoMgZwsRsZDNMpS1aJMKCVZfksU1NkTMIGhqufex9HrcW4NQIw 3gCkG8wRzzvl/Mw2GIBMPo8JLb55p2p2RJPBLda7EaBdJj+QSKX+aCtRivtQ0vF8yFiF IMG9mG0p3OhHrnq+aqUgfDnO3/Ax7uC3zLJtXbM92OEL5MZ3tdG/tgeAKdCQy+0ONlNO HGJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rJbNRffbDPpkUJwajpDO1oB+R2BJxt77OcdBnFDS5q8=; b=DW4Duq+tYqPEkHE2p+t7PzrFsrMZ1hvyhYC5e+ty3yjKtxjlski1ZsQhyQLglKSrW2 HUuI841ljXohXpBppXPaL0SkZMZ+A3iHJkNrliOdKF2CnyPqhfuA3+GDdr91ka8DDqSg qK+8sD3pUMiBW/nW7rk0zVS/GvBB0y1hq8vOIZkPqHFbQfswwTbNRrdM1HHE6d3xjIoh SKYbhwNAWgUHhhbLKE60u3froi1uYl8OQnUsJS2dqQn8iqlJF1gFLzd702jkWz5km5lG rvwZowCl5eihFJA2c6/VV58vC41NBr9ePChWnlVBG/n3KtDu+xzimTMMngyFSQ9HiS3t HB4g== X-Gm-Message-State: AE9vXwPCD4pvxbc5zc6RIaGmG9r+WcoNUQcysUkmg+CwBHceTkGXuzpMM+egNiEDGVyakRHGnhoU7VVaP4vjDrc+ X-Received: by 10.37.112.213 with SMTP id l204mr21914460ybc.124.1474214841203; Sun, 18 Sep 2016 09:07:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.148.11 with HTTP; Sun, 18 Sep 2016 09:07:20 -0700 (PDT) From: Ben Laurie Date: Sun, 18 Sep 2016 17:07:20 +0100 Message-ID: To: The IESG , "secdir@ietf.org" , draft-levine-herkula-oneclick.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Security review of draft-levine-herkula-oneclick-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2016 16:07:23 -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. Status: ready with issues. Broadly speaking, all seems fine with this draft, except the advice given for making the header non-forgeable is weak. "The URI and POST arguments SHOULD include a hard to forge component such as a hash in addition to or instead of the plain-text names of the list and the subscriber." Hashes are not inherently hard to forge, they need to be combined with a secret of some kind. Also, using a plain hash is error-prone. So better advice would be something along the lines of "The URI and POST arguments SHOULD include a hard to forge component such as an HMAC (RFC 2104) of the other components, using a secret key, in addition to or instead of the plain-text names of the list and the subscriber." Although its kinda obvious, you should probably also say that the server SHOULD verify this HMAC. Finally, since the URI argument is the subject of an existing RFC (2369) that RFC should probably be updated to include this advice. From nobody Sun Sep 18 09:18:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172AB12B12C for ; Sun, 18 Sep 2016 09:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CELUYiFYHpdr for ; Sun, 18 Sep 2016 09:18:39 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34FB2127A91 for ; Sun, 18 Sep 2016 09:18:39 -0700 (PDT) Received: (qmail 8090 invoked from network); 18 Sep 2016 16:18:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1f98.57debe5c.k1609; bh=MecP/Qdw9HfjvTw//wSYqCyJbXMI48pmMSajqtlmTCM=; b=jVEjMd/VAmuIQXIXpzLQNYOaliDPfcQVJ/fg0DI/QhURuPy4vHs+nQDUFRDKrFDul8wY3dMx5/0dDSSjCkVnzea1P7qrG+ys3hPtKlAYe4RKoQi1+XE2fkhz6wU2RotQtLEH6K2cTvk7QvcO7EdTOfhVeQ23CupjzA6/45yxPhug4UX0uzDFFI/E6g23mIYt4007o2LjFwxeoJDd58Gjq0IUR5ze2bEom9JB46xESywAFpsrtdo6xfg5GwUF8zYR Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 18 Sep 2016 16:18:36 -0000 Date: 18 Sep 2016 12:18:37 -0400 Message-ID: From: "John R. Levine" To: "Ben Laurie" In-Reply-To: References: User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: draft-levine-herkula-oneclick.all@ietf.org, Paul Kincaid-Smith , The IESG , "secdir@ietf.org" Subject: Re: [secdir] [taugh.com-standards] Security review of draft-levine-herkula-oneclick-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2016 16:18:41 -0000 > "The URI and POST arguments SHOULD include a hard to forge component > such as an HMAC (RFC 2104) of the other components, using a secret > key, in addition to or instead of the plain-text names of the list and > the subscriber." > > Although its kinda obvious, you should probably also say that the > server SHOULD verify this HMAC. It couldn't hurt, I'll put it into the -06. > Finally, since the URI argument is the subject of an existing RFC > (2369) that RFC should probably be updated to include this advice. I don't think that's right. The usual way to verify a 2369 unsubscribe is to ask for confirmation, either in a web page if the URI is an http or https, or by writing back if it's mailto:. That doesn't change for the current GET syntax of 2369. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Sep 18 10:05:59 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4119212B140 for ; Sun, 18 Sep 2016 10:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.317 X-Spam-Level: X-Spam-Status: No, score=-4.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcuabaPWATd1 for ; Sun, 18 Sep 2016 10:05:53 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::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 B52D912B142 for ; Sun, 18 Sep 2016 10:05:52 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id i66so69287840yba.0 for ; Sun, 18 Sep 2016 10:05:52 -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; bh=mHuW8uh/Q2Cnolzx366iceqjLaZtGLLUDHT/wWL9kek=; b=VFsb6usGPNxpWlE8e8uduKnxeGEXyTnrMjXe58I9tHPeJ7gyiZDAWP2TDjzfoF7EYE EwPzmhx0peLoRuXCCK5F0mRYvSfDZ1cJoAL3jrSvf7pOyOd5ppNBmbcQqHHWkZwsfMPH s8fGieCbdUTMoxdg14f9ibLEMFISAgeOwQtuPqyd5+rcVztAoPpP8oL4yjkYfBpOEbLp +W0qQevZ8t/+QBrY/RIx1EJ2AB9B5nD1D0BWJJC+9PZc23SS5qqHGcQwp1MyDfu61tuE H25waJFNBZIlOiCoiz3A/DvS+qFQ7EVhZ9vt2O15cbqGbuAhoyDvtSfSjcy9ejKWd4iw 5AwQ== 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; bh=mHuW8uh/Q2Cnolzx366iceqjLaZtGLLUDHT/wWL9kek=; b=BrphsDOZaPWpfqK6De0VyXxrn+z1eOjiqv4rmBzby1XfN9kz+kPDaMyj0BJmxQAOrv YFw3YPNj/VpY0lgn1DC1uOfpOL12qmorDPpkjhArxRuZ24ycfkp+7Jn+ls5nOjrf+0aY vBbCG6XzlLF3ngfbxLvK+zRvtW5/wxBGRNM/ZTlAXeRC0io+o8Pm+RP2xmdHVnKxyVSh +eFo0ePEmR2b0QgUbzfbDc1hd9f7PWblE1cXNIse/lyewha1AUoo6AwdyL+3ydXPYZjA svSF+jUenXTTPX+mmR4mCEP1fjbQTnHvPMh6qmU4ik+GeAEZ+AVOxmsDUB539nILfGrC uWAw== X-Gm-Message-State: AE9vXwNhpTbCNfxOdyahot7uvbrXCUfLnILd5N3V6nB+gEeRvJ5dpmWSY4woEeulsJrbVDemEY754SP/AkRlac2s X-Received: by 10.37.44.23 with SMTP id s23mr21051054ybs.18.1474218351840; Sun, 18 Sep 2016 10:05:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.148.11 with HTTP; Sun, 18 Sep 2016 10:05:51 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Sun, 18 Sep 2016 18:05:51 +0100 Message-ID: To: "John R. Levine" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-levine-herkula-oneclick.all@ietf.org, Paul Kincaid-Smith , The IESG , "secdir@ietf.org" Subject: Re: [secdir] [taugh.com-standards] Security review of draft-levine-herkula-oneclick-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2016 17:05:54 -0000 On 18 September 2016 at 17:18, John R. Levine wrote: >> "The URI and POST arguments SHOULD include a hard to forge component >> such as an HMAC (RFC 2104) of the other components, using a secret >> key, in addition to or instead of the plain-text names of the list and >> the subscriber." >> >> Although its kinda obvious, you should probably also say that the >> server SHOULD verify this HMAC. > > > It couldn't hurt, I'll put it into the -06. > >> Finally, since the URI argument is the subject of an existing RFC >> (2369) that RFC should probably be updated to include this advice. > > > I don't think that's right. The usual way to verify a 2369 unsubscribe is > to ask for confirmation, either in a web page if the URI is an http or > https, or by writing back if it's mailto:. That doesn't change for the > current GET syntax of 2369. If the goal is to prevent spoofed mails leading to unsubscription, then it applies in either case. From nobody Sun Sep 18 10:09:12 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A991C12B130 for ; Sun, 18 Sep 2016 10:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.017 X-Spam-Level: X-Spam-Status: No, score=-5.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8Id_Se2W7n2 for ; Sun, 18 Sep 2016 10:09:08 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 C3CC812B145 for ; Sun, 18 Sep 2016 10:09:06 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id g192so119305355ywh.1 for ; Sun, 18 Sep 2016 10:09:06 -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; bh=o7+9MFdi7MI5LOPEU+FbeevcNjOU3cCXhMRErTXvXcQ=; b=SX7jkPpBroktKMKdrPrWlHNyYLPEKPf7883hb/TQloqxMhwSHIiJ3qupo/Ua3ygvCf HhVH/3Pla3eYU0hFReJAogSAbW9ONzkxd/XIfOZxDVqv3h+b2kSKWBkAFVqN5ssutBZz 5g5UHz024wOg0u3Opcbo0PklqWVUOugROiTOD9XZb6myCot66Ys5HsBLQkrZpKMrDN16 P0G3KmjW4LnK3dyKmWKhn+3HShF/8oflFBFbZG8lQOnwSwPMnWvJhK2T3pv/FBzC2psf mQHRqp9YjEvkMApI7hbbwoOM+N+ff8UYaaYVwO5Np0jaS3oAbExcfz4CzmBpF+LcsieQ hUWA== 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; bh=o7+9MFdi7MI5LOPEU+FbeevcNjOU3cCXhMRErTXvXcQ=; b=TY3Kp6YvJ3IfP8fqLPUwul2kYxSQFtQaDvU7xR/Y61XVkW9wcg+IISvzdyy8+660n4 /D1zrczGGwA1sVctVhoXKDAQtDPum7zRPxCDuBScP7INLSmhb+jbcdOs5a4ghl8BTh0T 3DLo099F4H8Dd2EovvF0GvyS6hELd8nn4pTm85VTq3kNpiADEms8Z5tYES+uIQq7LzGD 7G97luMnnRCnIHSlMlWe36PxZNkxauavlb2yEJsnqFUSX9HRNeoPXF7/jMTkuPlB5uNp INoDoqGXkecGF28TUDqRQLkarD/AtvHAUKMTSNxZ3Lq1F6Vkn5DMDudseMx1kc3n5Egr oB0Q== X-Gm-Message-State: AE9vXwNBQNdJ2PaFwgQVXMPpQcKh4Ze0s5QaYjKy+jt9figo8xbPQ7cmep1aJjzEmMxT+qpQXZB5BSjNoMewTkS1 X-Received: by 10.13.225.211 with SMTP id k202mr14830456ywe.322.1474218545925; Sun, 18 Sep 2016 10:09:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.148.11 with HTTP; Sun, 18 Sep 2016 10:09:05 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Sun, 18 Sep 2016 18:09:05 +0100 Message-ID: To: "John R. Levine" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-levine-herkula-oneclick.all@ietf.org, Paul Kincaid-Smith , The IESG , "secdir@ietf.org" Subject: Re: [secdir] [taugh.com-standards] Security review of draft-levine-herkula-oneclick-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2016 17:09:08 -0000 On 18 September 2016 at 18:07, John R. Levine wrote: >>> I don't think that's right. The usual way to verify a 2369 unsubscribe >>> is >>> to ask for confirmation, either in a web page if the URI is an http or >>> https, or by writing back if it's mailto:. That doesn't change for the >>> current GET syntax of 2369. >> >> >> If the goal is to prevent spoofed mails leading to unsubscription, >> then it applies in either case. > > > It's only a goal here because they have other ways to do it if it's not > one-click. Ok, then in that case it seems like you only need to secure the POST arguments, not the URI. From nobody Sun Sep 18 10:13:58 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0346F12B130 for ; Sun, 18 Sep 2016 10:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dRFzAMqOenz for ; Sun, 18 Sep 2016 10:13:56 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5ABA128B38 for ; Sun, 18 Sep 2016 10:13:55 -0700 (PDT) Received: (qmail 15406 invoked from network); 18 Sep 2016 17:07:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3c2d.57dec9c0.k1609; bh=sSurJdrVJxQyo/mJWl5wy5KIp4fwLi8ev9XdXcngNfI=; b=wWbHjGfaSFoHDP+7ut7SFa9jURNigcD9R8e7Fvk4ACf2fJkFrp0OcLyfIcN4ngYLrrfrEMqu0jJ10s/r403vBpcQBgxeYSBjiqRNnpGd3E2aHkljwowwtiWJLPelh0/facoTyJFkb1AbmACq5nD8rRBzl/A2cFFn+NeoJssVe9afe2WLEyKdJ+wdEoU3wlxdfCEx619yQQw1IR/1UUvSwyerWWyZuTbMIanQ/yBQHl+ZLlRIeLJQAqHyU386uGNr Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 18 Sep 2016 17:07:12 -0000 Date: 18 Sep 2016 13:07:13 -0400 Message-ID: From: "John R. Levine" To: "Ben Laurie" In-Reply-To: References: User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: draft-levine-herkula-oneclick.all@ietf.org, Paul Kincaid-Smith , The IESG , "secdir@ietf.org" Subject: Re: [secdir] [taugh.com-standards] Security review of draft-levine-herkula-oneclick-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2016 17:13:57 -0000 >> I don't think that's right. The usual way to verify a 2369 unsubscribe is >> to ask for confirmation, either in a web page if the URI is an http or >> https, or by writing back if it's mailto:. That doesn't change for the >> current GET syntax of 2369. > > If the goal is to prevent spoofed mails leading to unsubscription, > then it applies in either case. It's only a goal here because they have other ways to do it if it's not one-click. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Sep 18 11:02:23 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B045212B05D for ; Sun, 18 Sep 2016 11:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNi9LOljvZQ1 for ; Sun, 18 Sep 2016 11:02:19 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF1B12B020 for ; Sun, 18 Sep 2016 11:02:19 -0700 (PDT) Received: (qmail 22390 invoked from network); 18 Sep 2016 17:55:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5775.57ded517.k1609; bh=+pF9LZ3tg+pYXlliEdISLZAKJWhczxKo6/zo1za7+B0=; b=XjBXTsSezwTRs97+ffb4+7/bFMKInyOx+y/jjCcz4v3KMbOxemCmkkxf7aCVM1r/ORDty7Ey+p+KlNxqaPQfSMep505bLeXmO11UwrnmseR1nVAgCb8wihT4Dsa+inkK+XMtugCB7REtKuhhH40CSGdpy5z+ifhtiT1zYAwmvP9tN73B9KoYiFfIqw20X/F9WTdagAUDlqpHmxbRRKxqTmtEd3GGD33RouYTBBkaBajhhxOSy3GwR55TSIEP4RUB Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 18 Sep 2016 17:55:35 -0000 Date: 18 Sep 2016 13:55:36 -0400 Message-ID: From: "John R. Levine" To: "Ben Laurie" In-Reply-To: References: User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: draft-levine-herkula-oneclick.all@ietf.org, Paul Kincaid-Smith , The IESG , "secdir@ietf.org" Subject: Re: [secdir] [taugh.com-standards] Re:Security review of draft-levine-herkula-oneclick-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2016 18:02:21 -0000 >> It's only a goal here because they have other ways to do it if it's not >> one-click. > > Ok, then in that case it seems like you only need to secure the POST > arguments, not the URI. There's several scenarios that this draft is addressing: A) bad guy sends fake mail with real insecure opt-out link, MUA clicks it indirectly when user hits the junk button B) real message with real link is clicked by helpful anti-spam software, not the user The hash stuff is for A, the POST is for B. Since the POST gets both the URI and the arguments, the hash can be in whichever is operationally easier. All the places that have rules about commercial junk mail say that if the recipient tells you to stop, you have to stop and "the link was in a fake message" isn't a defense. It's quite common now for the unsubscribe URI to be totally opaque, e.g., with a hash and a key the mailer looks up in a database to find the recipient's address, so that malicious parties can't guess other subscribers' addresses. If they add POST arguments for one-click, they'll likely keep the existing opaque URI, and with the secure URI, the POST arguments tell it nothing beyond the fact that this is a one-click transaction. In the two decades since 2369 came out, the URI stuff has become common knowledge among the narrow group of people for whom "deliverability" is an adjective. I really don't want to open up 2369 with this draft, because I don't think the small amount this draft says would be helpful. It doesn't change the way people use 2369, it only adds a new way to do list-unsubscribe. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Sep 18 12:41:09 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F68112B00D; Sun, 18 Sep 2016 12:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvmaYxpSQuzR; Sun, 18 Sep 2016 12:41:07 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002: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 BC13F12B0E0; Sun, 18 Sep 2016 12:41:06 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id g192so121840094ywh.1; Sun, 18 Sep 2016 12:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=gDRRKyKmw0KpPGOBLVUHX2xfqcOweRhuSTgcvdznwl4=; b=xoDare4NQUiVvljNVXvB9jUTnvKofrpX8dpPin1pBXE2XaT6n+JeTrwPhmUXas92dA N4buMDQUg0skzwg2qToI7F7m5zV2o1YgVHEC4oAVZKkQQc0RikAxWz/T/mOiBO9YyKPF 9r8cEfx2pjB4LBHYxAplaOQmjqtJSNfaDKODg9HiQg/xJeVDVHlLPeyVzlO2koS9RmBy X3CRrqneDvifHb4VC+8BPyI+s3eLo2i6H66V21XeT10SBz3OPco/75z+EgL5P5giU3fS DTi49Gn4I6w9jnKmFBbe15ruIhy/02kFvvXU9HW8peqBNg62BLiCVcC5mMHBzAl/O8YI WeiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gDRRKyKmw0KpPGOBLVUHX2xfqcOweRhuSTgcvdznwl4=; b=NYAkRW36poecKsL1km/Ua9cVhqxWhpBH1ucmtv/cggAFyWnl6m0uV/TjRq2O+fmcPR gG+JYSiqUQ3w6/Bb1o6RFHIMTE3rbmqFclUekmVqZZWH4b4jbeROyM756aT7+Xol5g3Z 7IgpL7n4INOOkvzXTx7/zK7jEmXBz0+t8a8P4zwBA39B3CY5nYXY8L1IKO1aZtrM6njd nHr+lIMPse8q2JjhUqMQsFcm1/GVEj7kdz/Kvc710OzcERPeeCbmasaywGmxkKyribRS KkslXAxLBAcXKgQkBXtZYpYOdIfakrrwgfaD9lf7wyZQ3ncO7yDHB1zPKo1ltzP874xq 1FWQ== X-Gm-Message-State: AE9vXwMU8mSwnWJL38oQFb5ORW+L1MlnWCVIUComz7qwIRHuD2yqXHi+zdO2kIClI9GfaGWkfMst//oO3ddNLA== X-Received: by 10.13.203.79 with SMTP id n76mr21258547ywd.122.1474227665844; Sun, 18 Sep 2016 12:41:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.102 with HTTP; Sun, 18 Sep 2016 12:41:05 -0700 (PDT) From: Watson Ladd Date: Sun, 18 Sep 2016 12:41:05 -0700 Message-ID: To: "" , secdir@ietf.org, draft-ietf-tictoc-multi-path-synchronization.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2016 19:41:08 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document presents a mechanism for servers and clients to conduct synchronization protocols over multiple paths. I didn't see anything wrong with the mechanism, but I am worried that its security benefits are overstated: independent paths may only be partially independent, and attackers can easily migrate from one router to another in most networks. Sincerely, Watson Ladd From nobody Sun Sep 18 16:22:58 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0700C12B15C; Sun, 18 Sep 2016 16:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gyb0IDI-coXn; Sun, 18 Sep 2016 16:22:55 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 BB6DD12B03B; Sun, 18 Sep 2016 16:22:55 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8INKGk4015313; Sun, 18 Sep 2016 16:22:52 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 25h36k4n81-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 18 Sep 2016 16:22:51 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Sep 2016 02:22:43 +0300 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1104.000; Mon, 19 Sep 2016 02:22:43 +0300 From: Tal Mizrahi To: Watson Ladd , "" , "secdir@ietf.org" , "draft-ietf-tictoc-multi-path-synchronization.all@tools.ietf.org" , "Suresh Krishnan" , "Karen ODonoghue (odonoghue@isoc.org)" Thread-Topic: secdir review of draft-ietf-tictoc-multi-path-synchronization-05 Thread-Index: AQHSEeSgVxkDrkl/jE+0/2Rx8wj6kqB/4pcA Date: Sun, 18 Sep 2016 23:22:42 +0000 Message-ID: <2c34b139112a45ac9a68ff000aa7d934@IL-EXCH01.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.94.250.30] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-18_14:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609180323 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2016 23:22:57 -0000 RGVhciBXYXRzb24sDQoNClRoYW5rcyBmb3IgcmV2aWV3aW5nIHRoZSBkcmFmdC4NCg0KVG8gYWRk cmVzcyB5b3VyIGNvbW1lbnRzLCBJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0aGUgZm9sbG93aW5n IHRleHQgZm9yIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0KUGxlYXNlIGxl dCB1cyBrbm93IGlmIHRoaXMgYWRkcmVzc2VzIHRoZSBjb21tZW50czoNCg0KDQpUaGUgc2VjdXJp dHkgYXNwZWN0cyBvZiB0aW1lIHN5bmNocm9uaXphdGlvbiBwcm90b2NvbHMgYXJlIGRpc2N1c3Nl ZCBpbiBkZXRhaWwgaW4gW1RJQ1RPQ1NFQ10uIFRoZSBtZXRob2RzIGRlc2NyaWJlIGluIHRoaXMg ZG9jdW1lbnQgcHJvcG9zZSB0byBydW4gYSB0aW1lIHN5bmNocm9uaXphdGlvbiBwcm90b2NvbCB0 aHJvdWdoIHJlZHVuZGFudCBwYXRocywgYW5kIHRodXMgYWxsb3cgdG8gZGV0ZWN0IGFuZCBtaXRp Z2F0ZSBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2tzLCBhcyBkZXNjcmliZWQgaW4gW0RFTEFZLUFU VF0uIEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IHdoZW4gdXNpbmcgbXVsdGlwbGUgcGF0aHMsIHRo ZXNlIHBhdGhzIG1heSBwYXJ0aWFsbHkgb3ZlcmxhcCwgYW5kIHRodXMgYW4gYXR0YWNrIHRoYXQg dGFrZXMgcGxhY2UgaW4gYSBjb21tb24gc2VnbWVudCBvZiB0aGVzZSBwYXRocyBpcyBub3QgbWl0 aWdhdGVkIGJ5IHRoZSByZWR1bmRhbmN5LiBNb3Jlb3ZlciwgYW4gb24tcGF0aCBhdHRhY2tlciBt YXkgaW4gc29tZSBjYXNlcyBoYXZlIGFjY2VzcyB0byBtb3JlIHRoYW4gb25lIHJvdXRlciwgb3Ig bWF5IGJlIGFibGUgdG8gbWlncmF0ZSBmcm9tIG9uZSByb3V0ZXIgdG8gYW5vdGhlci4gVGhlcmVm b3JlLCB3aGVuIHVzaW5nIG11bHRpcGxlIHBhdGhzIGl0IGlzIGltcG9ydGFudCBmb3IgdGhlIHBh dGhzIHRvIGJlIGFzIGRpdmVyc2UgYW5kIGFzIGluZGVwZW5kZW50IGFzIHBvc3NpYmxlLCBtYWtp bmcgdGhlIHJlZHVuZGFuY3kgc2NoZW1lIG1vcmUgdG9sZXJhbnQgdG8gb24tcGF0aCBhdHRhY2tz Lg0KDQoNCg0KUmVnYXJkcywNClRhbC4NCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogV2F0c29uIExhZGQgW21haWx0bzp3YXRzb25ibGFkZEBnbWFpbC5jb21dDQo+U2VudDog U3VuZGF5LCBTZXB0ZW1iZXIgMTgsIDIwMTYgMTA6NDEgUE0NCj5UbzogPGllc2dAaWV0Zi5vcmc+ OyBzZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdGljdG9jLW11bHRpLXBhdGgtDQo+c3luY2hy b25pemF0aW9uLmFsbEB0b29scy5pZXRmLm9yZw0KPlN1YmplY3Q6IHNlY2RpciByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi10aWN0b2MtbXVsdGktcGF0aC1zeW5jaHJvbml6YXRpb24tMDUNCj4NCj5JIGhh dmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3Rv cmF0ZSdzIG9uZ29pbmcNCj5lZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWlu ZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZQ0KPmNvbW1lbnRzIHdlcmUgd3JpdHRlbiBw cmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhDQo+ZGlyZWN0b3Jz LiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21t ZW50cyBqdXN0DQo+bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPg0KPlRoZSBk b2N1bWVudCBwcmVzZW50cyBhIG1lY2hhbmlzbSBmb3Igc2VydmVycyBhbmQgY2xpZW50cyB0byBj b25kdWN0DQo+c3luY2hyb25pemF0aW9uIHByb3RvY29scyBvdmVyIG11bHRpcGxlIHBhdGhzLiBJ IGRpZG4ndCBzZWUgYW55dGhpbmcgd3JvbmcNCj53aXRoIHRoZSBtZWNoYW5pc20sIGJ1dCBJIGFt IHdvcnJpZWQgdGhhdCBpdHMgc2VjdXJpdHkgYmVuZWZpdHMgYXJlDQo+b3ZlcnN0YXRlZDogaW5k ZXBlbmRlbnQgcGF0aHMgbWF5IG9ubHkgYmUgcGFydGlhbGx5IGluZGVwZW5kZW50LCBhbmQNCj5h dHRhY2tlcnMgY2FuIGVhc2lseSBtaWdyYXRlIGZyb20gb25lIHJvdXRlciB0byBhbm90aGVyIGlu IG1vc3QgbmV0d29ya3MuDQo+DQo+U2luY2VyZWx5LA0KPldhdHNvbiBMYWRkDQo= From nobody Sun Sep 18 16:36:10 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F36812B034 for ; Sun, 18 Sep 2016 16:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZMbxT3i5xGi for ; Sun, 18 Sep 2016 16:36:02 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A503212B046 for ; Sun, 18 Sep 2016 16:36:02 -0700 (PDT) Received: (qmail 76189 invoked from network); 18 Sep 2016 23:35:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1299c.57df24df.k1609; bh=o/tFmo5SWWa7VPDml56pZj0k938beLc1pjUV2bkZK6Q=; b=v3cyjIwwoBq+MDBFum9kt5e5yRQHBk8xoSGkX7fQ70iGulDCrN1FxuLdy6EeL4go2kyBQiuh+bVafLqo4ZPH+vjIRDXL2W9TBZ66LBSm8kuGlB8NUxWu7QoNyx5sG8fOmktjK7wfiuubObcjblnStR4hXPCy5JlA+wbd5QPpsr0hSKr7JdZq00pANwX9NQUTBfZs6un8eG/I18WdO+BoAjIDZRUPMO6U9dg/3zKzW+i4Y3TzL6TaGSYIMDTRqHH9 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 18 Sep 2016 23:35:59 -0000 Date: 18 Sep 2016 19:36:00 -0400 Message-ID: From: "John R. Levine" To: "Ben Laurie" In-Reply-To: References: User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Paul Kincaid-Smith , The IESG , Tobias Herkula , "secdir@ietf.org" Subject: Re: [secdir] [taugh.com-standards] Re:Security review of draft-levine-herkula-oneclick-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2016 23:36:05 -0000 One other thought -- I think the most common thing that mailers do is to put the subscriber info into a database where each record includes a randomly generated key unrelated to anything else. Then you put that key into the URI, no HMAC needed. R's, John >>> It's only a goal here because they have other ways to do it if it's not >>> one-click. >> >> Ok, then in that case it seems like you only need to secure the POST >> arguments, not the URI. > > There's several scenarios that this draft is addressing: > > A) bad guy sends fake mail with real insecure opt-out link, MUA clicks it > indirectly when user hits the junk button > > B) real message with real link is clicked by helpful anti-spam software, not > the user > > The hash stuff is for A, the POST is for B. Since the POST gets both the URI > and the arguments, the hash can be in whichever is operationally easier. All > the places that have rules about commercial junk mail say that if the > recipient tells you to stop, you have to stop and "the link was in a fake > message" isn't a defense. It's quite common now for the unsubscribe URI to be > totally opaque, e.g., with a hash and a key the mailer looks up in a database > to find the recipient's address, so that malicious parties can't guess other > subscribers' addresses. If they add POST arguments for one-click, they'll > likely keep the existing opaque URI, and with the secure URI, the POST > arguments tell it nothing beyond the fact that this is a one-click > transaction. > > In the two decades since 2369 came out, the URI stuff has become common > knowledge among the narrow group of people for whom "deliverability" is an > adjective. I really don't want to open up 2369 with this draft, because I > don't think the small amount this draft says would be helpful. It doesn't > change the way people use 2369, it only adds a new way to do > list-unsubscribe. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Sep 18 16:59:26 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C748812B034; Sun, 18 Sep 2016 16:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdfZmxZlN2Vx; Sun, 18 Sep 2016 16:59:18 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 73848128E19; Sun, 18 Sep 2016 16:59:18 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id t67so122243203ywg.3; Sun, 18 Sep 2016 16:59:18 -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-transfer-encoding; bh=Dj3TA+lE+ZS4gL2KcLhibX9P/jzSSb8haif/GI0g/jU=; b=i0G1XqpoNsUadZr4VI3ppSuOL+OuRaokR+kD3SsEJFGUwcbglrvCAZY1YARgXifvLg N8/NXUYOe+Xvz2U+FMbzSJcYoFWCjyq2hXV2E7elA448f/5HiXka82TagEWBoW97uKTD kvxwassVuT+U32KGbnMKB4tfWBmL1qIi0n4K/tDl6c4GMAjaFfD52aTArmZB6wNp4n5X 2XmYKCfkXMSQC1A5rhn3J8y4HpadDT0L5/8T+LEfkH27DA7G8jbv9pWo3fRCF4y013Yc ejUs4kkqxvLW5nNoU+uodKvWK4ArLcF57DD+PUJke3plLQreAH2GVvSq0cqZ7Tjjfb/S kVdA== 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-transfer-encoding; bh=Dj3TA+lE+ZS4gL2KcLhibX9P/jzSSb8haif/GI0g/jU=; b=AqBV0zwlxBo3S2h7WWyQ2x/CraDS6PoT1PRmt+IeFc6s64497GSIgX1lplqRemBrPf C5zl3UyvmkWgu3P6tUnTFLXS4k/7Vt7aJk7y+9lTnM9r6pIihgnoaddUtvpQLLIlxKdH l11LdKPxDQ/NJEB8fXXQaC5KNYQd1Mi+Ko28EtGKiGbQa1yVj3y9DUdUg38TKh9sJfLr u8IJy1CfUrZBR2sFSd4Eym9b2KWVsHGOhuWwyIpXlE1pmAK92/Pu1hUwQB1wh/qApAf+ 5BbsGEzuAHeDdWip06Rl/tJyWixyuZZhNfPIIGuFm5DwtHtgDoixJ9xDUveVMV1VOhip tosg== X-Gm-Message-State: AE9vXwNBouziz62bvDB1iwh7MXibK5fJIuhmoQL5vIaE8ptJVm8ughok7SxJijrxvsueygR0XD8LmBKo5gkw6A== X-Received: by 10.13.228.135 with SMTP id n129mr22892332ywe.196.1474243157631; Sun, 18 Sep 2016 16:59:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.102 with HTTP; Sun, 18 Sep 2016 16:59:17 -0700 (PDT) In-Reply-To: <2c34b139112a45ac9a68ff000aa7d934@IL-EXCH01.marvell.com> References: <2c34b139112a45ac9a68ff000aa7d934@IL-EXCH01.marvell.com> From: Watson Ladd Date: Sun, 18 Sep 2016 16:59:17 -0700 Message-ID: To: Tal Mizrahi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-ietf-tictoc-multi-path-synchronization.all@tools.ietf.org" , "Karen ODonoghue \(odonoghue@isoc.org\)" , "" , Suresh Krishnan , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2016 23:59:21 -0000 On Sun, Sep 18, 2016 at 4:22 PM, Tal Mizrahi wrote: > Dear Watson, > > Thanks for reviewing the draft. > > To address your comments, I would like to suggest the following text for = the Security Considerations section. > Please let us know if this addresses the comments: > > > The security aspects of time synchronization protocols are discussed in d= etail in [TICTOCSEC]. The methods describe in this document propose to run = a time synchronization protocol through redundant paths, and thus allow to = detect and mitigate man-in-the-middle attacks, as described in [DELAY-ATT].= It should be noted that when using multiple paths, these paths may partial= ly overlap, and thus an attack that takes place in a common segment of thes= e paths is not mitigated by the redundancy. Moreover, an on-path attacker m= ay in some cases have access to more than one router, or may be able to mig= rate from one router to another. Therefore, when using multiple paths it is= important for the paths to be as diverse and as independent as possible, m= aking the redundancy scheme more tolerant to on-path attacks. Multipath shouldn't be discussed as a security measure at all. My reading of the document was that it was simply to get more reliable packet delays and synchronization. You cannot throw this claim into the security considerations alone without explaining the rest of the picture. Why not remove it entirely? Real attackers get the job done: they grab the community strings and use them to own every single router you have, or own the sysadmins PC and go for all the routers at once. And it's not uncommon for machines to be connected to only one router: most desktops and laptops have a single Ethernet port. The proposed text makes extremely common things sound rare. > > > > Regards, > Tal. > >>-----Original Message----- >>From: Watson Ladd [mailto:watsonbladd@gmail.com] >>Sent: Sunday, September 18, 2016 10:41 PM >>To: ; secdir@ietf.org; draft-ietf-tictoc-multi-path- >>synchronization.all@tools.ietf.org >>Subject: secdir review of draft-ietf-tictoc-multi-path-synchronization-05 >> >>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 >>directors. Document editors and WG chairs should treat these comments ju= st >>like any other last call comments. >> >>The document presents a mechanism for servers and clients to conduct >>synchronization protocols over multiple paths. I didn't see anything wron= g >>with the mechanism, but I am worried that its security benefits are >>overstated: independent paths may only be partially independent, and >>attackers can easily migrate from one router to another in most networks. >> >>Sincerely, >>Watson Ladd --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sun Sep 18 17:34:48 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7760D12B16D; Sun, 18 Sep 2016 17:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXhGXn1FrOLN; Sun, 18 Sep 2016 17:34:41 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 63D0112B169; Sun, 18 Sep 2016 17:34:41 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8J0UAr5024934; Sun, 18 Sep 2016 17:34:37 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0a-0016f401.pphosted.com with ESMTP id 25h36k4u3h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 18 Sep 2016 17:34:37 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Sep 2016 03:34:34 +0300 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1104.000; Mon, 19 Sep 2016 03:34:34 +0300 From: Tal Mizrahi To: Watson Ladd Thread-Topic: secdir review of draft-ietf-tictoc-multi-path-synchronization-05 Thread-Index: AQHSEeSgVxkDrkl/jE+0/2Rx8wj6kqB/4pcA///YqYCAADiWMA== Date: Mon, 19 Sep 2016 00:34:33 +0000 Message-ID: <3993e58a01f4472992ae6fcdfaa8e0f7@IL-EXCH01.marvell.com> References: <2c34b139112a45ac9a68ff000aa7d934@IL-EXCH01.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.36.250.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-18_15:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609190006 Archived-At: Cc: "draft-ietf-tictoc-multi-path-synchronization.all@tools.ietf.org" , "Karen ODonoghue \(odonoghue@isoc.org\)" , "" , Suresh Krishnan , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 00:34:42 -0000 RGVhciBXYXRzb24sDQoNClRoYW5rcyBmb3IgdGhlIHByb21wdCByZXNwb25zZS4NCg0KPk11bHRp cGF0aCBzaG91bGRuJ3QgYmUgZGlzY3Vzc2VkIGFzIGEgc2VjdXJpdHkgbWVhc3VyZSBhdCBhbGwu IE15IHJlYWRpbmcgb2YNCj50aGUgZG9jdW1lbnQgd2FzIHRoYXQgaXQgd2FzIHNpbXBseSB0byBn ZXQgbW9yZSByZWxpYWJsZSBwYWNrZXQgZGVsYXlzIGFuZA0KPnN5bmNocm9uaXphdGlvbi4gWW91 IGNhbm5vdCB0aHJvdyB0aGlzIGNsYWltIGludG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z DQo+YWxvbmUgd2l0aG91dCBleHBsYWluaW5nIHRoZSByZXN0IG9mIHRoZSBwaWN0dXJlLiBXaHkg bm90IHJlbW92ZSBpdCBlbnRpcmVseT8NCj4NCg0KVGhlIG11bHRpLXBhdGggc2NoZW1lIGFkZHJl c3NlcyBib3RoIGFuIGFjY3VyYWN5IGlzc3VlIGFuZCBhIHNlY3VyaXR5IGlzc3VlLiBUaGUgc2Vj dXJpdHkgYXNwZWN0IGlzIG1lbnRpb25lZCB3ZWxsIGJlZm9yZSB0aGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgc2VjdGlvbiwgaW5jbHVkaW5nIGluIHRoZSBhYnN0cmFjdCBhbmQgaW4gdGhlIGlu dHJvZHVjdGlvbi4NCg0KPlJlYWwgYXR0YWNrZXJzIGdldCB0aGUgam9iIGRvbmU6IHRoZXkgZ3Jh YiB0aGUgY29tbXVuaXR5IHN0cmluZ3MgYW5kIHVzZQ0KPnRoZW0gdG8gb3duIGV2ZXJ5IHNpbmds ZSByb3V0ZXIgeW91IGhhdmUsIG9yIG93biB0aGUgc3lzYWRtaW5zIFBDIGFuZCBnbw0KPmZvciBh bGwgdGhlIHJvdXRlcnMgYXQgb25jZS4gIEFuZCBpdCdzIG5vdCB1bmNvbW1vbiBmb3IgbWFjaGlu ZXMgdG8gYmUNCj5jb25uZWN0ZWQgdG8gb25seSBvbmUgcm91dGVyOiBtb3N0IGRlc2t0b3BzIGFu ZCBsYXB0b3BzIGhhdmUgYSBzaW5nbGUNCj5FdGhlcm5ldCBwb3J0LiBUaGUgcHJvcG9zZWQgdGV4 dCBtYWtlcyBleHRyZW1lbHkgY29tbW9uIHRoaW5ncyBzb3VuZA0KPnJhcmUuDQoNClRpbWUgcHJv dG9jb2xzIGhhdmUgYSBwcmV0dHkgdW5pcXVlIHByb3BlcnR5OiBldmVuIGlmIHlvdSB1c2UgdGhl IHN0cm9uZ2VzdCBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbXMsIHRoZSBwcm90b2NvbCBjYW4gc3Rp bGwgZWFzaWx5IGJlIGF0dGFja2VkIGJ5IGEgbWFuLWluLXRoZS1taWRkbGUgd2hvIHNpbXBseSBh ZGRzIGEgY29uc3RhbnQgZGVsYXkgdG8gc29tZSBvZiB0aGUgcGFja2V0cywgYW5kIHRoZXJlYnkg ZWFzaWx5IG1hbmlwdWxhdGVzIHRoZSBwcm90b2NvbC4gVGhlIG9ubHkgd2F5IHRvIG1pdGlnYXRl IGRlbGF5IGF0dGFja3MgaXMgYnkgcmVkdW5kYW5jeTogbXVsdGlwbGUgdGltZSBzb3VyY2VzIGFu ZC9vciBtdWx0aXBsZSBuZXR3b3JrIHBhdGhzLg0KVGhlIGRlbGF5IGF0dGFjayBpcyBvbmUgb2Yg dGhlIG1vc3Qgc2lnbmlmaWNhbnQgdGhyZWF0cyBpbiB0aW1lIHByb3RvY29scywgYW5kIHRoZXJl Zm9yZSB3ZSBkZWZpbmVkIGRlbGF5IGF0dGFjayBwcm90ZWN0aW9uIGFzIGEgTVVTVCBpbiBSRkMg NzM4NC4NClNlY3VyaXR5IGlzIGFuIGltcG9ydGFudCBhc3BlY3Qgb2YgbXVsdGktcGF0aCBzeW5j aHJvbml6YXRpb24sIGFuZCBJIGJlbGlldmUgdGhlIGN1cnJlbnQgZHJhZnQgaGFzIHRvIHRhbGsg YWJvdXQgdGhpcyBhc3BlY3QuDQoNCkJlc3QgcmVnYXJkcywNClRhbC4NCg0KDQoNCj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IFdhdHNvbiBMYWRkIFttYWlsdG86d2F0c29uYmxh ZGRAZ21haWwuY29tXQ0KPlNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDE5LCAyMDE2IDI6NTkgQU0N Cj5UbzogVGFsIE1penJhaGkNCj5DYzogPGllc2dAaWV0Zi5vcmc+OyBzZWNkaXJAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtdGljdG9jLW11bHRpLXBhdGgtDQo+c3luY2hyb25pemF0aW9uLmFsbEB0b29s cy5pZXRmLm9yZzsgU3VyZXNoIEtyaXNobmFuOyBLYXJlbiBPRG9ub2dodWUNCj4ob2Rvbm9naHVl QGlzb2Mub3JnKQ0KPlN1YmplY3Q6IFJlOiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtdGlj dG9jLW11bHRpLXBhdGgtc3luY2hyb25pemF0aW9uLTA1DQo+DQo+T24gU3VuLCBTZXAgMTgsIDIw MTYgYXQgNDoyMiBQTSwgVGFsIE1penJhaGkgPHRhbG1pQG1hcnZlbGwuY29tPiB3cm90ZToNCj4+ IERlYXIgV2F0c29uLA0KPj4NCj4+IFRoYW5rcyBmb3IgcmV2aWV3aW5nIHRoZSBkcmFmdC4NCj4+ DQo+PiBUbyBhZGRyZXNzIHlvdXIgY29tbWVudHMsIEkgd291bGQgbGlrZSB0byBzdWdnZXN0IHRo ZSBmb2xsb3dpbmcgdGV4dCBmb3IgdGhlDQo+U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlv bi4NCj4+IFBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGlzIGFkZHJlc3NlcyB0aGUgY29tbWVudHM6 DQo+Pg0KPj4NCj4+IFRoZSBzZWN1cml0eSBhc3BlY3RzIG9mIHRpbWUgc3luY2hyb25pemF0aW9u IHByb3RvY29scyBhcmUgZGlzY3Vzc2VkIGluDQo+ZGV0YWlsIGluIFtUSUNUT0NTRUNdLiBUaGUg bWV0aG9kcyBkZXNjcmliZSBpbiB0aGlzIGRvY3VtZW50IHByb3Bvc2UgdG8gcnVuDQo+YSB0aW1l IHN5bmNocm9uaXphdGlvbiBwcm90b2NvbCB0aHJvdWdoIHJlZHVuZGFudCBwYXRocywgYW5kIHRo dXMgYWxsb3cgdG8NCj5kZXRlY3QgYW5kIG1pdGlnYXRlIG1hbi1pbi10aGUtbWlkZGxlIGF0dGFj a3MsIGFzIGRlc2NyaWJlZCBpbiBbREVMQVktQVRUXS4NCj5JdCBzaG91bGQgYmUgbm90ZWQgdGhh dCB3aGVuIHVzaW5nIG11bHRpcGxlIHBhdGhzLCB0aGVzZSBwYXRocyBtYXkgcGFydGlhbGx5DQo+ b3ZlcmxhcCwgYW5kIHRodXMgYW4gYXR0YWNrIHRoYXQgdGFrZXMgcGxhY2UgaW4gYSBjb21tb24g c2VnbWVudCBvZiB0aGVzZQ0KPnBhdGhzIGlzIG5vdCBtaXRpZ2F0ZWQgYnkgdGhlIHJlZHVuZGFu Y3kuIE1vcmVvdmVyLCBhbiBvbi1wYXRoIGF0dGFja2VyIG1heQ0KPmluIHNvbWUgY2FzZXMgaGF2 ZSBhY2Nlc3MgdG8gbW9yZSB0aGFuIG9uZSByb3V0ZXIsIG9yIG1heSBiZSBhYmxlIHRvDQo+bWln cmF0ZSBmcm9tIG9uZSByb3V0ZXIgdG8gYW5vdGhlci4gVGhlcmVmb3JlLCB3aGVuIHVzaW5nIG11 bHRpcGxlIHBhdGhzIGl0IGlzDQo+aW1wb3J0YW50IGZvciB0aGUgcGF0aHMgdG8gYmUgYXMgZGl2 ZXJzZSBhbmQgYXMgaW5kZXBlbmRlbnQgYXMgcG9zc2libGUsDQo+bWFraW5nIHRoZSByZWR1bmRh bmN5IHNjaGVtZSBtb3JlIHRvbGVyYW50IHRvIG9uLXBhdGggYXR0YWNrcy4NCj4NCj5NdWx0aXBh dGggc2hvdWxkbid0IGJlIGRpc2N1c3NlZCBhcyBhIHNlY3VyaXR5IG1lYXN1cmUgYXQgYWxsLiBN eSByZWFkaW5nIG9mDQo+dGhlIGRvY3VtZW50IHdhcyB0aGF0IGl0IHdhcyBzaW1wbHkgdG8gZ2V0 IG1vcmUgcmVsaWFibGUgcGFja2V0IGRlbGF5cyBhbmQNCj5zeW5jaHJvbml6YXRpb24uIFlvdSBj YW5ub3QgdGhyb3cgdGhpcyBjbGFpbSBpbnRvIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0K PmFsb25lIHdpdGhvdXQgZXhwbGFpbmluZyB0aGUgcmVzdCBvZiB0aGUgcGljdHVyZS4gV2h5IG5v dCByZW1vdmUgaXQgZW50aXJlbHk/DQo+DQo+UmVhbCBhdHRhY2tlcnMgZ2V0IHRoZSBqb2IgZG9u ZTogdGhleSBncmFiIHRoZSBjb21tdW5pdHkgc3RyaW5ncyBhbmQgdXNlDQo+dGhlbSB0byBvd24g ZXZlcnkgc2luZ2xlIHJvdXRlciB5b3UgaGF2ZSwgb3Igb3duIHRoZSBzeXNhZG1pbnMgUEMgYW5k IGdvDQo+Zm9yIGFsbCB0aGUgcm91dGVycyBhdCBvbmNlLiAgQW5kIGl0J3Mgbm90IHVuY29tbW9u IGZvciBtYWNoaW5lcyB0byBiZQ0KPmNvbm5lY3RlZCB0byBvbmx5IG9uZSByb3V0ZXI6IG1vc3Qg ZGVza3RvcHMgYW5kIGxhcHRvcHMgaGF2ZSBhIHNpbmdsZQ0KPkV0aGVybmV0IHBvcnQuIFRoZSBw cm9wb3NlZCB0ZXh0IG1ha2VzIGV4dHJlbWVseSBjb21tb24gdGhpbmdzIHNvdW5kDQo+cmFyZS4N Cj4NCj4+DQo+Pg0KPj4NCj4+IFJlZ2FyZHMsDQo+PiBUYWwuDQo+Pg0KPj4+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IFdhdHNvbiBMYWRkIFttYWlsdG86d2F0c29uYmxhZGRA Z21haWwuY29tXQ0KPj4+U2VudDogU3VuZGF5LCBTZXB0ZW1iZXIgMTgsIDIwMTYgMTA6NDEgUE0N Cj4+PlRvOiA8aWVzZ0BpZXRmLm9yZz47IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi10aWN0 b2MtbXVsdGktcGF0aC0NCj4+PnN5bmNocm9uaXphdGlvbi5hbGxAdG9vbHMuaWV0Zi5vcmcNCj4+ PlN1YmplY3Q6IHNlY2RpciByZXZpZXcgb2YNCj4+PmRyYWZ0LWlldGYtdGljdG9jLW11bHRpLXBh dGgtc3luY2hyb25pemF0aW9uLTA1DQo+Pj4NCj4+PkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3Vt ZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MNCj4+Pm9uZ29pbmcgZWZm b3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZQ0K Pj4+SUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBi ZW5lZml0IG9mIHRoZQ0KPj4+c2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0 b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0DQo+Pj50aGVzZSBjb21tZW50cyBqdXN0IGxp a2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4+Pg0KPj4+VGhlIGRvY3VtZW50IHBy ZXNlbnRzIGEgbWVjaGFuaXNtIGZvciBzZXJ2ZXJzIGFuZCBjbGllbnRzIHRvIGNvbmR1Y3QNCj4+ PnN5bmNocm9uaXphdGlvbiBwcm90b2NvbHMgb3ZlciBtdWx0aXBsZSBwYXRocy4gSSBkaWRuJ3Qg c2VlIGFueXRoaW5nDQo+Pj53cm9uZyB3aXRoIHRoZSBtZWNoYW5pc20sIGJ1dCBJIGFtIHdvcnJp ZWQgdGhhdCBpdHMgc2VjdXJpdHkgYmVuZWZpdHMNCj4+PmFyZQ0KPj4+b3ZlcnN0YXRlZDogaW5k ZXBlbmRlbnQgcGF0aHMgbWF5IG9ubHkgYmUgcGFydGlhbGx5IGluZGVwZW5kZW50LCBhbmQNCj4+ PmF0dGFja2VycyBjYW4gZWFzaWx5IG1pZ3JhdGUgZnJvbSBvbmUgcm91dGVyIHRvIGFub3RoZXIg aW4gbW9zdCBuZXR3b3Jrcy4NCj4+Pg0KPj4+U2luY2VyZWx5LA0KPj4+V2F0c29uIExhZGQNCj4N Cj4NCj4NCj4tLQ0KPiJNYW4gaXMgYm9ybiBmcmVlLCBidXQgZXZlcnl3aGVyZSBoZSBpcyBpbiBj aGFpbnMiLg0KPi0tUm91c3NlYXUuDQo= From nobody Mon Sep 19 04:00:48 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E08012B328 for ; Mon, 19 Sep 2016 04:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.016 X-Spam-Level: X-Spam-Status: No, score=-5.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtOV41KJPoaU for ; Mon, 19 Sep 2016 04:00:43 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 E152112B13D for ; Mon, 19 Sep 2016 04:00:42 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id g192so141759517ywh.1 for ; Mon, 19 Sep 2016 04:00:42 -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; bh=/sOzTenyBUw9euQjj9h7tAZr2PXO0z7w/EnAe7yXjsM=; b=bZ4eo9YaxS/u/ftDjfC4VRb9Tv2aUb5uQXeOrwD8TxlPyEMDqZLbaV8bcuVQbxJs27 Kz3XP2Yqe4XlRdlPELIzH1H6hpkcrxF6BtaCCgkAQJrk3ZkNm0q/QdJMV0t3TrXaZjbS ovM3gTKXhAhcSXzZ4JAK7kPyM2OKVyUGq7C8mTnnOzyGX7nJpD1BqEv9TDJfJH5kNsyU tg/zPHO3obf2lI64MQwzwrxVjT5bIucgRyWxJcuB4/ckXrV7QkpDa15uQ1mPS392Rjau Q3X85BvhrdXjFh+WJ0Ufxr4vs7/4pNwS1yIbPF8APngKfstXIcGuG0BKkIn7u4TNro// srkw== 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; bh=/sOzTenyBUw9euQjj9h7tAZr2PXO0z7w/EnAe7yXjsM=; b=OnvPRD+AqycGdMXFyhpOh9GVn9VbE0+FZbIj+jAzdM8R35XvWMMPfx9bCSrI99l8uX /sV28pZNdapdsfJ+5/CvgALOJ465x4/cNXmormQ3UzFfuVEsADsKaRoqx4MgR/lvbig6 v1VRJhCiR1qmxjFA+mWSaGCvGfY82LCzi1SjMUlZvYAlcxos1oqtjKz0SpWC/Xfa+3be ZOgpyHL8wg22+2ORx5Y6JCl2uNYxrAkL4i13IfpPsctubp+e2Ld322KkW3DMERwjZXwa RnNjHotBkSVhLgq8YcFKXaeeRXvDSiSvlB2T4whI1sRUudvVzRKI9STppSer7VeK6alE ZjOg== X-Gm-Message-State: AE9vXwMLhmW915VFfqdRjqX9jELbBTAcKJ+XZ5mrcktLZKXosvBEop9IirtJyyKqRIgu2KfcpLuG9w5fFRO2OVkb X-Received: by 10.13.231.199 with SMTP id q190mr26012626ywe.26.1474282841931; Mon, 19 Sep 2016 04:00:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.148.11 with HTTP; Mon, 19 Sep 2016 04:00:41 -0700 (PDT) In-Reply-To: <3993e58a01f4472992ae6fcdfaa8e0f7@IL-EXCH01.marvell.com> References: <2c34b139112a45ac9a68ff000aa7d934@IL-EXCH01.marvell.com> <3993e58a01f4472992ae6fcdfaa8e0f7@IL-EXCH01.marvell.com> From: Ben Laurie Date: Mon, 19 Sep 2016 12:00:41 +0100 Message-ID: To: Tal Mizrahi Content-Type: multipart/alternative; boundary=94eb2c08155217f89f053cda3903 Archived-At: Cc: "Karen ODonoghue \(odonoghue@isoc.org\)" , "secdir@ietf.org" , Suresh Krishnan , "draft-ietf-tictoc-multi-path-synchronization.all@tools.ietf.org" , "" Subject: Re: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 11:00:47 -0000 --94eb2c08155217f89f053cda3903 Content-Type: text/plain; charset=UTF-8 On 19 September 2016 at 01:34, Tal Mizrahi wrote: > Time protocols have a pretty unique property: even if you use the > strongest cryptographic mechanisms, the protocol can still easily be > attacked by a man-in-the-middle who simply adds a constant delay to some of > the packets, and thereby easily manipulates the protocol. The only way to > mitigate delay attacks is by redundancy: multiple time sources and/or > multiple network paths. Surely not - challenge/response, for example, would also reveal a delay. --94eb2c08155217f89f053cda3903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 19 September 2016 at 01:34, Tal Mizrahi <talmi@marvell.com> wrote:
Time protocols have a pretty un= ique property: even if you use the strongest cryptographic mechanisms, the = protocol can still easily be attacked by a man-in-the-middle who simply add= s a constant delay to some of the packets, and thereby easily manipulates t= he protocol. The only way to mitigate delay attacks is by redundancy: multi= ple time sources and/or multiple network paths.

Surel= y not - challenge/response, for example, would also reveal a delay.

--94eb2c08155217f89f053cda3903-- From nobody Mon Sep 19 04:06:46 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA2512B32C for ; Mon, 19 Sep 2016 04:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.316 X-Spam-Level: X-Spam-Status: No, score=-4.316 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOEwPtclv4bX for ; Mon, 19 Sep 2016 04:06:37 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 0E80D12B321 for ; Mon, 19 Sep 2016 04:06:37 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id i66so81829262yba.0 for ; Mon, 19 Sep 2016 04:06:37 -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; bh=dWaq9nu2g4K4vIMSHhnhXJGRBYclN1ZhwqYCAy1+6H4=; b=byCFWBXkySQ2kb4+BRilaYk9wWkuBh7FiSez3H/qAAHeR7OVDoJVqdU772CzcAhIoW ywcWtgNiBY3WnrMyZrS1YwRgI/+W9neQJV4Or8QnOh/aBdQLnlelivIO4OIHg7TPDI89 1f6CEPvXyfsq50PGgDEgaVrXLSW0MANSbFVSI82xpbO0+iI3uLzqMSzv208W6d0wc8Bb 2lcidJnr5btZAkKtAnZ7Mg0F/Cq9tB6HOEZrfwDoGwLAl7PD2QpG/4iNGVkYbUwasbdx mnUK/Hphs0ZNN9HMAbWOLX860sxJ+TizsyS+IbJSLGFddWSEKJA//yy6ntyoXS+9py0C 8e4A== 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; bh=dWaq9nu2g4K4vIMSHhnhXJGRBYclN1ZhwqYCAy1+6H4=; b=exBU0Xc9+SLjmhif6ZsYHrDGharMlicnghLQp6/WOQJfQ7ul4qPxm27ngAuoHW5zNT HOcOE4p5X9rWUuSKebUqvBxCyN5/5cdX8lYE++DLZ+wY2q0dyQtQSvYxPwgH8plT9NgS +CXgGESLG74NotH4pHO36W0NDisW5Nl8OJwuJR3ApxcZtU19yU6I64/D0EQL1bG3Wrgv zrTOklG+VXVxu0tgQygxHpRlute9rji0fOF473huXmwy3pUi+x80xGjmUG2pOJeU8v5S iZ+cM6wA+GXrZsLoj9kzfykZjABoz3GdcM0BPBYrKkISfz2vGGVwJnAtxPbiU6vU2Eol 4UKA== X-Gm-Message-State: AE9vXwOekfhkKgMP+t3Z47P7uwOwRiIvpjJFjsvGj6G+/P1zDMBU3teOobrv2PcEZSNH7J78/wNdKcaKC3eOX5Cl X-Received: by 10.37.112.213 with SMTP id l204mr25134045ybc.124.1474283195910; Mon, 19 Sep 2016 04:06:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.148.11 with HTTP; Mon, 19 Sep 2016 04:06:34 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Mon, 19 Sep 2016 12:06:34 +0100 Message-ID: To: "John R. Levine" Content-Type: multipart/alternative; boundary=001a114888503158b6053cda4eff Archived-At: Cc: Paul Kincaid-Smith , The IESG , Tobias Herkula , "secdir@ietf.org" Subject: Re: [secdir] [taugh.com-standards] Re:Security review of draft-levine-herkula-oneclick-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 11:06:39 -0000 --001a114888503158b6053cda4eff Content-Type: text/plain; charset=UTF-8 On 19 September 2016 at 00:36, John R. Levine wrote: > One other thought -- I think the most common thing that mailers do is to > put the subscriber info into a database where each record includes a > randomly generated key unrelated to anything else. Then you put that key > into the URI, no HMAC needed. > Yep. > > R's, > John > > > It's only a goal here because they have other ways to do it if it's not >>>> one-click. >>>> >>> >>> Ok, then in that case it seems like you only need to secure the POST >>> arguments, not the URI. >>> >> >> There's several scenarios that this draft is addressing: >> >> A) bad guy sends fake mail with real insecure opt-out link, MUA clicks it >> indirectly when user hits the junk button >> >> B) real message with real link is clicked by helpful anti-spam software, >> not the user >> >> The hash stuff is for A, the POST is for B. Since the POST gets both the >> URI and the arguments, the hash can be in whichever is operationally >> easier. All the places that have rules about commercial junk mail say that >> if the recipient tells you to stop, you have to stop and "the link was in a >> fake message" isn't a defense. It's quite common now for the unsubscribe >> URI to be totally opaque, e.g., with a hash and a key the mailer looks up >> in a database to find the recipient's address, so that malicious parties >> can't guess other subscribers' addresses. If they add POST arguments for >> one-click, they'll likely keep the existing opaque URI, and with the secure >> URI, the POST arguments tell it nothing beyond the fact that this is a >> one-click transaction. >> >> In the two decades since 2369 came out, the URI stuff has become common >> knowledge among the narrow group of people for whom "deliverability" is an >> adjective. I really don't want to open up 2369 with this draft, because I >> don't think the small amount this draft says would be helpful. It doesn't >> change the way people use 2369, it only adds a new way to do >> list-unsubscribe. >> > > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > --001a114888503158b6053cda4eff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 19 September 2016 at 00:36, John R. Levine <johnl@iecc.com> wrote:
One other thought -- I think t= he most common thing that mailers do is to put the subscriber info into a d= atabase where each record includes a randomly generated key unrelated to an= ything else.=C2=A0 Then you put that key into the URI, no HMAC needed.
<= /blockquote>

Yep.
=C2=A0

R's,
John


It's only a goal here because they have other ways to do it if it's= not
one-click.

Ok, then in that case it seems like you only need to secure the POST
arguments, not the URI.

There's several scenarios that this draft is addressing:

A) bad guy sends fake mail with real insecure opt-out link, MUA clicks it indirectly when user hits the junk button

B) real message with real link is clicked by helpful anti-spam software, no= t the user

The hash stuff is for A, the POST is for B.=C2=A0 Since the POST gets both = the URI and the arguments, the hash can be in whichever is operationally ea= sier.=C2=A0 All the places that have rules about commercial junk mail say t= hat if the recipient tells you to stop, you have to stop and "the link= was in a fake message" isn't a defense. It's quite common now= for the unsubscribe URI to be totally opaque, e.g., with a hash and a key = the mailer looks up in a database to find the recipient's address, so t= hat malicious parties can't guess other subscribers' addresses.=C2= =A0 If they add POST arguments for one-click, they'll likely keep the e= xisting opaque URI, and with the secure URI, the POST arguments tell it not= hing beyond the fact that this is a one-click transaction.

In the two decades since 2369 came out, the URI stuff has become common kno= wledge among the narrow group of people for whom "deliverability"= is an adjective.=C2=A0 I really don't want to open up 2369 with this d= raft, because I don't think the small amount this draft says would be h= elpful.=C2=A0 It doesn't change the way people use 2369, it only adds a= new way to do list-unsubscribe.

Regards,
John Levine, johnl@iecc= .com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--001a114888503158b6053cda4eff-- From nobody Mon Sep 19 06:24:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB8B127735; Mon, 19 Sep 2016 06:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWnrl1zh-F8w; Mon, 19 Sep 2016 06:24:08 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 7E72912B029; Mon, 19 Sep 2016 06:24:08 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8JDL8IJ017382; Mon, 19 Sep 2016 06:24:02 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 25h5bp0d99-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Sep 2016 06:24:01 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Sep 2016 16:23:59 +0300 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1104.000; Mon, 19 Sep 2016 16:23:58 +0300 From: Tal Mizrahi To: Ben Laurie Thread-Topic: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05 Thread-Index: AQHSEeSgVxkDrkl/jE+0/2Rx8wj6kqB/4pcA///YqYCAADiWMIAAgDWAgABXvyA= Date: Mon, 19 Sep 2016 13:23:57 +0000 Message-ID: References: <2c34b139112a45ac9a68ff000aa7d934@IL-EXCH01.marvell.com> <3993e58a01f4472992ae6fcdfaa8e0f7@IL-EXCH01.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_ff13c3a269a84fd8969171109ee8064cILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-19_08:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609190184 Archived-At: Cc: "Karen ODonoghue \(odonoghue@isoc.org\)" , "secdir@ietf.org" , Suresh Krishnan , "draft-ietf-tictoc-multi-path-synchronization.all@tools.ietf.org" , "" Subject: Re: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 13:24:12 -0000 --_000_ff13c3a269a84fd8969171109ee8064cILEXCH01marvellcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVuLA0KDQpKdXN0IHRvIGNsYXJpZnksIHdlIGFyZSB0YWxraW5nIGFib3V0IGFuIGF0dGFj a2VyIHRoYXQgYWRkcyBhIG1hbGljaW91cyBkZWxheSB0aGF0IG1heSBiZSBhcyBsb3cgYXMsIHNh eSBmaXZlIG1pY3Jvc2Vjb25kcyAoeWVzLCBtaWNyb3NlY29uZHMpIGJleW9uZCB0aGUg4oCYbm9y bWFs4oCZIHBhdGggZGVsYXkuIEEgZml2ZSBtaWNyb3NlY29uZCBhZGRpdGlvbmFsIGRlbGF5IGlz IGNlcnRhaW5seSBlbm91Z2ggdG8ga2lsbCB0aGUgcHJvdG9jb2wgaW4gdmFyaW91cyBlbnZpcm9u bWVudHMgc3VjaCBhcyBtb2JpbGUgYmFzZSBzdGF0aW9ucyBvciBwb3dlciBzdWJzdGF0aW9ucy4N Cg0KRml2ZSBtaWNyb3NlY29uZHMgaXMganVzdCBhbiBleGFtcGxlLiBUaGUgcG9pbnQgaXMgdGhh dCB0aGUgYXR0YWNrZXIgYWRkcyBzb21lIGFkZGl0aW9uYWwgZGVsYXkgd2hpY2ggaXMgYXQgbGVh c3QgYW4gb3JkZXIgb2YgbWFnbml0dWRlIGxvd2VyIHRoYW4gdGhlIHBhdGggZGVsYXkuDQoNCkNv cnJlY3QgbWUgaWYgSSBhbSB3cm9uZywgYnV0IGEgY2hhbGxlbmdlL3Jlc3BvbnNlIHdpbGwgcHJv YmFibHkgbm90IGJlIGVmZmVjdGl2ZSBpbiBkZXRlY3RpbmcgZGVsYXkgYXR0YWNrcyBpbiB0aGlz IG9yZGVyIG9mIG1hZ25pdHVkZS4NCg0KQmVzdCByZWdhcmRzLA0KVGFsLg0KDQpGcm9tOiBCZW4g TGF1cmllIFttYWlsdG86YmVubEBnb29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIg MTksIDIwMTYgMjowMSBQTQ0KVG86IFRhbCBNaXpyYWhpDQpDYzogV2F0c29uIExhZGQ7IGRyYWZ0 LWlldGYtdGljdG9jLW11bHRpLXBhdGgtc3luY2hyb25pemF0aW9uLmFsbEB0b29scy5pZXRmLm9y ZzsgS2FyZW4gT0Rvbm9naHVlIChvZG9ub2dodWVAaXNvYy5vcmcpOyA8aWVzZ0BpZXRmLm9yZz47 IFN1cmVzaCBLcmlzaG5hbjsgc2VjZGlyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NlY2Rpcl0g c2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXRpY3RvYy1tdWx0aS1wYXRoLXN5bmNocm9uaXph dGlvbi0wNQ0KDQoNCk9uIDE5IFNlcHRlbWJlciAyMDE2IGF0IDAxOjM0LCBUYWwgTWl6cmFoaSA8 dGFsbWlAbWFydmVsbC5jb208bWFpbHRvOnRhbG1pQG1hcnZlbGwuY29tPj4gd3JvdGU6DQpUaW1l IHByb3RvY29scyBoYXZlIGEgcHJldHR5IHVuaXF1ZSBwcm9wZXJ0eTogZXZlbiBpZiB5b3UgdXNl IHRoZSBzdHJvbmdlc3QgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc21zLCB0aGUgcHJvdG9jb2wgY2Fu IHN0aWxsIGVhc2lseSBiZSBhdHRhY2tlZCBieSBhIG1hbi1pbi10aGUtbWlkZGxlIHdobyBzaW1w bHkgYWRkcyBhIGNvbnN0YW50IGRlbGF5IHRvIHNvbWUgb2YgdGhlIHBhY2tldHMsIGFuZCB0aGVy ZWJ5IGVhc2lseSBtYW5pcHVsYXRlcyB0aGUgcHJvdG9jb2wuIFRoZSBvbmx5IHdheSB0byBtaXRp Z2F0ZSBkZWxheSBhdHRhY2tzIGlzIGJ5IHJlZHVuZGFuY3k6IG11bHRpcGxlIHRpbWUgc291cmNl cyBhbmQvb3IgbXVsdGlwbGUgbmV0d29yayBwYXRocy4NCg0KU3VyZWx5IG5vdCAtIGNoYWxsZW5n ZS9yZXNwb25zZSwgZm9yIGV4YW1wbGUsIHdvdWxkIGFsc28gcmV2ZWFsIGEgZGVsYXkuDQoNCg== --_000_ff13c3a269a84fd8969171109ee8064cILEXCH01marvellcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEJlbiw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkp1c3QgdG8gY2xhcmlmeSwgd2UgYXJlIHRhbGtpbmcgYWJvdXQgYW4gYXR0YWNr ZXIgdGhhdCBhZGRzIGEgbWFsaWNpb3VzIGRlbGF5IHRoYXQgbWF5IGJlIGFzIGxvdyBhcywgc2F5 IGZpdmUgbWljcm9zZWNvbmRzICh5ZXMsIG1pY3Jvc2Vjb25kcykgYmV5b25kIHRoZSDigJhub3Jt YWzigJkNCiBwYXRoIGRlbGF5LiBBIGZpdmUgbWljcm9zZWNvbmQgYWRkaXRpb25hbCBkZWxheSBp cyBjZXJ0YWlubHkgZW5vdWdoIHRvIGtpbGwgdGhlIHByb3RvY29sIGluIHZhcmlvdXMgZW52aXJv bm1lbnRzIHN1Y2ggYXMgbW9iaWxlIGJhc2Ugc3RhdGlvbnMgb3IgcG93ZXIgc3Vic3RhdGlvbnMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5GaXZlIG1pY3Jvc2Vjb25kcyBpcyBqdXN0IGFuIGV4YW1wbGUuIFRoZSBwb2lu dCBpcyB0aGF0IHRoZSBhdHRhY2tlciBhZGRzIHNvbWUgYWRkaXRpb25hbCBkZWxheSB3aGljaCBp cyBhdCBsZWFzdCBhbiBvcmRlciBvZiBtYWduaXR1ZGUgbG93ZXIgdGhhbiB0aGUgcGF0aA0KIGRl bGF5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Q29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLCBidXQgYSBjaGFsbGVuZ2Uv cmVzcG9uc2Ugd2lsbCBwcm9iYWJseSBub3QgYmUgZWZmZWN0aXZlIGluIGRldGVjdGluZyBkZWxh eSBhdHRhY2tzIGluIHRoaXMgb3JkZXIgb2YgbWFnbml0dWRlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UYWwuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1yaWdodDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBCZW4gTGF1cmllIFttYWlsdG86YmVubEBnb29n bGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgU2VwdGVtYmVyIDE5LCAyMDE2IDI6 MDEgUE08YnI+DQo8Yj5Ubzo8L2I+IFRhbCBNaXpyYWhpPGJyPg0KPGI+Q2M6PC9iPiBXYXRzb24g TGFkZDsgZHJhZnQtaWV0Zi10aWN0b2MtbXVsdGktcGF0aC1zeW5jaHJvbml6YXRpb24uYWxsQHRv b2xzLmlldGYub3JnOyBLYXJlbiBPRG9ub2dodWUgKG9kb25vZ2h1ZUBpc29jLm9yZyk7ICZsdDtp ZXNnQGlldGYub3JnJmd0OzsgU3VyZXNoIEtyaXNobmFuOyBzZWNkaXJAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZWNkaXJdIHNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi10 aWN0b2MtbXVsdGktcGF0aC1zeW5jaHJvbml6YXRpb24tMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE5IFNlcHRlbWJlciAyMDE2IGF0 IDAxOjM0LCBUYWwgTWl6cmFoaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhbG1pQG1hcnZlbGwuY29t IiB0YXJnZXQ9Il9ibGFuayI+dGFsbWlAbWFydmVsbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRpbWUgcHJvdG9jb2xzIGhhdmUgYSBwcmV0 dHkgdW5pcXVlIHByb3BlcnR5OiBldmVuIGlmIHlvdSB1c2UgdGhlIHN0cm9uZ2VzdCBjcnlwdG9n cmFwaGljIG1lY2hhbmlzbXMsIHRoZSBwcm90b2NvbCBjYW4gc3RpbGwgZWFzaWx5IGJlIGF0dGFj a2VkIGJ5IGEgbWFuLWluLXRoZS1taWRkbGUgd2hvIHNpbXBseSBhZGRzIGEgY29uc3RhbnQgZGVs YXkgdG8gc29tZSBvZiB0aGUgcGFja2V0cywgYW5kIHRoZXJlYnkNCiBlYXNpbHkgbWFuaXB1bGF0 ZXMgdGhlIHByb3RvY29sLiBUaGUgb25seSB3YXkgdG8gbWl0aWdhdGUgZGVsYXkgYXR0YWNrcyBp cyBieSByZWR1bmRhbmN5OiBtdWx0aXBsZSB0aW1lIHNvdXJjZXMgYW5kL29yIG11bHRpcGxlIG5l dHdvcmsgcGF0aHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NClN1cmVseSBub3QgLSBjaGFsbGVuZ2UvcmVzcG9uc2UsIGZvciBleGFtcGxlLCB3b3Vs ZCBhbHNvIHJldmVhbCBhIGRlbGF5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_ff13c3a269a84fd8969171109ee8064cILEXCH01marvellcom_-- From nobody Mon Sep 19 07:12:51 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868FA12B347; Mon, 19 Sep 2016 07:12:48 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPPy8GKNCwAg; Mon, 19 Sep 2016 07:12:44 -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 3D81E12B17C; Mon, 19 Sep 2016 07:12:44 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8JECdWY018186 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Sep 2016 17:12:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8JECcWH006233; Mon, 19 Sep 2016 17:12:38 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22495.62038.771947.984586@fireball.acr.fi> Date: Mon, 19 Sep 2016 17:12:38 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 27 min X-Total-Time: 36 min Archived-At: Subject: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 14:12:48 -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 document describes adding new IPv6 destination option header to allow performance metrics calculations. I think this document has serious issues. It proposes that the new Destination option MUST be put before the ESP so it is sent in clear. This will leak out the traffic information from the ESP, allowing easy traffic analysis of encrypted packets, as passive attacker can see which encrypted ESP packets belong to which 5-tuple flow. The PDM option header includes the incrementing sequence numbers, so checking those will allow see which packet belongs to which flow. It claims that PDM MUST be placed before the ESP header in order to work, which is untrue. This is destination option, thus it is meant to be checked on the destination host, i.e., the packet capture after the ESP decryption will allow seeing the PDM header values without issues. -- Also the Time Base definations seem to be inconsistent. The section 3.2 says: That is, for a value of 00 in the Time Base field, a value of 1 in the DELTA fields indicates 1 microsecond. Section 4.4 on other hand claims: That is, for a value of 00 in the Time Base field, a value of 1 in the DELTA fields indicates 1 picosecond. On the other hand looking at the table in both 3.2 and 4.4 it seems that time base value field value of 00 means milliseconds, not microseconds or picoseconds. Again section 4.5 says that "TimeBase of picosecond (or 00)", and again I think picoseconds was supposed to be Time Base of 11... The whole section 4 seems to be wierd. It is talking about different encodings, and time units on different systems, and it also talks about the limitations on TCP Timestamp Option, but this option uses different encoding so I have no idea why this text is here. It would be more useful to count what are the limits on the encoding method used here (16 bit value, 7 bit signed scaling value), instead of what some other option use. In section 5.3 in the example it converts 4 seconds to hex value of 3A35 and scale of 25. On the other hand it is using milliseconds as Time Base, so I think those values are wrong, i.e. 4 seconds in milliseconds is 4000 milliseconds, thus FA0 with scale of 0 would be correct represetnation. Same mistake in 5.4. -- I skipped most of the section 6 and 7, so cannot say if similar mistakes are in those sections. -- The section 8 is wrong as it claims "PDM does not introduce any new security weakness." while this will leak lots of information about the traffic flows inside the encrypted transport mode ESP packets. Also another thing the PDM leaks is exact host timings, i.e., it can be used to launch timing attacks against crypto protocols. In general those are hard as it is very hard to know how much of n ms rtt is network delay and how much was the actual host processing the packet. Now if we can see that that host used 123 nanoseconds to process the signature verification packet, and next time it uses 1755 nanoseconds, this might allow attacker to get information out from the key. The actual round trip times might have been 123 ms in both cases, and the 1 microsecond difference in the processing time would have been lost by the network latencies. In addition to that the abstract is not very clear, it does not do very good job of telling that this draft tries to do, and having the Background section to duplicate most of that text does not still what this document really tries to do. -- kivinen@iki.fi From nobody Mon Sep 19 07:41:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9998C12B3CF; Mon, 19 Sep 2016 07:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hfaKU8BP0Zf; Mon, 19 Sep 2016 07:41:37 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 8A25C12B3E5; Mon, 19 Sep 2016 07:41:36 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id t67so147943316ywg.3; Mon, 19 Sep 2016 07:41:36 -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-transfer-encoding; bh=JNDC2VSS2CyDG/VoeC+Uf8Qs6eQ+aRlbnDYaWhFWnGQ=; b=OLEb8h8LXSDNKHapsIqtC0I+Fyin15I/7bYAeCyPB9tHdSpdOTg7G+0fCPLDp7lLoF LVr4smlghMn5Pc0wYQ+306HCBrcNEXWfihJpXqn4tVV9HCNDN8fJN7lmgB8Xm1cz37ma DE0LYkICPOvvLTWwToHpYrKuAoSwFa1zNzSjnR19zDfHC0Vh59hxWryVsOJnvoT/OBDI wvkGtR6mjxxKsp43tXDd87w2RVAssCyGupTNA2cTugfs126WBkxB9HJRE+soi5Fro1Jq 6w4kvPoFaAlzzwy+LEcnjy1vzfWizzFxBh7FezAGZsnb9fE9hBqvDdTUGWyH9/l00Trb 7i0g== 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-transfer-encoding; bh=JNDC2VSS2CyDG/VoeC+Uf8Qs6eQ+aRlbnDYaWhFWnGQ=; b=MPBN10RR/wqHqKmHY1qD9A1wWYN6D42qdiG1x8VHieBywSCoecOWmt/h9mWsLRcBVn ZhKWDjbiCDwzkJi01nyKJq59UygHanmSnh7lzSHLXDZ5KktW3ZJpux8GeJrRDZryKLzl djmU3yZE1ZXkm2Vb6pz3/hPyPBFoNeezWhHafDWqBWlwDp4FYw+ixy75CCN/QNcUJZdx 40zQkZgoaheQEq3mk3jVXou2a4jX7v8LYS2+tkFKBALOOJ3fVF5tk3Sd47V9xzy0k+XP RzPFIscXW76fUlVilYtq6pIKvHwvr6uf2iiDwHusFBB16TkW8Y9MTYU4RlPovHyV94A8 DBrA== X-Gm-Message-State: AE9vXwPAmjhbXSscJjiTZ4lUgPhjP/jtITGBDKxBHnlVXwuPX1ppTg4ZqbTj1/U0iklDfwyio7EL/Ort1HLHZg== X-Received: by 10.13.252.132 with SMTP id m126mr24914293ywf.307.1474296095683; Mon, 19 Sep 2016 07:41:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.102 with HTTP; Mon, 19 Sep 2016 07:41:35 -0700 (PDT) In-Reply-To: <3993e58a01f4472992ae6fcdfaa8e0f7@IL-EXCH01.marvell.com> References: <2c34b139112a45ac9a68ff000aa7d934@IL-EXCH01.marvell.com> <3993e58a01f4472992ae6fcdfaa8e0f7@IL-EXCH01.marvell.com> From: Watson Ladd Date: Mon, 19 Sep 2016 07:41:35 -0700 Message-ID: To: Tal Mizrahi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-ietf-tictoc-multi-path-synchronization.all@tools.ietf.org" , "Karen ODonoghue \(odonoghue@isoc.org\)" , "" , Suresh Krishnan , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 14:41:41 -0000 On Sun, Sep 18, 2016 at 5:34 PM, Tal Mizrahi wrote: > Dear Watson, > > Thanks for the prompt response. > >>Multipath shouldn't be discussed as a security measure at all. My reading= of >>the document was that it was simply to get more reliable packet delays an= d >>synchronization. You cannot throw this claim into the security considerat= ions >>alone without explaining the rest of the picture. Why not remove it entir= ely? >> > > The multi-path scheme addresses both an accuracy issue and a security iss= ue. The security aspect is mentioned well before the security consideration= s section, including in the abstract and in the introduction. What should a client do with multipath to integrate the data in a way that is strong against malicious delays inserted even on one path? This draft says there are various discussed algorithms, but some (like pure Kalman filtering, which the draft suggests) won't be robust against adversarial manipulation. It needs to say more about this! > >>Real attackers get the job done: they grab the community strings and use >>them to own every single router you have, or own the sysadmins PC and go >>for all the routers at once. And it's not uncommon for machines to be >>connected to only one router: most desktops and laptops have a single >>Ethernet port. The proposed text makes extremely common things sound >>rare. > > Time protocols have a pretty unique property: even if you use the stronge= st cryptographic mechanisms, the protocol can still easily be attacked by a= man-in-the-middle who simply adds a constant delay to some of the packets,= and thereby easily manipulates the protocol. The only way to mitigate dela= y attacks is by redundancy: multiple time sources and/or multiple network p= aths. > The delay attack is one of the most significant threats in time protocols= , and therefore we defined delay attack protection as a MUST in RFC 7384. > Security is an important aspect of multi-path synchronization, and I beli= eve the current draft has to talk about this aspect. Just because you demanded that a certain solution have a property doesn't mean it actually has that property. In fact RFC 7384 is unreasonably strong: most applications can survive with degraded clocks and degrading the clock accuracy (say to an amount depending on observed roundtrip time) is probably acceptable, and in the face of the standard network attacker (who manipulates all packets at will) this is the best we can do. Multipath is extremely limited as a mitigation technique. Given the demands the systems you are discussing place on reliable timing (to the point where downthread you indicate microseconds required) multipath shouldn't be considered effective. If you really need microseconds secure timing, and actually need things to be secure you need to trust at least one path. > > Best regards, > Tal. > > > >>-----Original Message----- >>From: Watson Ladd [mailto:watsonbladd@gmail.com] >>Sent: Monday, September 19, 2016 2:59 AM >>To: Tal Mizrahi >>Cc: ; secdir@ietf.org; draft-ietf-tictoc-multi-path- >>synchronization.all@tools.ietf.org; Suresh Krishnan; Karen ODonoghue >>(odonoghue@isoc.org) >>Subject: Re: secdir review of draft-ietf-tictoc-multi-path-synchronizatio= n-05 >> >>On Sun, Sep 18, 2016 at 4:22 PM, Tal Mizrahi wrote: >>> Dear Watson, >>> >>> Thanks for reviewing the draft. >>> >>> To address your comments, I would like to suggest the following text fo= r the >>Security Considerations section. >>> Please let us know if this addresses the comments: >>> >>> >>> The security aspects of time synchronization protocols are discussed in >>detail in [TICTOCSEC]. The methods describe in this document propose to r= un >>a time synchronization protocol through redundant paths, and thus allow t= o >>detect and mitigate man-in-the-middle attacks, as described in [DELAY-ATT= ]. >>It should be noted that when using multiple paths, these paths may partia= lly >>overlap, and thus an attack that takes place in a common segment of these >>paths is not mitigated by the redundancy. Moreover, an on-path attacker m= ay >>in some cases have access to more than one router, or may be able to >>migrate from one router to another. Therefore, when using multiple paths = it is >>important for the paths to be as diverse and as independent as possible, >>making the redundancy scheme more tolerant to on-path attacks. >> >>Multipath shouldn't be discussed as a security measure at all. My reading= of >>the document was that it was simply to get more reliable packet delays an= d >>synchronization. You cannot throw this claim into the security considerat= ions >>alone without explaining the rest of the picture. Why not remove it entir= ely? >> >>Real attackers get the job done: they grab the community strings and use >>them to own every single router you have, or own the sysadmins PC and go >>for all the routers at once. And it's not uncommon for machines to be >>connected to only one router: most desktops and laptops have a single >>Ethernet port. The proposed text makes extremely common things sound >>rare. >> >>> >>> >>> >>> Regards, >>> Tal. >>> >>>>-----Original Message----- >>>>From: Watson Ladd [mailto:watsonbladd@gmail.com] >>>>Sent: Sunday, September 18, 2016 10:41 PM >>>>To: ; secdir@ietf.org; draft-ietf-tictoc-multi-path- >>>>synchronization.all@tools.ietf.org >>>>Subject: secdir review of >>>>draft-ietf-tictoc-multi-path-synchronization-05 >>>> >>>>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 presents a mechanism for servers and clients to conduct >>>>synchronization protocols over multiple paths. I didn't see anything >>>>wrong with the mechanism, but I am worried that its security benefits >>>>are >>>>overstated: independent paths may only be partially independent, and >>>>attackers can easily migrate from one router to another in most network= s. >>>> >>>>Sincerely, >>>>Watson Ladd >> >> >> >>-- >>"Man is born free, but everywhere he is in chains". >>--Rousseau. --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Sep 19 07:57:27 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEF312B3FF for ; Mon, 19 Sep 2016 07:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfrExeBCIAfN for ; Mon, 19 Sep 2016 07:57:18 -0700 (PDT) Received: from nm28-vm1.bullet.mail.ne1.yahoo.com (nm28-vm1.bullet.mail.ne1.yahoo.com [98.138.91.35]) (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 0526A12B400 for ; Mon, 19 Sep 2016 07:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1474297036; bh=6toqydDOLjFbTusQU6VZ7XJW2qE4lBPmEZi6h4ETuDY=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Q9FM1buA7NVLD0prCaJKrTy4kaTzNqyepjWeiBYVamaO/buzWjHqmqZ9+gD2l2/8JimVpU6ZljJ+SsI70+p+/fOgRUO5DQjpJ6P9BqSiHq5aoG/jAm4/RLKQx4faCvjHL3SMRJ8v/LK7Rsf5f6Pwt9EMf+GZbk7TzqN34GggMOlagccNIXeXgjqsEV4CLJu02YsgzlxtkBSs1xB1OrOwUHT3NBO6/Yz5hr8aUT+Yc8hyVf16b96HbfO8xrjp/aGnvXYr9OIrXjiAAvofZdb5NXDAwzUB567WoHNi1O0A3tLgV3d7hM4zh8G0tCED7qwzKG4MuPV2Uqzwtcfb9TC9lw== Received: from [98.138.226.180] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2016 14:57:16 -0000 Received: from [98.138.89.192] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2016 14:57:16 -0000 Received: from [127.0.0.1] by omp1050.mail.ne1.yahoo.com with NNFMP; 19 Sep 2016 14:57:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 83775.29007.bm@omp1050.mail.ne1.yahoo.com X-YMail-OSG: fmtgN1AVM1lQ6.mq0E8O.jJqykCY7b9vubF5fQcTjxatPHDAYZWepfPdIiMu3CJ _frK1HqWikX_I7aDsT4gFRMSbGXzUKumbAs6zXpWihPRXF1tETRo3SXQt.UXnm5OdTnVy4y2keNE mdOiJrHY.l98wOVG76PQTboYaEckzn9MNY9AuUzDxPNGneyWU8u0IGSqpJSnE32bnsMCwO0u0VOb 4s3iUjabSAiXv3QICZkR2B.W6J1UJZqnj_dCAL01YGuGb6Ckl7Ska7u0dVI_DGvAtbQz_FC4xLnw vYfmeX6hTUxFayCNSHqeXXFVQyMyh16ls0rpvBdGUgr6urfjpYhaS9wvxsWx7TYAdv_DbSwJ1aqJ WCM984VjQm3kM80fX1JwqNylxjT3CMbg3XsrIQXpvCR0dmpL4G.ej5m8QD6XY0ucK9Oj5EP8VuPL XkytjL5YvTqu_a5eFmufFcyHyZF2A94qIY8BIajj6lWtf3lpPQe_n.Z7QQjwWLCMQmuHzCfbL.Rp xcFTvAldC1G_hLjyKPNPdZLxESra3SsXgpBhGcHxA9Mey6fogM2_tJUUJ8FAThkCjAy2Trj55 Received: from jws100105.mail.ne1.yahoo.com by sendmailws133.mail.ne1.yahoo.com; Mon, 19 Sep 2016 14:57:15 +0000; 1474297035.655 Date: Mon, 19 Sep 2016 14:57:15 +0000 (UTC) From: To: Tero Kivinen , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" Message-ID: <2079549486.943099.1474297035246@mail.yahoo.com> In-Reply-To: <22495.62038.771947.984586@fireball.acr.fi> References: <22495.62038.771947.984586@fireball.acr.fi> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_943097_163803426.1474297035239" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 14:57:22 -0000 ------=_Part_943097_163803426.1474297035239 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tero, Thank you for your comments. =C2=A0We will review and get back to you on th= em later today. =C2=A0But, first, let me address one thing which may be a m= isunderstanding of PDM. 1. =C2=A0PDM is OFF initially at the end hosts (client and server) 2. =C2=A0It is turned ON for diagnostics then turned OFF afterwards. =C2=A0= If someone chooses to leave PDM ON always, then that is explicitly chosen f= or their network. 3. =C2=A0PDM is an OPTIONAL feature. =C2=A0One may choose not to implement = it at all. To address some of your comments about leakage, etc. Let's discuss how this might happen: 1. =C2=A0Attacker obtains access to either or both end host client and serv= er and turns on PDM=C2=A0 2. =C2=A0Attacker watches passively. Actually the problem is 1. =C2=A0If you have done that, what do you need PD= M for? =C2=A0 Many other things can be found - such as type of device, etc = without resorting to PDM.=C2=A0=C2=A0Thanks, Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360 From: Tero Kivinen To: iesg@ietf.org; secdir@ietf.org; draft-ietf-ippm-6man-pdm-option.all@to= ols.ietf.org=20 Sent: Monday, September 19, 2016 7:12 AM Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-05 =20 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat these comments just like any other last call comments. This document describes adding new IPv6 destination option header to allow performance metrics calculations. I think this document has serious issues. It proposes that the new Destination option MUST be put before the ESP so it is sent in clear. This will leak out the traffic information from the ESP, allowing easy traffic analysis of encrypted packets, as passive attacker can see which encrypted ESP packets belong to which 5-tuple flow. The PDM option header includes the incrementing sequence numbers, so checking those will allow see which packet belongs to which flow. It claims that PDM MUST be placed before the ESP header in order to work, which is untrue. This is destination option, thus it is meant to be checked on the destination host, i.e., the packet capture after the ESP decryption will allow seeing the PDM header values without issues. -- Also the Time Base definations seem to be inconsistent. The section 3.2 says: =C2=A0 That is, for a value of 00 in the Time Base field, a value of 1 in =C2=A0 the DELTA fields indicates 1 microsecond. Section 4.4 on other hand claims: =C2=A0 That is, for a value of 00 in the Time Base field, a value of 1 in =C2=A0 the DELTA fields indicates 1 picosecond. On the other hand looking at the table in both 3.2 and 4.4 it seems that time base value field value of 00 means milliseconds, not microseconds or picoseconds. Again section 4.5 says that "TimeBase of picosecond (or 00)", and again I think picoseconds was supposed to be Time Base of 11... The whole section 4 seems to be wierd. It is talking about different encodings, and time units on different systems, and it also talks about the limitations on TCP Timestamp Option, but this option uses different encoding so I have no idea why this text is here. It would be more useful to count what are the limits on the encoding method used here (16 bit value, 7 bit signed scaling value), instead of what some other option use. In section 5.3 in the example it converts 4 seconds to hex value of 3A35 and scale of 25. On the other hand it is using milliseconds as Time Base, so I think those values are wrong, i.e. 4 seconds in milliseconds is 4000 milliseconds, thus FA0 with scale of 0 would be correct represetnation. Same mistake in 5.4. -- I skipped most of the section 6 and 7, so cannot say if similar mistakes are in those sections. -- The section 8 is wrong as it claims =C2=A0=C2=A0=C2=A0 "PDM does not introduce any new security weakness." while this will leak lots of information about the traffic flows inside the encrypted transport mode ESP packets. Also another thing the PDM leaks is exact host timings, i.e., it can be used to launch timing attacks against crypto protocols. In general those are hard as it is very hard to know how much of n ms rtt is network delay and how much was the actual host processing the packet. Now if we can see that that host used 123 nanoseconds to process the signature verification packet, and next time it uses 1755 nanoseconds, this might allow attacker to get information out from the key. The actual round trip times might have been 123 ms in both cases, and the 1 microsecond difference in the processing time would have been lost by the network latencies. In addition to that the abstract is not very clear, it does not do very good job of telling that this draft tries to do, and having the Background section to duplicate most of that text does not still what this document really tries to do.=20 --=20 kivinen@iki.fi =20 ------=_Part_943097_163803426.1474297035239 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tero,

Thank you for your comments. =  We will review and get back to you on them later today.  But, fi= rst, let me address one thing which may be a misunderstanding of PDM.

1.  PDM is OF= F initially at the end hosts (client and server)

<= div dir=3D"ltr" id=3D"yui_3_16_0_1_1474296269631_8128">2.  It is turned ON for diagnostics = then turned OFF afterwards.  If someone chooses to leave PDM ON always= , then that is explicitly chosen for their network.

3.=  PDM is an OPTIONAL feature.  One may choose not to implement it= at all.


To address some of your comments about leakage, etc.

Let's discuss= how this might happen:

<= span style=3D"font-family: HelveticaNeue, "Helvetica Neue", Helve= tica, Arial, "Lucida Grande", sans-serif;" id=3D"yui_3_16_0_1_147= 4296269631_8134">1.  Attacker obtains access to either or both end hos= t client and server and turns on PDM 

2.  Attacker watches passively.

Actually the problem is 1.  If you have don= e that, what do you need PDM for?   Many other things can be found - s= uch as type of device, etc without resorting to PDM.
 
 
Thanks,

=
Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360=


=
=
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org; secdir@ietf.org; draft-i= etf-ippm-6man-pdm-option.all@tools.ietf.org
Sent: Monday, September 19, 2016 7:12 AM
Subject: Secdir review of draft-i= etf-ippm-6man-pdm-option-05

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

This docume= nt describes adding new IPv6 destination option header to
allow performa= nce metrics calculations.

I think this document has serious issues.<= br>
It proposes that the new Destination option MUST be put before the E= SP
so it is sent in clear. This will leak out the traffic informationfrom the ESP, allowing easy traffic analysis of encrypted packets, as
p= assive attacker can see which encrypted ESP packets belong to which
5-tu= ple flow. The PDM option header includes the incrementing sequence
numbe= rs, so checking those will allow see which packet belongs to
which flow.=

It claims that PDM MUST be placed before the ESP header in order to=
work, which is untrue. This is destination option, thus it is meant to<= br>be checked on the destination host, i.e., the packet capture after theESP decryption will allow seeing the PDM header values without issues.
--

Also the Time Base definations seem to be inconsistent. The = section
3.2 says:

  That is, for a value of 00 in the Time = Base field, a value of 1 in
  the DELTA fields indicates 1 microse= cond.

Section 4.4 on other hand claims:

  That is, for = a value of 00 in the Time Base field, a value of 1 in
  the DELTA = fields indicates 1 picosecond.

On the other hand looking at the tabl= e in both 3.2 and 4.4 it seems
that time base value field value of 00 me= ans milliseconds, not
microseconds or picoseconds.

Again section = 4.5 says that "TimeBase of picosecond (or 00)", and
again I think picose= conds was supposed to be Time Base of 11...

The whole section 4 seem= s to be wierd. It is talking about different
encodings, and time units o= n different systems, and it also talks
about the limitations on TCP Time= stamp Option, but this option uses
different encoding so I have no idea = why this text is here. It would
be more useful to count what are the lim= its on the encoding method
used here (16 bit value, 7 bit signed scaling= value), instead of what
some other option use.

In section 5.3 in= the example it converts 4 seconds to hex value of
3A35 and scale of 25.= On the other hand it is using milliseconds as
Time Base, so I think tho= se values are wrong, i.e. 4 seconds in
milliseconds is 4000 milliseconds= , thus FA0 with scale of 0 would be
correct represetnation. Same mistake= in 5.4.

--

I skipped most of the section 6 and 7, so cannot = say if similar
mistakes are in those sections.

--

The sect= ion 8 is wrong as it claims

    "PDM does not introdu= ce any new security weakness."

while this will leak lots of informat= ion about the traffic flows
inside the encrypted transport mode ESP pack= ets.

Also another thing the PDM leaks is exact host timings, i.e., i= t can
be used to launch timing attacks against crypto protocols. In gene= ral
those are hard as it is very hard to know how much of n ms rtt isnetwork delay and how much was the actual host processing the packet.
N= ow if we can see that that host used 123 nanoseconds to process the
sign= ature verification packet, and next time it uses 1755 nanoseconds,
this = might allow attacker to get information out from the key. The
actual rou= nd trip times might have been 123 ms in both cases, and the
1 microsecon= d difference in the processing time would have been lost
by the network = latencies.

In addition to that the abstract is not very clear, it do= es not do
very good job of telling that this draft tries to do, and havi= ng the
Background section to duplicate most of that text does not still = what
this document really tries to do.
--
kivinen@iki.fi

------=_Part_943097_163803426.1474297035239-- From nobody Wed Sep 21 06:27:05 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304E612B2C1; Wed, 21 Sep 2016 06:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59Xx5Y3Gc1Q0; Wed, 21 Sep 2016 06:27:01 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E0412B2B6; Wed, 21 Sep 2016 06:25:59 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id n185so45092585qke.1; Wed, 21 Sep 2016 06:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=VdTo2W35pmNjdjWuK0Fp5auoR1Yo+JGL+/z9J17ltYI=; b=Jgqb3RtMNm8E3gFz7a2BMfoQPPDTmZrTb3yGUMj6QYzzqULfGIz4+xuPVcKkBbUcto es34jsAAjLe0Ae0rg/XVQqb4YCHxGzf1GKuHt8MmJyyn2ZsCbi3DsPW/5XrnJKh5NB+U /nFmT4icj26z8opTgQFEywdaLXtFivwvlCAkstljJUbkKe5txeQ5vHSroMnA4aUXrbN2 ELOPSHpVSIJ+4/H2vDqP0lrG4/kVNVPhR2Ik/6shjYxAmPDyyR7L7Kh3QZQYtEGXxta9 vuV2m8ZkhsN81eo7MwTwkkJkBVOLHztqGQYgj9m6Je63E0m1olKuzdhhdumJNdBDZyIz N9rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=VdTo2W35pmNjdjWuK0Fp5auoR1Yo+JGL+/z9J17ltYI=; b=jgnAo+LT7pXMy+xcAJBfp1pa0QG45z1dgIPabMN6aoUhZg7Pqw24rJgOwYuzHXuxDS RYiZdxmPXGnhI/WqdNqKWsw0ne0JMxH33g6rVoxgfXkZHrwh912PMb046aVMGFx8jroB KLm6CgOEx8VImRotVegMnR8Wt8OZS0SFKLpO1keXD4p0gMdKunHiuitgTq1I0NjZKm4L XKfHwGn2Dfn1QMMCTJEU8olMYOBJVX17BwytVsp86fwJa9jC3zBMKwyiocrUiZJtfIGb OXODsQnzFiqUHY3JF6Oa+015n0M3Lund+uPo3+of0Wj3NHNJFNvzBdsOUkYheeXllNN+ 8VUQ== X-Gm-Message-State: AE9vXwO70INX4mjPX0TpoecM9wha/qQHnXhJyOKdcDKu8YT2dAGSeyLDio3HXSSlwboiNZWrwwP4aytglUEqLw== X-Received: by 10.55.220.193 with SMTP id v184mr31799393qki.303.1474464358268; Wed, 21 Sep 2016 06:25:58 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.140.39.52 with HTTP; Wed, 21 Sep 2016 06:25:57 -0700 (PDT) From: Barry Leiba Date: Wed, 21 Sep 2016 14:25:57 +0100 X-Google-Sender-Auth: vdI3F-mteAiQr9lImUjl49tJIIA Message-ID: To: draft-murchison-nntp-compress.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IESG , secdir@ietf.org Subject: [secdir] Secdir review of draft-murchison-nntp-compress-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 13:27:03 -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. There are no major issues here, but there are a number of things I think need to be addressed before this document is ready. References: RFC 1951 (DEFLATE) MUST be implemented with this, so it needs to be a normative reference. -- Section 2.1 -- This document defines one compression algorithm: DEFLATE. This algorithm is mandatory to implement and MUST be supported in order to advertise the COMPRESS extension. Just to be clear and specific, I suggest changing the second sentence to say "and MUST be supported and listed in the advertisement of the COMPRESS extension." -- Section 2.2.2 -- In order to help mitigate leaking authentication credentials via for instance a CRIME attack [CRIME], authentication SHOULD NOT be attempted when a compression layer is active. Consequently, a server SHOULD NOT return any arguments with the AUTHINFO capability label (or SHOULD NOT advertise it at all) in response to a CAPABILITIES command received from an unauthenticated client after a compression layer is active, and such a client SHOULD NOT attempt to utilize any AUTHINFO [RFC4643] commands. It implies that a server SHOULD reply with a 502 response code if a syntactically valid AUTHINFO command is received while a compression layer is already active. Why are these SHOULD, and not MUST? Under what conditions would it be necessary or reasonable for an implementation not to abide by these, and what considerations need to be considered when making that determination? (And this is also directly referred to in Section 6.) When compression is active and either the client or the server receives invalid or corrupted compressed data, the receiving end SHOULD immediately close the connection. (Then the sending end will in turn do the same.) Same question. -- Section 2.3 -- At the end of the first example, it would be useful to add another CAPABILITIES command to show that COMPRESS DEFLATE is no longer listed. -- Section 5 -- This section contains a list of each new response code defined in this document and indicates whether it is multi-line, which commands can generate it, what arguments it has, and what its meaning is. This is a total nit, but this sentence seems odd when there's only one new code (there's also nothing that says whether it is or isn't multi-line). I suggest, instead, "The following new response code is defined in this document:". -- Section 6 -- NNTP commands other than AUTHINFO are not believed to divulgate confidential information Qu'est que c'est "divulgate"? Perhaps you mean "divulge", unless you're Shakespeare. In case confidential articles are accessed in private newsgroups, special care is needed: implementations SHOULD NOT compress confidential data together with public data when a security layer is active, for the same reasons as mentioned above in this Section. Sorry: it is not clear to me what reasons those are; can you be specific here? And why SHOULD, and not MUST? Additionally, implementations MAY ensure that the contents of two distinct confidential articles are not compressed together. Of course they MAY, but what's the point of saying that. I think you'd be much better off skipping the 2119 key word here, and instead say something about why it might be good to do this: what's the advantage? Something like, "Additionally, implementations would do well to ensure that the contents of two distinct confidential articles are not compressed together, because [of this advantage]." Future extensions to NNTP that define commands conveying confidential data SHOULD ensure to state that these confidential data SHOULD NOT be compressed together with public data when a security layer is active. I guess this is related the the paragraph I quoted immediately above, so the question is the same. -- Section 7.1 -- Any name that conforms to the syntax of an NNTP compression algorithm name (Section 4.3) can be used. It would be useful here, for IANA's benefit, to specifically highlight that letters in algorithm names are always upper case. However, the name of a registered NNTP compression algorithm MUST NOT begin with "X". To avoid the risk of a clash with a future registered NNTP compression algorithm, the names of private compression algorithms SHOULD begin with "X-". This was discussed in response to another review, and I understand the "X-" stuff will be removed. Thanks. If it does not implement the compression algorithm as specified, it MUST NOT list its registered name in the arguments list of the COMPRESS capability label. In that case, it MAY, but SHOULD NOT, provide a private algorithm (not listed, or listed with a different name) that implements the compression algorithm differently. Oy. This really sounds convoluted to me, and the "MAY, but SHOULD NOT" is a direct contradiction. I think what you're trying to say here is that if you list a registered algorithm, it MUST be properly implemented according to the relevant spec. Got that. Now, what about including unregistered algorithms? Do you want to say that you MAY include unregistered algorithms? Do you want to say that you SHOULD NOT include any? Why not, and why might you decide to do that anyway? What are the interoperability issues with respect to unregistered algorithms? A server MUST NOT send different response codes to COMPRESS in response to the availability or use of a private compression algorithm. I don't understand what this is saying at all. Different from what? Can you clarify this? -- Barry From nobody Wed Sep 21 07:27:00 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01AC12B19C for ; Wed, 21 Sep 2016 07:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w7SfcbVFjnp for ; Wed, 21 Sep 2016 07:26:56 -0700 (PDT) Received: from bos-mailout2.raytheon.com (bos-mailout2.raytheon.com [199.46.198.208]) (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 121AC12B1A5 for ; Wed, 21 Sep 2016 07:26:54 -0700 (PDT) Received: from ma-mailout10.rtnmail.ray.com (ma-mailout10.rtnmail.ray.com [147.25.130.27]) by bos-mailout2.raytheon.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u8LEQekU025757 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Sep 2016 14:26:40 GMT Received: from smtp.bbn.com ([128.33.1.81]) by ma-mailout10.rtnmail.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id u8LEQbBU025198 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Wed, 21 Sep 2016 14:26:37 GMT Received: from ssh.bbn.com ([192.1.122.15]:46841 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bmiTs-0006Pg-Ue; Wed, 21 Sep 2016 10:26:37 -0400 To: secdir , Jim Schaad , Justin Richer , Kepeng Li , Kathleen Moriarty From: Stephen Kent Message-ID: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> Date: Wed, 21 Sep 2016 10:26:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------718207C49D1628D772C3EC0D" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-21_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609210259 Archived-At: Subject: [secdir] secdir review of cose-msg-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 14:26:59 -0000 This is a multi-part message in MIME format. --------------718207C49D1628D772C3EC0D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit SECDIR review of draft-ietf-cose-msg-18 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written with the intent of improving security requirements and considerations in IETF drafts.Comments not addressed in last call may be included in AD reviews during the IESG review.Document editors and WG chairs should treat these comments just like any other last call comments. This document defines formats for signing and/or encryption of data encoded using CBOR (RFC7049). The signing/encryption approach adopted here is based on the standards developed in JOSE (RFCs 7515-18), since CBOR is based on JSON. This is a large document: about 90 pages plus almost 30 pages of appendices (providing useful examples). Close to half of the (non-appendix portion) document is devoted to specifications for a set of algorithms for encryption, signatures, message authentication, and key distribution. Only when the reader reaches page 73 is it made clear that the algorithm descriptions are not MTI; they define a set from which application developers must (?) choose when creating a profile for COSE use in a specific application context. Given the long-standing IETF policy to trying to facilitate algorithm agility, I think it preferable to extract these descriptions and publish them as separate RFCs, a practice often employed in documenting many other security protocols (including JOSE, from which this work is based). The document begins with a brief explanation of how COSE differs from JOSE, an excellent preface to the document. The cited design differences all seem very appropriate for CBOR, e.g., using binary encoding instead of base64url, shedding some of the odd constraints adopted in JOSE because of pre-existing work in the area, and updating the list of algorithms. Since there is no standard grammar for CBOR, the author adopted the primitive types defined in an I-D (draft-ietf- greevenbosch-appsawg-cbor-cddl) to allow for a concise specification of COSE formats. I recommend that this document be held for publication until that I-D is approved. I also note that the cited I-D is Informational, but this document is Standards Track. the cited I-D is listed as informative, but the syntax it defines is used extensively throughout this document, thus I believe it really is normative. Section 2 defines the basic COSE data structure. The description seems clear and logical, but the list of message types is a bit puzzling (absent information that is provided later, in Sections 4 and 5). For example, there is a Single Signer data Object, and a Signed Data Object. If the latter accommodates multiple signers, why not make that part of the name? The same nomenclature confusion arises for encrypted objects directed to a single recipient vs. multiple recipients. Section 3 Describes the header parameters. It provides generally good, detailed descriptions of the common header elements and explains why certain conventions are adopted. It clearly describes requirements imposed on senders and recipients. Section 4 describes the objects used to convey one or more signatures for objects. The description here is a bit confusing when it discusses one vs. multiple signatures. The format that allows carriage of multiple signatures does not necessarily imply that there are multiple signers, e.g., the multiple signatures may be present to accommodate different algorithm capabilities for different recipients. The introduction to 4.2 says: “The COSE_Sign1 signature structure is used when only one signer is going to be placed on a message.†Perhaps it would be clearer to say that this structure is used when only one _signature is to be placed in_ a message. Overall this section is well written and provides useful details about how to compute signatures and counter signatures. Section 5 describes the COSE encryption objects. I disagree with one choice of terminology adopted here: “recipient algorithm classes†which is described in 5.1.1. This is really a discussion of classes of key distribution/management algorithms, focusing on how each recipient of an encrypted message acquires the CEK used to decrypt the message. I’d prefer a less obscure name for this sub-section. Otherwise this section is well written and provide lots of useful details about how to encrypt and decrypt messages for two classes of encryption algorithms. Section 6 describes the MAC objects. Here too there are two types of structures, depending on whether a recipient implicitly knows what key to use to verify the MAC, or whether an ID for one or more MAC keys must be communicated. The text here closely parallels that of Section 5 and is very good. Section 7 describes the COSE key structure. It is designed to accommodate the data needed by a wide range of key distribution mechanisms and encryption techniques. Section 8 defines two classes of signature algorithms that can be used with COSE, specifies an algorithm of each type, and provides security guidance for each algorithm. I think it would be preferable to remove the detailed algorithm descriptions (Sections 8.1 and 8.2) and associated security considerations (which are well written) from this document. The comments below apply to sections 9, 10, 11 and 12. I have several concerns about including the algorithm (vs. algorithm class) descriptions here. For many security protocols (and security-focused data formats), we usually (though not always) specify mandatory and optional to implement algorithms in separate documents, to facilitate algorithm agility. I think we should follow that model for COSE. Also, the text here does not mandate support for these algorithms; it merely provides details for a set of algorithms that a sender and/or receive may choose to implement. One has to read the final sentence of the opening paragraph of Section 15 to learn that this is the intent, i.e., that selection of specific algorithms is deferred to the each application that makes use of COSE. Given that later statement, it appears that the algorithms specified in Sections 8-12 ate intended to define the set from which application developer MUST choose, but that too is not clearly stated. I think this makes it even more appropriate to remove the detailed algorithm discussions from this document. Section 12 describes the “recipient algorithm classes†aka key distribution/management methods. Most of this section is analogous to the preceding sections (9-11) where specific algorithms are described for use with COSE, and thus my comments about undue bundling of algorithms with a protocol specs apply here too. I do not object to describing key transport, key wrapping and key agreement methods in general, but the detailed specs in 12.2.1, 12.4.1 and 12.5.1 seem inappropriate here, for the reasons noted above. Section 13 describes parameters for key objects used by COSE. The specs here are sufficiently generic that they do not suffer from the problems I noted for Sections 8-12. Section 15 provides guidance for application developers making use of COSE. This is where a reader finally discovers that the algorithms described in Sections 8-12 are not MTI, and that each application is expected to specify which algorithms are MTI in that context, to facilitate interoperability. Section 16 (IANA Considerations) describes the registries that need to be created for COSE, and extensions to the CoAP registry to support COSE. It seem to be well written and comprehensive. Section 18 (Security Considerations) is a good adjunct to the already well-written security considerations discussions provided for the algorithms in Sections 8-12. *Typos and suggested rewording.* Section 2: The COSE object structure is designed so that there can be a large amount of common code when parsing and processing the different security messages. -> The COSE object structure is designed so that there can be a large amount of common code when parsing and processing the different types of security messages. COSE messages are also built using the concept of using layers to … -> COSE messages are built using the concept of layers to … Section 3: The integer and string values for labels has been divided … -> The integer and string values for labels have been divided … Applications SHOULD perform the same checks that the same label … -> Applications SHOULD verify that the same label … Applications should have a statement if the label can be omitted. -> Applications SHOULD (?) have a statement if the label can be omitted. Integers are from the "CoAP Content-Formats" IANA registry table. (no reference) As the IV is authenticated by the encryption process, it can be placed in the unprotected header bucket. (in general, an encryption process will not “authenticate†an IV, but use of a modified IV will yield mangled plaintext, which can be detected by an integrity check or a signature. the same comment applies to the similar statement in the “partial IV†description.) Section 4: Edwards Digital Signature Algorithm (EdDSA) signature algorithm and with the Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithm. -> Edwards Digital Signature Algorithm (EdDSA) (cite) and with the Elliptic Curve Digital Signature Algorithm (ECDSA) (cite). One of the features supplied in the COSE document is the ability… -> One of the features offered by the COSE format is the ability … This algorithm takes in the body information … -> The signing and verification processes take in the body information … Counter signatures provide a method of having a different signature occur on some piece of content. -> Counter signatures provide a method of associating different signatures generated by different signers with some piece of content. Section 5 Other:The key is randomly generated. -> Other:The key is randomly or pseudo-randomly generated. Section 6 (This knowledge of sender assumes that there are only two parties involved and you did not send the message yourself.) -> (This knowledge of sender assumes that there are only two parties involved and you did not send the message to yourself.) Section 15: It is intended that a profile of this document be created that defines the interopability -> It is intended that a profile of this document be created that defines the interoperability --------------718207C49D1628D772C3EC0D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

SECDIR review of draft-ietf-cose-msg-18

 

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

 

This document defines formats for signing and/or encryption of data encoded using CBOR (RFC7049). The signing/encryption approach adopted here is based on the standards developed in JOSE (RFCs 7515-18), since CBOR is based on JSON.

 

This is a large document: about 90 pages plus almost 30 pages of appendices (providing useful examples).  Close to half of the (non-appendix portion) document is devoted to specifications for a set of algorithms for encryption, signatures, message authentication, and key distribution. Only when the reader reaches page 73 is it made clear that the algorithm descriptions are not MTI; they define a set from which application developers must (?) choose when creating a profile for COSE use in a specific application context. Given the long-standing IETF policy to trying to facilitate algorithm agility, 

I think it preferable to extract these descriptions and publish them as separate RFCs, a practice often employed in documenting many other security protocols (including JOSE, from which this work is based).

 

 

The document begins with a brief explanation of how COSE differs from JOSE, an excellent preface to the document. The cited design differences all seem very appropriate for CBOR, e.g., using binary encoding instead of base64url, shedding some of the odd constraints adopted in JOSE because of pre-existing work in the area, and updating the list of algorithms.

 

Since there is no standard grammar for CBOR, the author adopted the primitive types defined in an I-D (draft-ietf- greevenbosch-appsawg-cbor-cddl) to allow for a concise specification of COSE formats. I recommend that this document be held for publication until that I-D is approved. I also note that the cited I-D is Informational, but this document is Standards Track. the cited I-D is listed as informative, but the syntax it defines is used extensively throughout this document, thus I believe it really is normative.

 

 

Section 2 defines the basic COSE data structure. The description seems clear and logical, but the list of message types is a bit puzzling (absent information that is provided later, in Sections 4 and 5). For example, there is a Single Signer data Object, and a Signed Data Object. If the latter accommodates multiple signers, why not make that part of the name? The same nomenclature confusion arises for encrypted objects directed to a single recipient vs. multiple recipients.

 

 

Section 3 Describes the header parameters. It provides generally good, detailed descriptions of the common header elements and explains why certain conventions are adopted. It clearly describes requirements imposed on senders and recipients.

 

 

Section 4 describes the objects used to convey one or more signatures for objects. The description here is a bit confusing when it discusses one vs. multiple signatures. The format that allows carriage of multiple signatures does not necessarily imply that there are multiple signers, e.g., the multiple signatures may be present to accommodate different algorithm capabilities for different recipients. The introduction to 4.2 says:

    “The COSE_Sign1 signature structure is used when only one signer is going to be placed on a message.â€

Perhaps it would be clearer to say that this structure is used when only one signature is to be placed in a message.

 

Overall this section is well written and provides useful details about how to compute signatures and counter signatures.

 

 

Section 5 describes the COSE encryption objects. I disagree with one choice of terminology adopted here: “recipient algorithm classes†which is described in 5.1.1. This is really a discussion of classes of key distribution/management algorithms, focusing on how each recipient of an encrypted message acquires the CEK used to decrypt the message. I’d prefer a less obscure name for this sub-section. Otherwise this section is well written and provide lots of useful details about how to encrypt and decrypt messages for two classes of encryption algorithms.

 

 

Section 6 describes the MAC objects. Here too there are two types of structures, depending on whether a recipient implicitly knows what key to use to verify the MAC, or whether an ID for one or more MAC keys must be communicated. The text here closely parallels that of Section 5 and is very good.

 

 

Section 7 describes the COSE key structure. It is designed to accommodate the data needed by a wide range of key distribution mechanisms and encryption techniques.

 

 

Section 8 defines two classes of signature algorithms that can be used with COSE, specifies an algorithm of each type, and provides security guidance for each algorithm. I think it would be preferable to remove the detailed algorithm descriptions (Sections 8.1 and 8.2) and associated security considerations (which are well written) from this document. The comments below apply to sections 9, 10, 11 and 12.

 

I have several concerns about including the algorithm (vs. algorithm class) descriptions here. For many security protocols (and security-focused data formats), we usually (though not always) specify mandatory and optional to implement algorithms in separate documents, to facilitate algorithm agility. I think we should follow that model for COSE. Also, the text here does not mandate support for these algorithms; it merely provides details for a set of algorithms that a sender and/or receive may choose to implement. One has to read the final sentence of the opening paragraph of Section 15 to learn that this is the intent, i.e., that selection of specific algorithms is deferred to the each application that makes use of COSE. Given that later statement, it appears that the algorithms specified in Sections 8-12 ate intended to define the set from which application developer MUST choose, but that too is not clearly stated. I think this makes it even more appropriate to remove the detailed algorithm discussions from this document. 

 

Section 12 describes the “recipient algorithm classes†aka key distribution/management methods. Most of this section is analogous to the preceding sections (9-11) where specific algorithms are described for use with COSE, and thus my comments about undue bundling of algorithms with a protocol specs apply here too. I do not object to describing key transport, key wrapping and key agreement methods in general, but the detailed specs in 12.2.1, 12.4.1 and 12.5.1 seem inappropriate here, for the reasons noted above.

 

 

Section 13 describes parameters for key objects used by COSE. The specs here are sufficiently generic that they do not suffer from the problems I noted for Sections 8-12.

 

 

Section 15 provides guidance for application developers making use of COSE. This is where a reader finally discovers that  the algorithms described in Sections 8-12 are not MTI, and that each application is expected to specify which algorithms are MTI in that context, to facilitate interoperability.

 

Section 16 (IANA Considerations) describes the registries that need to be created for COSE, and extensions to the CoAP registry to support COSE. It seem to be well written and comprehensive.

 

Section 18 (Security Considerations) is a good adjunct to the already well-written security considerations discussions provided for the algorithms in Sections 8-12.

 

 

Typos and suggested rewording.

 

Section 2:

 

The COSE object structure is designed so that there can be a large amount of common code when parsing and processing the different

security messages.

 -> The COSE object structure is designed so that there can be a large amount of common code when parsing and processing the different types of security messages.

 

COSE messages are also built using the concept of using layers to …

-> COSE messages are built using the concept of layers to …

 

Section 3:

 

The integer and string values for labels has been divided …

 -> The integer and string values for labels have been divided …

 

Applications SHOULD perform the same checks that the same label …

-> Applications SHOULD verify that the same label …

 

Applications should have a statement if the label can be omitted.

-> Applications SHOULD (?) have a statement if the label can be omitted.

 

Integers are from the "CoAP Content-Formats" IANA registry table. (no reference)

 

As the IV is authenticated by the encryption process, it can be placed in the unprotected header bucket. (in general, an encryption process will not “authenticate†an IV, but use of a modified IV will yield mangled plaintext, which can be detected by an integrity check or a signature. the same comment applies to the similar statement in the “partial IV†description.)

 

 

Section 4:

 

Edwards Digital Signature Algorithm (EdDSA) signature algorithm and with the Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithm.

-> Edwards Digital Signature Algorithm (EdDSA) (cite) and with the Elliptic Curve Digital Signature Algorithm (ECDSA) (cite).

 

One of the features supplied in the COSE document is the ability…

-> One of the features offered by the COSE format is the ability …

 

This algorithm takes in the body information …

-> The signing and verification processes take in the body information …

 

Counter signatures provide a method of having a different signature occur on some piece of content.

-> Counter signatures provide a method of associating different signatures generated by different signers with some piece of content.

 

 

Section 5

 

Other:  The key is randomly generated.

-> Other:  The key is randomly or pseudo-randomly generated.

 

 

Section 6

 

(This knowledge of sender assumes that there are only two parties involved and you did not send the message yourself.)

-> (This knowledge of sender assumes that there are only two parties involved and you did not send the message to yourself.)

 

 

Section 15:

 

It is intended that a profile of this document be created that

defines the interopability

-> It is intended that a profile of this document be created that

   defines the interoperability

--------------718207C49D1628D772C3EC0D-- From nobody Wed Sep 21 07:28:12 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5449B12B1A5; Wed, 21 Sep 2016 07:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=JlGAbj2h; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=m0uwsFej 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 xUy0IO62glqt; Wed, 21 Sep 2016 07:28:02 -0700 (PDT) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 D5B8E12B1B7; Wed, 21 Sep 2016 07:28:01 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=bfqduTzOu2RL452XVXPXkheFDkXZJSyaGSM2FdS5/ufFysQrTLO18E6L J06J4lmrhE/CmR/J+Wn9AhLv/R2b73mvRQ9Sqlbk39lGFxX1j8CsKN0DI cXXz/1Wywih837NFq8helsoJM6o3FRSXQcQ3cAmgqnw1SLLs6ylYteU56 E=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1474468081; x=1506004081; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lf8cYKP4kwN4W/r/XaoDfuyARA3GC6OBqqX4a3ZhP7c=; b=JlGAbj2hs3/sSCO3B0sjI+vTBJ3kVJDMPbzvlFmq2zpGvLgamvaUImF3 4egqi+JJAOHOm19wezu775dfH6cSPpy/ugrOYeCO/fB/kD1K/qCchUOoU ACUIZkEEPpOfK8gMzo9qTcB9v5gkoP+KJG84Xd+JzsgWFjw52F2+x6b8i E=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2016 09:28:00 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2016 20:28:00 +0600 Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u8LERwa8004387 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Sep 2016 10:27:59 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u8LERwa8004387 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1474468079; bh=6/x1isyn5RnTQ+Td9RxDGu1OEho=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=m0uwsFej+b7q0EpihReGBS4+g6oN9sCeLkiGSIIj/m8/b4Fihv9w6l3FD3KDgkYhq yPtBLHJwWtCIB5U6pmOq8Zp61pq8zvy6tXgrJcCctG9zYnHVrvWaegtEgrOBBqRq9L 3z6+fxPmLBK2mnqya7ESfDL3TtiOcVMcq01TEqTQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u8LERwa8004387 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd05.lss.emc.com (RSA Interceptor); Wed, 21 Sep 2016 10:27:43 -0400 Received: from MXHUB319.corp.emc.com (MXHUB319.corp.emc.com [10.146.3.97]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u8LERgCv011624 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 21 Sep 2016 10:27:43 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB319.corp.emc.com ([10.146.3.97]) with mapi id 14.03.0266.001; Wed, 21 Sep 2016 10:27:42 -0400 To: Benjamin Kaduk , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-tsvwg-diffserv-intercon@ietf.org" Thread-Topic: secdir review of draft-ietf-tsvwg-diffserv-intercon-09 Thread-Index: AQHSDjyajyKhOTPr40WZvsnPej2GaaCEA6aw Date: Wed, 21 Sep 2016 14:27:42 +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.252.39.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-diffserv-intercon-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 14:28:04 -0000 Hi Ben, Thanks for the review. > However, I do think it's worth giving a little bit of new thought to the > potential privacy considerations -- a new way of marking traffic, in > abstract, has the potential to leak classification information about the > traffic in question (e.g., is this IP address doing telephony?). That > said, the classification added by this document is something that could b= e > done by any party with access to the raw network traffic, so I don't thin= k > there are actually any new considerations in play; it's just something to > keep in mind. On balance, it seems like a good idea to add a sentence or two to point out that additional traffic classification information is exposed at network interconnections by comparison to DSCP remarking to zero - if that traffic classification info is sensitive, remarking DSCPs to zero to hide the class= ification is the countermeasure, at the cost of loss of QoS info and traffic handling on the interconnect. Also, here are a few comments on your editorial suggestions: >=20 > Introduction, first paragraph, space between ')' and 'and'. > Just a few words later, is it clearer to s/at/for use at/? Yes, we'll make both changes. > Top of page 3, last sentence of first paragraph ("This draft assumes that > latter approach by defining additional DSCPs that are known and expected > at network interconnection interfaces.") -- I think maybe "subsumes" is a > better verb than "assumes", as it is true that unknown/unexpected DSCPs > are remarked to zero, but there is additional functionality in the > known/expected DSCPs that are preserved. Well, "subsumes" isn't quite right either. Here's a longer rewrite that I= hope makes things clearer: OLD This draft assumes that latter approach by defining additional DSCPs that are known and expected at network interconnection interfaces. NEW This draft is based on the latter approach, and defines additional DSCPs that are known and expected at network interconnection interfaces in order to reduce the amount of traffic whose DSCPs are remarked to zero. =20 > Across the page 3/page 4 boundary, the part after the semicolon is a > sentence fragment ... I can't even tell what it's trying to say. Maybe, > "remarking to zero is performed in the absence of [...]" (but put a comma > before "for"). Yes, it's a fragment - here's a suggested rewrite: OLD remarking in the absence of additional agreement(s) when the MPLS Short Pipe model is used for reasons explained in this document. NEW use of the MPLS Short Pipe model favors remarking unexpected DSCPs to zero in the absence of additional agreement(s), as explained further in this document. > Section 1.1, first paragraph, is this work really intended to *complement= * > RFC 5160? It seems to me that rather it is building upon 5160, or > implementing its suggestions, or something like that. The activities are independent, so "complement" is a reasonable summary. > Section 4, Telephony Service Treatment Aggregate, it looks like the > convention would have the DSCP be formatted as "101 100" with a space. Yes, there's a missing space. Thanks, --David > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@MIT.EDU] > Sent: Wednesday, September 14, 2016 12:01 AM > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-tsvwg-diffserv-intercon@ie= tf.org > Subject: secdir review of draft-ietf-tsvwg-diffserv-intercon-09 >=20 > [re-sending with proper recipients list; sorry for the duplicate] >=20 > Hi all, >=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 draft is Ready. >=20 > I had to do some background reading (RFC 2475, mostly, and skimming some > other references) to really understand what's going on here; I'll probabl= y > use some wrong terminology as a result. This draft describes a standard > set of 4 Treatment Aggregates that can be used by MPLS networks using the > Short-Pipe tunnel mode to preserve IP Differentiated Service code point > markings and the corresponding per-hop behaviors as traffic traverses the > network boundary. DSCP translation is expected to be done both at entry > and exit from the network (as applicable; not all traffic is through > traffic, of course) betwen the standard DSCPs and network-internal DSCPs > used to apply PHBs, but the benfit of this scheme is the standardized > interface, much as how it is easier for a user to accept a two-clause BSD > software license that is well-known than it is for that user to accept a > software EULA that was custom written by a company's lawyers. Otherwise, > everything described in this document could be done already by two peered > networks that negotiate an SLA. With this document, they still must > negotiate an SLA, but there are standard terms to simplify the process. >=20 > The security considerations accordingly note (correctly) that this > document does not introduce new features; rather, it describes how to use > existing ones. It refers to the security considerations in RFCs 2475 and > 4594, which seem to be complete, noting that differentiated services > introduce the possibility of fasely marked/prioritized traffic and the > potential for denial of service. Only calling out IPsec as the example i= s > a bit dated, but the general principles still seem fine -- the physical > network has to be protected and traffic sanitized on entry. >=20 > However, I do think it's worth giving a little bit of new thought to the > potential privacy considerations -- a new way of marking traffic, in > abstract, has the potential to leak classification information about the > traffic in question (e.g., is this IP address doing telephony?). That > said, the classification added by this document is something that could b= e > done by any party with access to the raw network traffic, so I don't thin= k > there are actually any new considerations in play; it's just something to > keep in mind. >=20 >=20 > A few editorial comments follow: >=20 > Please expand PHBs in the abstract, not just in the introduction >=20 > Introduction, first paragraph, space between ')' and 'and'. > Just a few words later, is it clearer to s/at/for use at/? >=20 > Top of page 3, last sentence of first paragraph ("This draft assumes that > latter approach by defining additional DSCPs that are known and expected > at network interconnection interfaces.") -- I think maybe "subsumes" is a > better verb than "assumes", as it is true that unknown/unexpected DSCPs > are remarked to zero, but there is additional functionality in the > known/expected DSCPs that are preserved. >=20 > Across the page 3/page 4 boundary, the part after the semicolon is a > sentence fragment ... I can't even tell what it's trying to say. Maybe, > "remarking to zero is performed in the absence of [...]" (but put a comma > before "for"). >=20 > Section 1.1, first paragraph, is this work really intended to *complement= * > RFC 5160? It seems to me that rather it is building upon 5160, or > implementing its suggestions, or something like that. >=20 > Section 4, Telephony Service Treatment Aggregate, it looks like the > convention would have the DSCP be formatted as "101 100" with a space. >=20 > -Ben From nobody Wed Sep 21 08:29:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803C712B4DF for ; Wed, 21 Sep 2016 08:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQfcWqw5pW0T for ; Wed, 21 Sep 2016 08:29:17 -0700 (PDT) Received: from 4.mo177.mail-out.ovh.net (4.mo177.mail-out.ovh.net [46.105.37.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAA412B4DA for ; Wed, 21 Sep 2016 08:29:11 -0700 (PDT) Received: from player699.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 0F824FFC2C0 for ; Wed, 21 Sep 2016 17:29:04 +0200 (CEST) Received: from RCM-mail305.ha.ovh.net (unknown [193.104.162.7]) (Authenticated sender: julien@trigofacile.com) by player699.ha.ovh.net (Postfix) with ESMTPSA id 6D54B24007D; Wed, 21 Sep 2016 17:28:55 +0200 (CEST) Received: from [193.104.162.7] by ssl0.ovh.net with HTTP (HTTP/1.1 POST); Wed, 21 Sep 2016 17:28:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 21 Sep 2016 17:28:55 +0200 From: =?UTF-8?Q?Julien_=C3=89LIE?= To: Barry Leiba Organization: TrigoFACILE In-Reply-To: References: Message-ID: <20981db3190142193043f1445abadaa3@trigofacile.com> X-Sender: julien@trigofacile.com User-Agent: Roundcube Webmail/1.1.3 X-Originating-IP: 193.104.162.7 X-Webmail-UserID: julien@trigofacile.com X-Ovh-Tracer-Id: 12051632606819450146 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelvddrtddvgdekiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Archived-At: Cc: draft-murchison-nntp-compress.all@ietf.org, IESG , barryleiba@gmail.com, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 15:29:20 -0000 Hi Barry, > 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. > > There are no major issues here, but there are a number of things I > think need to be addressed before this document is ready. Thanks a lot for your review and your comments. > References: > RFC 1951 (DEFLATE) MUST be implemented with this, so it needs to be a > normative reference. OK. > -- Section 2.1 -- > > This document defines one > compression algorithm: DEFLATE. This algorithm is mandatory to > implement and MUST be supported in order to advertise the COMPRESS > extension. > > Just to be clear and specific, I suggest changing the second sentence > to say "and MUST be supported and listed in the advertisement of the > COMPRESS extension." OK. > -- Section 2.2.2 -- > > In order to help mitigate leaking authentication credentials via for > instance a CRIME attack [CRIME], authentication SHOULD NOT be > attempted when a compression layer is active. Consequently, a > server > SHOULD NOT return any arguments with the AUTHINFO capability label > (or SHOULD NOT advertise it at all) in response to a CAPABILITIES > command received from an unauthenticated client after a compression > layer is active, and such a client SHOULD NOT attempt to utilize any > AUTHINFO [RFC4643] commands. It implies that a server SHOULD reply > with a 502 response code if a syntactically valid AUTHINFO command > is > received while a compression layer is already active. > > Why are these SHOULD, and not MUST? Under what conditions would it be > necessary or reasonable for an implementation not to abide by these, > and what considerations need to be considered when making that > determination? (And this is also directly referred to in Section 6.) I agree that we could change most of SHOULD to MUST here. The remaining SHOULD would be: Consequently, a server SHOULD NOT return any arguments with the AUTHINFO capability label (or SHOULD NOT advertise it at all) in response to a CAPABILITIES command received from an unauthenticated client after a compression layer is active The rationale is because of the wording of RFC 4346, Section 2.1: The server MAY list the AUTHINFO capability with no arguments, which indicates that it complies with this specification and does not permit any authentication commands in its current state. Maybe you would prefer for our document: Consequently, a server MAY list the AUTHINFO capability with no arguments, or not advertise it at all, in response to a CAPABILITIES command received from an unauthenticated client after a compression layer is active This way, we would no longer use SHOULD, but MUST and one MAY. What wording is preferrable? > When compression is active and either the client or the server > receives invalid or corrupted compressed data, the receiving end > SHOULD immediately close the connection. (Then the sending end will > in turn do the same.) > > Same question. We used SHOULD because RFC 4642 uses SHOULD in a in Section 2.2.2: If, after having issued the STARTTLS command, the client finds out that some failure prevents it from actually starting a TLS handshake, then it SHOULD immediately close the connection. [...] If the TLS negotiation fails, both client and server SHOULD immediately close the connection. Note that while continuing the NNTP session is theoretically possible, in practice a TLS negotiation failure often leaves the session in an indeterminate state; therefore, interoperability can not be guaranteed. I therefore also suggest to keep SHOULD here. Do you believe we should switch to MUST anyway? (Wouldn't it be a too strong constraint?) > -- Section 2.3 -- > > At the end of the first example, it would be useful to add another > CAPABILITIES command to show that COMPRESS DEFLATE is no longer > listed. Good point. Besides, I believe I should add it anyway because of Section 2.1: As the COMPRESS command is related to security because it can weaken encryption, cached results of CAPABILITIES from a previous session MUST NOT be relied on, as per Section 12.6 of [RFC3977]. CAPABILITIES is therefore required to be sent after a successful use of COMPRESS. > -- Section 5 -- > > This section contains a list of each new response code defined in > this document and indicates whether it is multi-line, which commands > can generate it, what arguments it has, and what its meaning is. > > This is a total nit, but this sentence seems odd when there's only one > new code (there's also nothing that says whether it is or isn't > multi-line). I suggest, instead, "The following new response code is > defined in this document:". Agreed. It was just a lame copy/paste from previous RFCs defining NNTP extensions. FYI, the core documentation (RFC 3977) uses: Response code 100 (multi-line) Generated by: HELP Meaning: help text follows. Response code 111 Generated by: DATE 1 argument: yyyymmddhhmmss Meaning: server date and time. Wording suggested for our document: This document defines the following new response code. It is not multi-line and has no arguments. Response code 206 Generated by: COMPRESS Meaning: compression layer activated > -- Section 6 -- > > NNTP commands other than AUTHINFO are not believed to divulgate > confidential information > > Qu'est que c'est "divulgate"? Perhaps you mean "divulge", unless > you're Shakespeare. Je ne suis effectivement ni Shakespeare ni Molière :) > In case confidential articles are accessed in private > newsgroups, special care is needed: implementations SHOULD NOT > compress confidential data together with public data when a security > layer is active, for the same reasons as mentioned above in this > Section. > > Sorry: it is not clear to me what reasons those are; can you be > specific here? And why SHOULD, and not MUST? ... because the reasons above do not strictly apply to that case. Suggestion: In case confidential articles are accessed in private newsgroups, special care is needed: implementations SHOULD NOT compress confidential data together with public data when a security layer is active. As a matter of fact, adversaries that observe the length of the compressed data might be able to derive information about it, when public data (that adversaries know is read) and confidential data are compressed in the same compress session. Of course, if you have a more fluent suggestion of wording, you're welcome :) I suggested SHOULD because I thought MUST was too strong. It would imply that clients and servers have a way to specify the confidentialness of newsgroups. It currently does not exist, and I doubt a user would maintain it in its news client. That's why I had not used MUST, so as not to declare non-compliant implementations that do not flag newsgroups as confidential or not. Am I wrong with that consideration and should we use MUST anyway? > Additionally, implementations MAY ensure that the contents of two > distinct confidential articles are not compressed together. > > Of course they MAY, but what's the point of saying that. I think > you'd be much better off skipping the 2119 key word here, and instead > say something about why it might be good to do this: what's the > advantage? Something like, "Additionally, implementations would do > well to ensure that the contents of two distinct confidential articles > are not compressed together, because [of this advantage]." We had in mind the following scenario: "[...], because adversaries might be able to derive information about confidential articles as they may have identical header fields (like Subject, Newsgroups or From) or header fields whose contents may be predictable (like Xref or Injection-Info)." Maybe "predictable" is not the right word. "have a structured pattern"? "are formatted in a known syntax?" Examples: Injection-Info: news.trigofacile.com; posting-account="eliej"; posting-host="news.trigofacile.com:2001:41d0:1:6d44::1"; logging-data="29828"; mail-complaints-to="abuse@trigofacile.com" Xref: news.trigofacile.com trigofacile.test:566 Do you have a preferred wording for that paragraph? (Should a reference to RFC 5536 be also mentioned? Like "These header fields are described in [RFC5536].") > Future extensions to NNTP that define commands conveying > confidential > data SHOULD ensure to state that these confidential data SHOULD NOT > be compressed together with public data when a security layer is > active. > > I guess this is related the the paragraph I quoted immediately above, > so the question is the same. This time, it correctly refers to Section 6 of [RFC3749]. See the beginning of Section 6 of the document: Implementers should be aware that combining compression with encryption like TLS can sometimes reveal information that would not have been revealed without compression, as explained in Section 6 of [RFC3749]. If we decide to use MUST instead of SHOULD before in the document, of course it will need to be homogenized here. > -- Section 7.1 -- > > Any name that conforms to the syntax of an NNTP compression > algorithm > name (Section 4.3) can be used. > > It would be useful here, for IANA's benefit, to specifically highlight > that letters in algorithm names are always upper case. In the registry, it is indeed best to use upper case. I can mention it. Just to be certain of the meaning of your remark: the algorithm name in the NNTP command is not required to be upper case. algorithm = "DEFLATE" / 1*20alg-char alg-char = UPPER / DIGIT / "-" / "_" ABNF syntax is not case-sensitive, so "COmprESs dEFlaTe" is a valid NNTP command, that has the same effect as "COMPRESS DEFLATE". > However, the name of a registered > NNTP compression algorithm MUST NOT begin with "X". > > To avoid the risk of a clash with a future registered NNTP > compression algorithm, the names of private compression algorithms > SHOULD begin with "X-". > > This was discussed in response to another review, and I understand the > "X-" stuff will be removed. Thanks. Yep. > If it does not implement the compression > algorithm as specified, it MUST NOT list its registered name in the > arguments list of the COMPRESS capability label. In that case, it > MAY, but SHOULD NOT, provide a private algorithm (not listed, or > listed with a different name) that implements the compression > algorithm differently. > > Oy. This really sounds convoluted to me, and the "MAY, but SHOULD > NOT" is a direct contradiction. Just saying that an implementation has the possibility to do that (MAY) but is not encouraged to (SHOULD NOT). > I think what you're trying to say here is that if you list a > registered algorithm, it MUST be properly implemented according to the > relevant spec. Got that. Now, what about including unregistered > algorithms? Do you want to say that you MAY include unregistered > algorithms? Do you want to say that you SHOULD NOT include any? Why > not, and why might you decide to do that anyway? What are the > interoperability issues with respect to unregistered algorithms? To respond your questions: yes, unregistered algorithms MAY be included if the implementation wishes to. Yes, unregistered algorithms SHOULD NOT be included (bad practice). Why that? because out of consistency between RFCs, I'm just declining in this NNTP extension what Section 3.3.3 of RFC 3977 (core NNTP specification) mentions: If the server advertises a capability defined by a registered extension, it MUST implement the extension so as to fully conform with the specification (for example, it MUST implement all the commands that the extension describes as mandatory). If it does not implement the extension as specified, it MUST NOT list the extension in the capabilities list under its registered name. In that case, it MAY, but SHOULD NOT, provide a private extension (not listed, or listed with a different name) that implements part of the extension or implements the commands of the extension with a different meaning. And I would just say that interoperability issues with that SHOULD NOT is out of scope of this document. Implementations SHOULD NOT do that. A case I see is "private news servers and news clients" (for instance Giganews [server] and Mimo [client developed specifically for the Giganews Usenet service]). They could implement their own unregistered algorithm, and use it if they wish. I believe they are clever enough not to name it LZMA or BZIP2 but XGIGAFEATURE, GIGACOMPRESS... > A server MUST NOT send different response codes to COMPRESS in > response to the availability or use of a private compression > algorithm. > > I don't understand what this is saying at all. Different from what? > Can you clarify this? Suggestion: The 206, 403, and 502 response codes a news server answers to COMPRESS using a private compression algorithm MUST have the same meaning as the one documented in Section 2.2 of this document. Would it be OK for you with that rewording? Thanks again for your valuable comments to help improve the quality of the document. -- Julien ÉLIE From nobody Wed Sep 21 09:11:44 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6C012B569; Wed, 21 Sep 2016 09:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7Trvy1paJoV; Wed, 21 Sep 2016 09:11:36 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 1E53512B566; Wed, 21 Sep 2016 09:11:36 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id z190so50285310qkc.3; Wed, 21 Sep 2016 09:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=AqUlFsDumT8/0fSM+tUIwg0CbwxTB0RiJ++3PzJa9f8=; b=yZNji6BeiQeuwYsAf+EINnrRyXCEYTmRgbrjER0Uox9XXvf/J2BWa/1c77w2Gd5KAt EpdtHzqWXduQ2M6N5jN2mjSt+QICxHmkIJuKDmkS7i56tOOYCxWEWejSJ79/HzyjEwEZ opkOZHjrdDFfjWu08VxTicncijubsHJ68OS5b8crV9VCzsnX9aV17zyi5RJ7312a/Tj5 PorWIWVaJknKzs8LlcYk/Mn2tb4f9LjeQtzHHL6+fIZUtJtMSupwMze5pHS/NTzusdfW gRZXodBOJmKkO5OtVbnAYrp8SHHMxcI89PxmYnch7Efrajc6zV/fXWSNHLcFByog6J22 TU6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=AqUlFsDumT8/0fSM+tUIwg0CbwxTB0RiJ++3PzJa9f8=; b=dSfk6ybI2qtWcEr0HPDnc+1FYaZyhqQrBTqoLNL1n6qsx0Dn57+ZR3sX7BXIIBJB7x yg2fAnGH2nSBv8zuDyUT0pSOxUworwJSA59eDhLxHHlFOdNgeS7vC68k9FxL2o+5+JlR gQ+eqLbj/hr5mE81gSeo0F4kNdAy2OWcknXOQ96U4SZLhFbfxLSl9WYnHDs5fn3RT7bO A+rgGhebn+XsM1kzUQjJWd+TZL7A4MqOcq1ZYgSn28XEtAXLAjMKU4PphFwLgb4g9exs E/AN/mtmQfA9FjSuF6EmM1jCFP8JVxybezposMEZReaS+QryNau4ZJgdHumRlTCkv8oR EfWQ== X-Gm-Message-State: AE9vXwMam+PJbSEn6PzFx1iheWrbJHln8JTrtBiDaR2rNMNndFotPoAF4mJzoZqHbBzN/aeTQBxWZOyQydmKig== X-Received: by 10.55.101.16 with SMTP id z16mr40121189qkb.276.1474474295176; Wed, 21 Sep 2016 09:11:35 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.140.39.52 with HTTP; Wed, 21 Sep 2016 09:11:34 -0700 (PDT) In-Reply-To: <20981db3190142193043f1445abadaa3@trigofacile.com> References: <20981db3190142193043f1445abadaa3@trigofacile.com> From: Barry Leiba Date: Wed, 21 Sep 2016 17:11:34 +0100 X-Google-Sender-Auth: Wvp2k4HEnHClUlaif8uSJPZU5QA Message-ID: To: =?UTF-8?B?SnVsaWVuIMOJTElF?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-murchison-nntp-compress.all@ietf.org, IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 16:11:43 -0000 Hi, Julien, and thanks for the thorough response. Further response only on the items where response is needed: > Maybe you would prefer for our document: > > Consequently, a server MAY list the AUTHINFO capability with > no arguments, or not advertise it at all, in response to a CAPABILITI= ES > command received from an unauthenticated client after a compression > layer is active > > This way, we would no longer use SHOULD, but MUST and one MAY. It's a small point, but I don't like "MAY" to introduce two alternatives, because it's not clear whether there might be other alternatives as well... or not. How does it work for you to make it "MUST" instead of "MAY", saying, therefore, that the server MUST either list AUTHINFO with no arguments or not advertise it at all? Then it's clear that there are two alternatives, and either is OK. No? >> When compression is active and either the client or the server >> receives invalid or corrupted compressed data, the receiving end >> SHOULD immediately close the connection. (Then the sending end will >> in turn do the same.) >> >> Same question. > > We used SHOULD because RFC 4642 uses SHOULD in a in Section 2.2.2: OK. > I therefore also suggest to keep SHOULD here. > Do you believe we should switch to MUST anyway? (Wouldn't it be a > too strong constraint?) Well (and we're now down to nit level, so do as you think best here), as I see it, it's not a question of level of constraint -- if it were, you could say it without 2119 key words, as "the receiving end immediately closes the connection, in response to which the sending end will do the same." (Now that I think about it more, I think that's the best answer, but if you disagree that's fine.) The (very, very small) problem I have with "SHOULD" here is that "SHOULD" means that you really need to do it unless you have a good reason not to and have considered the consequences of not doing it. Along that line, what does it really mean for me *not* to close the connection when I've received bogus compressed data? > Wording suggested for our document: > > This document defines the following new response code. It is not > multi-line and has no arguments. > > Response code 206 > Generated by: COMPRESS > Meaning: compression layer activated Parfait; merci. > Je ne suis effectivement ni Shakespeare ni Moli=C3=A8re :) He-he... >> In case confidential articles are accessed in private >> newsgroups, special care is needed: implementations SHOULD NOT >> compress confidential data together with public data when a security >> layer is active, for the same reasons as mentioned above in this >> Section. >> >> Sorry: it is not clear to me what reasons those are; can you be >> specific here? And why SHOULD, and not MUST? > > ... because the reasons above do not strictly apply to that case. > > Suggestion: > > In case confidential articles are accessed in private > newsgroups, special care is needed: implementations SHOULD NOT > compress confidential data together with public data when a security > layer is active. As a matter of fact, adversaries that observe > the length of the compressed data might be able to derive > information about it, when public data (that adversaries know is > read) and confidential data are compressed in the same compress sessi= on. That sounds great; thanks. > I suggested SHOULD because I thought MUST was too strong. > It would imply that clients and servers have a way to specify > the confidentialness of newsgroups. It currently does not exist, > and I doubt a user would maintain it in its news client. Yes, that makes sense. >> Additionally, implementations MAY ensure that the contents of two >> distinct confidential articles are not compressed together. >> >> Of course they MAY, but what's the point of saying that. I think >> you'd be much better off skipping the 2119 key word here, and instead >> say something about why it might be good to do this: what's the >> advantage? Something like, "Additionally, implementations would do >> well to ensure that the contents of two distinct confidential articles >> are not compressed together, because [of this advantage]." > > We had in mind the following scenario: > > "[...], because adversaries might be able to derive information about > confidential articles as they may have identical header fields (like > Subject, Newsgroups or From) or header fields whose contents may be > predictable (like Xref or Injection-Info)." > > Maybe "predictable" is not the right word. > "have a structured pattern"? "are formatted in a known syntax?" > > Examples: > Injection-Info: news.trigofacile.com; posting-account=3D"eliej"; > posting-host=3D"news.trigofacile.com:2001:41d0:1:6d44::1"; > logging-data=3D"29828"; mail-complaints-to=3D"abuse@trigofacile.c= om" > Xref: news.trigofacile.com trigofacile.test:566 > > Do you have a preferred wording for that paragraph? > (Should a reference to RFC 5536 be also mentioned? Like "These header > fields are described in [RFC5536].") As I say, maybe just drop the key word and say it without capitals. If it's not easy to explain or determine, maybe just say that it's good to do it if you can: NEW Additionally, it is preferable not to compress the contents of two distinct confidential articles together if it can be avoided. END But, again, it's a small point that probably doesn't need further discussio= n. > In the registry, it is indeed best to use upper case. I can mention it. > > Just to be certain of the meaning of your remark: the algorithm name > in the NNTP command is not required to be upper case. > > algorithm =3D "DEFLATE" / 1*20alg-char > alg-char =3D UPPER / DIGIT / "-" / "_" > > ABNF syntax is not case-sensitive, so "COmprESs dEFlaTe" is a valid > NNTP command, that has the same effect as "COMPRESS DEFLATE". Actually, that's an ABNF error that I missed: "DEFLATE" doesn't have to be in upper case, but any *other* algorithm does (because "alg-char" can only contain UPPER, not ALPHA or LOWER). To fix that, I suggest using this: algorithm =3D %s"DEFLATE" / 1*20alg-char ...and adding a normative reference to RFC 7405... that forces DEFLATE to be upper case. Unless, of course, you really want to allow case-insensitivity here. If that's so, you'll need to change the definition of alg-char to use ALPHA, and you'll need to tell IANA that all values should be converted to upper case when they're registered (so that we won't wind up with "FLOOB" and "floob" both being registered). >> Oy. This really sounds convoluted to me, and the "MAY, but SHOULD >> NOT" is a direct contradiction. > > Just saying that an implementation has the possibility to do that (MAY) > but is not encouraged to (SHOULD NOT). But that's not what it says: "MAY" doesn't mean it's possible; it means that the choice is entirely an option. So what that's really saying is that it's perfectly OK to do either, at your option... and then making a fairly strong restriction against one of the options. I think that's poorly specified and can be confusing. Considering what you say in your response after that, let me suggest an alternative: NEW If the server advertises a registered NNTP compression algorithm, it MUST implement the compression algorithm so as to fully conform with its related specification. If it does not implement the compression algorithm as specified, the implementation is considered a private algorithm and MUST NOT be listed with the registered name in the arguments list of the COMPRESS capability label. Private algorithms with unregistered names are allowed, but SHOULD NOT be used because it is difficult to achieve interoperability with the= m. END How's that? >> A server MUST NOT send different response codes to COMPRESS in >> response to the availability or use of a private compression >> algorithm. >> >> I don't understand what this is saying at all. Different from what? >> Can you clarify this? > > Suggestion: > > The 206, 403, and 502 response codes a news server answers > to COMPRESS using a private compression algorithm MUST have the > same meaning as the one documented in Section 2.2 of this document. Ah, yes, very clear now. Thanks. > Thanks again for your valuable comments to help improve the quality > of the document. You're welcome; I'm glad they've been helpful. Barry From nobody Wed Sep 21 09:40:50 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA3112B593; Wed, 21 Sep 2016 09:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzE2YUse5lVD; Wed, 21 Sep 2016 09:40:42 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 6E88D12B5A5; Wed, 21 Sep 2016 09:40:42 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id i129so63058954ywb.0; Wed, 21 Sep 2016 09:40: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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=h3TuU42hYxb6Bw0JcAVU+ZRO6EBLUQIWlrnky9SVv04=; b=zvP8ks466ycAKfCTpqvpXAz1TEffDwVIQC48AKzKqNU/29Q6uwNwR0V4Ajt3GsaMXh OkddsLkUv62rQI0ioQsFvNe1RjbuIAgpxRobytjJJzo5Na3ZcmoToGRE2IOiLD/kqsRW sKPDQd0UEzca+OtJNjs2EcnDeme+RTpepxm/8Pg4RkQ2eC5i58xCEnHk52OxawUWZ9AH OJoVeMbjJ2fQL3jEsrjmOV6lJJH8KSwsqTUOHYQ9gJ7yvda6fplbS/suxWsn6LxadiIi bPla896y/uT0MRTOvQZPy+90lEs6xK3ZncRC8DROBnmKzJPCEB9TtQ7ZGssNBWKOjHHR 9rOw== 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-transfer-encoding; bh=h3TuU42hYxb6Bw0JcAVU+ZRO6EBLUQIWlrnky9SVv04=; b=AlHgUVUr8Lj5NinZn7xkePBC9sTlTP9rG7DqKKRkMvX1o0BHD93WIfBHj3XmDX+veS xSn54sgVe2Wj0j2grJXZL9ceINESV2nJtBAU8H3McCF6130v5exvv4XSJquN7M0a5BMD PiM6GIWPl5Coyz4Rbnyaz2FcFpV0inFVg/CT3a6Xz0eekodWsYjQVrUgEdc9AEYXyEdH KVGr7f61fOxkGu3uX51u7W4rbXdLYd9YgBRjiYkX2fZRtDz/svujAANWe/X/sYLJAuGm BU8l6NofZnxC6yKJqIKEkpJFQV1nZe55bFpBnKIAmfViC0yIgBGmnox7LiITLj6deHNr ByFg== X-Gm-Message-State: AE9vXwPc2yThdkIvE54li4irxffQEk3Nrhln/UZobluXFOYnGls7ctEOVm4MoI+b52dryP60cN07QoRNy8WKzQ== X-Received: by 10.13.197.197 with SMTP id h188mr32544997ywd.202.1474476041389; Wed, 21 Sep 2016 09:40:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Wed, 21 Sep 2016 09:40:40 -0700 (PDT) In-Reply-To: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> References: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> From: Kathleen Moriarty Date: Wed, 21 Sep 2016 12:40:40 -0400 Message-ID: To: Stephen Kent , "iesg@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jim Schaad , Kepeng Li , Justin Richer , secdir Subject: Re: [secdir] secdir review of cose-msg-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 16:40:45 -0000 Hi Steve, Thank you very much for your detailed review, it's helpful. I'll respond on the normative/informative question, the chairs and/or Jim should respond on your other questions as some (like removing text) may not be done as I believe it was WG consensus to have the content you mention in this draft. The nits are helpful too, so Jim will add those into the next revision. On Wed, Sep 21, 2016 at 10:26 AM, Stephen Kent wrote: > SECDIR review of draft-ietf-cose-msg-18 > > > > 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 with the intent of improving security requirements = and > considerations in IETF drafts. Comments not addressed in last call may b= e > included in AD reviews during the IESG review. Document editors and WG > chairs should treat these comments just like any other last call comments= . > > > > This document defines formats for signing and/or encryption of data encod= ed > using CBOR (RFC7049). The signing/encryption approach adopted here is bas= ed > on the standards developed in JOSE (RFCs 7515-18), since CBOR is based on > JSON. > > > > This is a large document: about 90 pages plus almost 30 pages of appendic= es > (providing useful examples). Close to half of the (non-appendix portion) > document is devoted to specifications for a set of algorithms for > encryption, signatures, message authentication, and key distribution. Onl= y > when the reader reaches page 73 is it made clear that the algorithm > descriptions are not MTI; they define a set from which application > developers must (?) choose when creating a profile for COSE use in a > specific application context. Given the long-standing IETF policy to tryi= ng > to facilitate algorithm agility, > > I think it preferable to extract these descriptions and publish them as > separate RFCs, a practice often employed in documenting many other securi= ty > protocols (including JOSE, from which this work is based). > > > > > > The document begins with a brief explanation of how COSE differs from JOS= E, > an excellent preface to the document. The cited design differences all se= em > very appropriate for CBOR, e.g., using binary encoding instead of base64u= rl, > shedding some of the odd constraints adopted in JOSE because of pre-exist= ing > work in the area, and updating the list of algorithms. > > > > Since there is no standard grammar for CBOR, the author adopted the > primitive types defined in an I-D (draft-ietf- > greevenbosch-appsawg-cbor-cddl) to allow for a concise specification of C= OSE > formats. I recommend that this document be held for publication until tha= t > I-D is approved. I also note that the cited I-D is Informational, but thi= s > document is Standards Track. the cited I-D is listed as informative, but = the > syntax it defines is used extensively throughout this document, thus I > believe it really is normative. The reference is fine as informative IMO as it is clearly stated in the draft in Section 1.3: "The CDDL grammar is informational, the prose description is normati= ve." This is common and we've seen many drafts using UML descriptions and other formats similarly. Thank you, Kathleen > > > > > > Section 2 defines the basic COSE data structure. The description seems cl= ear > and logical, but the list of message types is a bit puzzling (absent > information that is provided later, in Sections 4 and 5). For example, th= ere > is a Single Signer data Object, and a Signed Data Object. If the latter > accommodates multiple signers, why not make that part of the name? The sa= me > nomenclature confusion arises for encrypted objects directed to a single > recipient vs. multiple recipients. > > > > > > Section 3 Describes the header parameters. It provides generally good, > detailed descriptions of the common header elements and explains why cert= ain > conventions are adopted. It clearly describes requirements imposed on > senders and recipients. > > > > > > Section 4 describes the objects used to convey one or more signatures for > objects. The description here is a bit confusing when it discusses one vs= . > multiple signatures. The format that allows carriage of multiple signatur= es > does not necessarily imply that there are multiple signers, e.g., the > multiple signatures may be present to accommodate different algorithm > capabilities for different recipients. The introduction to 4.2 says: > > =E2=80=9CThe COSE_Sign1 signature structure is used when only one sig= ner is > going to be placed on a message.=E2=80=9D > > Perhaps it would be clearer to say that this structure is used when only = one > signature is to be placed in a message. > > > > Overall this section is well written and provides useful details about ho= w > to compute signatures and counter signatures. > > > > > > Section 5 describes the COSE encryption objects. I disagree with one choi= ce > of terminology adopted here: =E2=80=9Crecipient algorithm classes=E2=80= =9D which is > described in 5.1.1. This is really a discussion of classes of key > distribution/management algorithms, focusing on how each recipient of an > encrypted message acquires the CEK used to decrypt the message. I=E2=80= =99d prefer a > less obscure name for this sub-section. Otherwise this section is well > written and provide lots of useful details about how to encrypt and decry= pt > messages for two classes of encryption algorithms. > > > > > > Section 6 describes the MAC objects. Here too there are two types of > structures, depending on whether a recipient implicitly knows what key to > use to verify the MAC, or whether an ID for one or more MAC keys must be > communicated. The text here closely parallels that of Section 5 and is ve= ry > good. > > > > > > Section 7 describes the COSE key structure. It is designed to accommodate > the data needed by a wide range of key distribution mechanisms and > encryption techniques. > > > > > > Section 8 defines two classes of signature algorithms that can be used wi= th > COSE, specifies an algorithm of each type, and provides security guidance > for each algorithm. I think it would be preferable to remove the detailed > algorithm descriptions (Sections 8.1 and 8.2) and associated security > considerations (which are well written) from this document. The comments > below apply to sections 9, 10, 11 and 12. > > > > I have several concerns about including the algorithm (vs. algorithm clas= s) > descriptions here. For many security protocols (and security-focused data > formats), we usually (though not always) specify mandatory and optional t= o > implement algorithms in separate documents, to facilitate algorithm agili= ty. > I think we should follow that model for COSE. Also, the text here does no= t > mandate support for these algorithms; it merely provides details for a se= t > of algorithms that a sender and/or receive may choose to implement. One h= as > to read the final sentence of the opening paragraph of Section 15 to lear= n > that this is the intent, i.e., that selection of specific algorithms is > deferred to the each application that makes use of COSE. Given that later > statement, it appears that the algorithms specified in Sections 8-12 ate > intended to define the set from which application developer MUST choose, = but > that too is not clearly stated. I think this makes it even more appropria= te > to remove the detailed algorithm discussions from this document. > > > > Section 12 describes the =E2=80=9Crecipient algorithm classes=E2=80=9D ak= a key > distribution/management methods. Most of this section is analogous to the > preceding sections (9-11) where specific algorithms are described for use > with COSE, and thus my comments about undue bundling of algorithms with a > protocol specs apply here too. I do not object to describing key transpor= t, > key wrapping and key agreement methods in general, but the detailed specs= in > 12.2.1, 12.4.1 and 12.5.1 seem inappropriate here, for the reasons noted > above. > > > > > > Section 13 describes parameters for key objects used by COSE. The specs h= ere > are sufficiently generic that they do not suffer from the problems I note= d > for Sections 8-12. > > > > > > Section 15 provides guidance for application developers making use of COS= E. > This is where a reader finally discovers that the algorithms described i= n > Sections 8-12 are not MTI, and that each application is expected to speci= fy > which algorithms are MTI in that context, to facilitate interoperability. > > > > Section 16 (IANA Considerations) describes the registries that need to be > created for COSE, and extensions to the CoAP registry to support COSE. It > seem to be well written and comprehensive. > > > > Section 18 (Security Considerations) is a good adjunct to the already > well-written security considerations discussions provided for the algorit= hms > in Sections 8-12. > > > > > > Typos and suggested rewording. > > > > Section 2: > > > > The COSE object structure is designed so that there can be a large amount= of > common code when parsing and processing the different > > security messages. > > -> The COSE object structure is designed so that there can be a large > amount of common code when parsing and processing the different types of > security messages. > > > > COSE messages are also built using the concept of using layers to =E2=80= =A6 > > -> COSE messages are built using the concept of layers to =E2=80=A6 > > > > Section 3: > > > > The integer and string values for labels has been divided =E2=80=A6 > > -> The integer and string values for labels have been divided =E2=80=A6 > > > > Applications SHOULD perform the same checks that the same label =E2=80=A6 > > -> Applications SHOULD verify that the same label =E2=80=A6 > > > > Applications should have a statement if the label can be omitted. > > -> Applications SHOULD (?) have a statement if the label can be omitted. > > > > Integers are from the "CoAP Content-Formats" IANA registry table. (no > reference) > > > > As the IV is authenticated by the encryption process, it can be placed in > the unprotected header bucket. (in general, an encryption process will no= t > =E2=80=9Cauthenticate=E2=80=9D an IV, but use of a modified IV will yield= mangled plaintext, > which can be detected by an integrity check or a signature. the same comm= ent > applies to the similar statement in the =E2=80=9Cpartial IV=E2=80=9D desc= ription.) > > > > > > Section 4: > > > > Edwards Digital Signature Algorithm (EdDSA) signature algorithm and with = the > Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithm. > > -> Edwards Digital Signature Algorithm (EdDSA) (cite) and with the Ellipt= ic > Curve Digital Signature Algorithm (ECDSA) (cite). > > > > One of the features supplied in the COSE document is the ability=E2=80=A6 > > -> One of the features offered by the COSE format is the ability =E2=80= =A6 > > > > This algorithm takes in the body information =E2=80=A6 > > -> The signing and verification processes take in the body information = =E2=80=A6 > > > > Counter signatures provide a method of having a different signature occur= on > some piece of content. > > -> Counter signatures provide a method of associating different signature= s > generated by different signers with some piece of content. > > > > > > Section 5 > > > > Other: The key is randomly generated. > > -> Other: The key is randomly or pseudo-randomly generated. > > > > > > Section 6 > > > > (This knowledge of sender assumes that there are only two parties involve= d > and you did not send the message yourself.) > > -> (This knowledge of sender assumes that there are only two parties > involved and you did not send the message to yourself.) > > > > > > Section 15: > > > > It is intended that a profile of this document be created that > > defines the interopability > > -> It is intended that a profile of this document be created that > > defines the interoperability --=20 Best regards, Kathleen From nobody Wed Sep 21 13:20:11 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8245F12B213; Wed, 21 Sep 2016 13:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfPOmtg3WD3f; Wed, 21 Sep 2016 13:20:04 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 79F9612B7CA; Wed, 21 Sep 2016 13:20:01 -0700 (PDT) X-AuditID: 1209190f-8dfff70000003b8b-0a-57e2eb6f6f02 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 (Symantec Messaging Gateway) with SMTP id 39.A9.15243.F6BE2E75; Wed, 21 Sep 2016 16:20:00 -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 u8LKJria011900; Wed, 21 Sep 2016 16:19:53 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u8LKJmCn015760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 21 Sep 2016 16:19:52 -0400 To: Kathleen Moriarty , Stephen Kent , "iesg@ietf.org" References: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> From: Justin Richer Message-ID: Date: Wed, 21 Sep 2016 16:19:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0S14/Sjc4O1fPosZfyYyW6ye/p3N omFnvsXG2YwWl+cXWXxY+JDFgc1j4tuPLB4b50xn85h6PtRj56y77B5LlvxkCmCN4rJJSc3J LEst0rdL4MqY/GMbU8Gh7Iq/N7cwNTB+C+1i5OSQEDCRmPpjEVMXIxeHkEAbk8SFpd9ZIZyN jBK7mxcxQji3mSRW33zBBtIiLKApMW3Cc2YQW0SgXuJgbw8zRFEjo8Tt5YeZQBLMAkUS62Yv ZgSx2QRUJaavaQGL8wpYSfQ+ewU2iAUo/vPlFVYQW1QgRmL/rJnMEDWCEidnPmEBsTkFAiX6 735khJhpJjFv80NmCFteonnrbOYJjAKzkLTMQlI2C0nZAkbmVYyyKblVurmJmTnFqcm6xcmJ eXmpRbomermZJXqpKaWbGEGhzinJv4NxToP3IUYBDkYlHt6I7kfhQqyJZcWVuYcYJTmYlER5 u7cAhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nw/rwOlONNSaysSi3Kh0lJc7AoifN2zTgQLiSQ nliSmp2aWpBaBJOV4eBQkuBlugPUKFiUmp5akZaZU4KQZuLgBBnOAzR80m2Q4cUFibnFmekQ +VOMilLivBogCQGQREZpHlwvKBUlvD1s+opRHOgVYd4okBU8wDQG1/0KaDAT0OAtPx+ADC5J REhJNTDyPJwifrfzYvGKCdPdnHZP8a+qe/e86cAbv8YLcWte/VQu/es0cXfntJeX49pM3dax lS8+/zxv+zeNvidbDz7mjRewXpPKOn15utXkI+uUynKKjVeoRbFcmLiV7W2M2qcCvYYDK40u POn28wwIn+3ZVx/VYNc/6fiLqEmuL//VHWL1//hdtrxaiaU4I9FQi7moOBEAO5kaXiADAAA= Archived-At: Cc: Jim Schaad , Kepeng Li , secdir Subject: Re: [secdir] secdir review of cose-msg-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 20:20:09 -0000 Hi Steve, Thank you for the thorough review of the specification. Speaking for the COSE chairs, I want to confirm that it was WG consensus to keep everything in a single document. This was partially in reaction to community dissatisfaction with the document arrangement of JOSE, from which this work originally grew. Additionally, there was WG discussion and consensus around the use of CDDL in the document. The CDDL is used throughout the document in a non-normative example fashion. The normative requirements in terms of data structures and construction of COSE objects is in the surrounding text. The editor and WG could have adopted an arbitrary description language, or invented one out of whole cloth for this purpose, but a simple one had already been written down and was available. Due to it being still in draft and an informational document, the WG decided to not have a normative requirement on CDDL and to not rely on the CDDL listings in a normative fashion. Hopefully this clears up those two issues, and I'll let Jim answer the remainder. Thank you, -- Justin Richer On 9/21/2016 12:40 PM, Kathleen Moriarty wrote: > Hi Steve, > > Thank you very much for your detailed review, it's helpful. I'll > respond on the normative/informative question, the chairs and/or Jim > should respond on your other questions as some (like removing text) > may not be done as I believe it was WG consensus to have the content > you mention in this draft. The nits are helpful too, so Jim will add > those into the next revision. > > On Wed, Sep 21, 2016 at 10:26 AM, Stephen Kent wrote: >> SECDIR review of draft-ietf-cose-msg-18 >> >> >> >> I have reviewed this document as part of the security directorate's ongoing >> effort to review all IETF documents being processed by the IESG. These >> comments were written with the intent of improving security requirements and >> considerations in IETF drafts. Comments not addressed in last call may be >> included in AD reviews during the IESG review. Document editors and WG >> chairs should treat these comments just like any other last call comments. >> >> >> >> This document defines formats for signing and/or encryption of data encoded >> using CBOR (RFC7049). The signing/encryption approach adopted here is based >> on the standards developed in JOSE (RFCs 7515-18), since CBOR is based on >> JSON. >> >> >> >> This is a large document: about 90 pages plus almost 30 pages of appendices >> (providing useful examples). Close to half of the (non-appendix portion) >> document is devoted to specifications for a set of algorithms for >> encryption, signatures, message authentication, and key distribution. Only >> when the reader reaches page 73 is it made clear that the algorithm >> descriptions are not MTI; they define a set from which application >> developers must (?) choose when creating a profile for COSE use in a >> specific application context. Given the long-standing IETF policy to trying >> to facilitate algorithm agility, >> >> I think it preferable to extract these descriptions and publish them as >> separate RFCs, a practice often employed in documenting many other security >> protocols (including JOSE, from which this work is based). >> >> >> >> >> >> The document begins with a brief explanation of how COSE differs from JOSE, >> an excellent preface to the document. The cited design differences all seem >> very appropriate for CBOR, e.g., using binary encoding instead of base64url, >> shedding some of the odd constraints adopted in JOSE because of pre-existing >> work in the area, and updating the list of algorithms. >> >> >> >> Since there is no standard grammar for CBOR, the author adopted the >> primitive types defined in an I-D (draft-ietf- >> greevenbosch-appsawg-cbor-cddl) to allow for a concise specification of COSE >> formats. I recommend that this document be held for publication until that >> I-D is approved. I also note that the cited I-D is Informational, but this >> document is Standards Track. the cited I-D is listed as informative, but the >> syntax it defines is used extensively throughout this document, thus I >> believe it really is normative. > The reference is fine as informative IMO as it is clearly stated in > the draft in Section 1.3: > > "The CDDL grammar is informational, the prose description is normative." > > This is common and we've seen many drafts using UML descriptions and > other formats similarly. > > Thank you, > Kathleen > >> >> >> >> >> Section 2 defines the basic COSE data structure. The description seems clear >> and logical, but the list of message types is a bit puzzling (absent >> information that is provided later, in Sections 4 and 5). For example, there >> is a Single Signer data Object, and a Signed Data Object. If the latter >> accommodates multiple signers, why not make that part of the name? The same >> nomenclature confusion arises for encrypted objects directed to a single >> recipient vs. multiple recipients. >> >> >> >> >> >> Section 3 Describes the header parameters. It provides generally good, >> detailed descriptions of the common header elements and explains why certain >> conventions are adopted. It clearly describes requirements imposed on >> senders and recipients. >> >> >> >> >> >> Section 4 describes the objects used to convey one or more signatures for >> objects. The description here is a bit confusing when it discusses one vs. >> multiple signatures. The format that allows carriage of multiple signatures >> does not necessarily imply that there are multiple signers, e.g., the >> multiple signatures may be present to accommodate different algorithm >> capabilities for different recipients. The introduction to 4.2 says: >> >> “The COSE_Sign1 signature structure is used when only one signer is >> going to be placed on a message.†>> >> Perhaps it would be clearer to say that this structure is used when only one >> signature is to be placed in a message. >> >> >> >> Overall this section is well written and provides useful details about how >> to compute signatures and counter signatures. >> >> >> >> >> >> Section 5 describes the COSE encryption objects. I disagree with one choice >> of terminology adopted here: “recipient algorithm classes†which is >> described in 5.1.1. This is really a discussion of classes of key >> distribution/management algorithms, focusing on how each recipient of an >> encrypted message acquires the CEK used to decrypt the message. I’d prefer a >> less obscure name for this sub-section. Otherwise this section is well >> written and provide lots of useful details about how to encrypt and decrypt >> messages for two classes of encryption algorithms. >> >> >> >> >> >> Section 6 describes the MAC objects. Here too there are two types of >> structures, depending on whether a recipient implicitly knows what key to >> use to verify the MAC, or whether an ID for one or more MAC keys must be >> communicated. The text here closely parallels that of Section 5 and is very >> good. >> >> >> >> >> >> Section 7 describes the COSE key structure. It is designed to accommodate >> the data needed by a wide range of key distribution mechanisms and >> encryption techniques. >> >> >> >> >> >> Section 8 defines two classes of signature algorithms that can be used with >> COSE, specifies an algorithm of each type, and provides security guidance >> for each algorithm. I think it would be preferable to remove the detailed >> algorithm descriptions (Sections 8.1 and 8.2) and associated security >> considerations (which are well written) from this document. The comments >> below apply to sections 9, 10, 11 and 12. >> >> >> >> I have several concerns about including the algorithm (vs. algorithm class) >> descriptions here. For many security protocols (and security-focused data >> formats), we usually (though not always) specify mandatory and optional to >> implement algorithms in separate documents, to facilitate algorithm agility. >> I think we should follow that model for COSE. Also, the text here does not >> mandate support for these algorithms; it merely provides details for a set >> of algorithms that a sender and/or receive may choose to implement. One has >> to read the final sentence of the opening paragraph of Section 15 to learn >> that this is the intent, i.e., that selection of specific algorithms is >> deferred to the each application that makes use of COSE. Given that later >> statement, it appears that the algorithms specified in Sections 8-12 ate >> intended to define the set from which application developer MUST choose, but >> that too is not clearly stated. I think this makes it even more appropriate >> to remove the detailed algorithm discussions from this document. >> >> >> >> Section 12 describes the “recipient algorithm classes†aka key >> distribution/management methods. Most of this section is analogous to the >> preceding sections (9-11) where specific algorithms are described for use >> with COSE, and thus my comments about undue bundling of algorithms with a >> protocol specs apply here too. I do not object to describing key transport, >> key wrapping and key agreement methods in general, but the detailed specs in >> 12.2.1, 12.4.1 and 12.5.1 seem inappropriate here, for the reasons noted >> above. >> >> >> >> >> >> Section 13 describes parameters for key objects used by COSE. The specs here >> are sufficiently generic that they do not suffer from the problems I noted >> for Sections 8-12. >> >> >> >> >> >> Section 15 provides guidance for application developers making use of COSE. >> This is where a reader finally discovers that the algorithms described in >> Sections 8-12 are not MTI, and that each application is expected to specify >> which algorithms are MTI in that context, to facilitate interoperability. >> >> >> >> Section 16 (IANA Considerations) describes the registries that need to be >> created for COSE, and extensions to the CoAP registry to support COSE. It >> seem to be well written and comprehensive. >> >> >> >> Section 18 (Security Considerations) is a good adjunct to the already >> well-written security considerations discussions provided for the algorithms >> in Sections 8-12. >> >> >> >> >> >> Typos and suggested rewording. >> >> >> >> Section 2: >> >> >> >> The COSE object structure is designed so that there can be a large amount of >> common code when parsing and processing the different >> >> security messages. >> >> -> The COSE object structure is designed so that there can be a large >> amount of common code when parsing and processing the different types of >> security messages. >> >> >> >> COSE messages are also built using the concept of using layers to … >> >> -> COSE messages are built using the concept of layers to … >> >> >> >> Section 3: >> >> >> >> The integer and string values for labels has been divided … >> >> -> The integer and string values for labels have been divided … >> >> >> >> Applications SHOULD perform the same checks that the same label … >> >> -> Applications SHOULD verify that the same label … >> >> >> >> Applications should have a statement if the label can be omitted. >> >> -> Applications SHOULD (?) have a statement if the label can be omitted. >> >> >> >> Integers are from the "CoAP Content-Formats" IANA registry table. (no >> reference) >> >> >> >> As the IV is authenticated by the encryption process, it can be placed in >> the unprotected header bucket. (in general, an encryption process will not >> “authenticate†an IV, but use of a modified IV will yield mangled plaintext, >> which can be detected by an integrity check or a signature. the same comment >> applies to the similar statement in the “partial IV†description.) >> >> >> >> >> >> Section 4: >> >> >> >> Edwards Digital Signature Algorithm (EdDSA) signature algorithm and with the >> Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithm. >> >> -> Edwards Digital Signature Algorithm (EdDSA) (cite) and with the Elliptic >> Curve Digital Signature Algorithm (ECDSA) (cite). >> >> >> >> One of the features supplied in the COSE document is the ability… >> >> -> One of the features offered by the COSE format is the ability … >> >> >> >> This algorithm takes in the body information … >> >> -> The signing and verification processes take in the body information … >> >> >> >> Counter signatures provide a method of having a different signature occur on >> some piece of content. >> >> -> Counter signatures provide a method of associating different signatures >> generated by different signers with some piece of content. >> >> >> >> >> >> Section 5 >> >> >> >> Other: The key is randomly generated. >> >> -> Other: The key is randomly or pseudo-randomly generated. >> >> >> >> >> >> Section 6 >> >> >> >> (This knowledge of sender assumes that there are only two parties involved >> and you did not send the message yourself.) >> >> -> (This knowledge of sender assumes that there are only two parties >> involved and you did not send the message to yourself.) >> >> >> >> >> >> Section 15: >> >> >> >> It is intended that a profile of this document be created that >> >> defines the interopability >> >> -> It is intended that a profile of this document be created that >> >> defines the interoperability > > From nobody Wed Sep 21 16:52:59 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B153812B7FC for ; Wed, 21 Sep 2016 16:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxaUxUhI_KbJ for ; Wed, 21 Sep 2016 16:52:53 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B13012B56A for ; Wed, 21 Sep 2016 16:42:58 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Sep 2016 16:56:12 -0700 From: Jim Schaad To: 'Stephen Kent' , 'secdir' , 'Justin Richer' , 'Kepeng Li' , 'Kathleen Moriarty' References: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> In-Reply-To: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> Date: Wed, 21 Sep 2016 16:42:48 -0700 Message-ID: <080101d21461$de39f850$9aade8f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLn+ErX890UkhHKZArMVoO8r82N055YgYfQ Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: Re: [secdir] secdir review of cose-msg-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 23:52:55 -0000 Hi Steve, Good to hear from you again. I will be doing a second message on the = nits so that I can make them at the same time that I do the response. It is always good to have a comprehensive and useful review and one with = action items. Thanks for that Comments in line jim From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Wednesday, September 21, 2016 7:27 AM To: secdir ; Jim Schaad ; = Justin Richer ; Kepeng Li ; = Kathleen Moriarty Subject: secdir review of cose-msg-18 SECDIR review of draft-ietf-cose-msg-18 =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 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. =20 This document defines formats for signing and/or encryption of data = encoded using CBOR (RFC7049). The signing/encryption approach adopted = here is based on the standards developed in JOSE (RFCs 7515-18), since = CBOR is based on JSON.=20 =20 This is a large document: about 90 pages plus almost 30 pages of = appendices (providing useful examples). Close to half of the = (non-appendix portion) document is devoted to specifications for a set = of algorithms for encryption, signatures, message authentication, and = key distribution. Only when the reader reaches page 73 is it made clear = that the algorithm descriptions are not MTI; they define a set from = which application developers must (?) choose when creating a profile for = COSE use in a specific application context. Given the long-standing IETF = policy to trying to facilitate algorithm agility, =20 I think it preferable to extract these descriptions and publish them as = separate RFCs, a practice often employed in documenting many other = security protocols (including JOSE, from which this work is based).=20 [JLS] This was the approach that I had originally intended to take, = breaking the document in two pieces towards the end when things were = settled. My memory is that this was discussed in the working group, and = it was determined that one document was preferable to having two = different documents. I believe that this practice started with CMS and = it was done there to deal with the question of how to advance to = standards track for the format document and still allow the algorithm = document to be updated. This has not seemed to be how things have = worked in practice, or has been necessary as protocol documents such as = S/MIME is where the implementation requirements on algorithms are = specified rather than in the format draft (CMS). I therefore have less = problems with the fact that this is one draft from that standpoint. It = would have been nicer just from a length prospective, but people thought = that being able to reference back and forth in a single HTML page to be = better than flipping between different pages. =20 Since there is no standard grammar for CBOR, the author adopted the = primitive types defined in an I-D (draft-ietf- = greevenbosch-appsawg-cbor-cddl) to allow for a concise specification of = COSE formats. I recommend that this document be held for publication = until that I-D is approved. I also note that the cited I-D is = Informational, but this document is Standards Track. the cited I-D is = listed as informative, but the syntax it defines is used extensively = throughout this document, thus I believe it really is normative. [JLS] There was a long discussion about what to do with the CDDL = grammar portions of the document. Like me, it would appear that you are = a strong advocate of doing formal languages and making them normative = rather than making descriptive text normative. Given the state of CDDL = making it a normative reference would be difficult since it is still = being transformed. I have argued with the authors to try and get what = is there published but have not been successful. During the discussion there were several versions where presented as = alternatives. * The current mixing of CDDL and text * Moving the CDDL to the end of the section that it relates to=20 * Moving the CDDL to an appendix * Removing the CDDL entirely. I argued against the last option as I find formal language to be useful. = As I placed the CDDL in line to start with as it makes it easier to = validate the language and the text as being the same that became = somewhat of the baseline, however at least one version of the document = moved all of the CDDL to the end of the section so people did have a = change to see what that would look like. After much discussion, the = group decided that it wanted to keep the current format as they did not = like having it at the end of the section. =20 The draft is cited as informative because the document states that the = text description is to be normative and there is a full duplication of = the CDDL in the text. One can remove the CDDL and a complete = description of how to encode things is still I the document. =20 =20 Section 2 defines the basic COSE data structure. The description seems = clear and logical, but the list of message types is a bit puzzling = (absent information that is provided later, in Sections 4 and 5). For = example, there is a Single Signer data Object, and a Signed Data Object. = If the latter accommodates multiple signers, why not make that part of = the name? The same nomenclature confusion arises for encrypted objects = directed to a single recipient vs. multiple recipients. [JLS] I thought about making this change in the past but had an issue = with the fact that this might make people think that the Signed Data = object version could only be used if there were two or more signers. It = allows for one or more signers so it is a bit of a misnomer to say that = it is a multiple signer version. The structures are build in such a way = that one cannot switch between the versions so you cannot just go from = the Single Signer to the Multiple Signer when a second signature is = added. I can understand the issue you are raising, but the solution has similar = issues. The term "One or More Signer Data Object" seems to be a bit = unwieldy. Other suggestions would be welcome. =20 Section 4 describes the objects used to convey one or more signatures = for objects. The description here is a bit confusing when it discusses = one vs. multiple signatures. The format that allows carriage of multiple = signatures does not necessarily imply that there are multiple signers, = e.g., the multiple signatures may be present to accommodate different = algorithm capabilities for different recipients. The introduction to 4.2 = says:=20 =E2=80=9CThe COSE_Sign1 signature structure is used when only one = signer is going to be placed on a message.=E2=80=9D Perhaps it would be clearer to say that this structure is used when only = one signature is to be placed in a message. [JLS] Makes sense - done. =20 =20 Section 5 describes the COSE encryption objects. I disagree with one = choice of terminology adopted here: =E2=80=9Crecipient algorithm = classes=E2=80=9D which is described in 5.1.1. This is really a = discussion of classes of key distribution/management algorithms, = focusing on how each recipient of an encrypted message acquires the CEK = used to decrypt the message. I=E2=80=99d prefer a less obscure name for = this sub-section. Otherwise this section is well written and provide = lots of useful details about how to encrypt and decrypt messages for two = classes of encryption algorithms. [JLS] I agree that the term is not optimal. There was a long discussion = about this in the WG on the mailing list. The original term used was = "key management classes" (if memory serves) and there were issues raised = because this is not key management in the world of how does a client get = a symmetric or public key. The fact that the term was ambiguous as to = the problem being solved was thought to be an issue. After a long = discussion the term "recipient algorithm classes" was adopted. =20 =20 Section 6 describes the MAC objects. Here too there are two types of = structures, depending on whether a recipient implicitly knows what key = to use to verify the MAC, or whether an ID for one or more MAC keys must = be communicated. The text here closely parallels that of Section 5 and = is very good. =20 =20 Section 8 defines two classes of signature algorithms that can be used = with COSE, specifies an algorithm of each type, and provides security = guidance for each algorithm. I think it would be preferable to remove = the detailed algorithm descriptions (Sections 8.1 and 8.2) and = associated security considerations (which are well written) from this = document. The comments below apply to sections 9, 10, 11 and 12.=20 =20 I have several concerns about including the algorithm (vs. algorithm = class) descriptions here. For many security protocols (and = security-focused data formats), we usually (though not always) specify = mandatory and optional to implement algorithms in separate documents, to = facilitate algorithm agility. I think we should follow that model for = COSE. Also, the text here does not mandate support for these algorithms; = it merely provides details for a set of algorithms that a sender and/or = receive may choose to implement. One has to read the final sentence of = the opening paragraph of Section 15 to learn that this is the intent, = i.e., that selection of specific algorithms is deferred to the each = application that makes use of COSE. Given that later statement, it = appears that the algorithms specified in Sections 8-12 ate intended to = define the set from which application developer MUST choose, but that = too is not clearly stated. I think this makes it even more appropriate = to remove the detailed algorithm discussions from this document. =20 [JLS] There is discussion on making things a separate document up above. Section 15 was placed to be near the other "Considerations" sections and = so that it would not need to do any clarification language about the = issues. This section could just as easily be placed immediately = following Section 1 (Introduction) which would allow people to = understand that not only are the algorithms presented as not MTI but the = same thing is true on the structures. Would that alleviate some of = your concerns? =20 Section 12 describes the =E2=80=9Crecipient algorithm classes=E2=80=9D = aka key distribution/management methods. Most of this section is = analogous to the preceding sections (9-11) where specific algorithms are = described for use with COSE, and thus my comments about undue bundling = of algorithms with a protocol specs apply here too. I do not object to = describing key transport, key wrapping and key agreement methods in = general, but the detailed specs in 12.2.1, 12.4.1 and 12.5.1 seem = inappropriate here, for the reasons noted above. =20 =20 Section 15 provides guidance for application developers making use of = COSE. This is where a reader finally discovers that the algorithms = described in Sections 8-12 are not MTI, and that each application is = expected to specify which algorithms are MTI in that context, to = facilitate interoperability. [JLS] See above question =20 From nobody Wed Sep 21 17:41:20 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FC412BA52; Wed, 21 Sep 2016 17:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=cIszTHv7; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=oot2tw4H 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 fKNoP3_ksTah; Wed, 21 Sep 2016 17:41:17 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213F012BB9C; Wed, 21 Sep 2016 17:41:17 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7759F205B4; Wed, 21 Sep 2016 20:41:16 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 21 Sep 2016 20:41:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=PS7ElPejRibDzAzcfQNVyOKuT2s=; b=cIszTH v7DSBS4hyGeS5zty/ijCrOfkSoeQ49R6vlMAZBx3s6anhUqNsqkMkMfOsKcbquzd K17cQ+0Rs5c6u3iisKXhEi04gACyTqsZ+qhbBJy9yVMtnx2sH/PLXbA9qSxPg8pI Fj5oFxysiz/KRCK+2E36HECXORMo7sTyKsO0M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=PS7ElPejRibDzAz cfQNVyOKuT2s=; b=oot2tw4HiY9GmFr2hod79hC7ZEVPnyaMXmPumjQztRniwnp DWrypdeL8JU5oXqUTZWwJ4ij3Mpo0edQ7OfxnhEzGX22DAvNCjO3Qshj/jEA/3w+ 0wU4MgTM/3FO5lvMghRQJjyA8kdPHFObpbG2fyU7BK5GwNkCxImdCMcbeqC4= X-Sasl-enc: +kEx+0Q6oWfsJlPFzoyi9Dk3WOtx9JlUOv4SXax4jW+j 1474504875 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.182]) by mail.messagingengine.com (Postfix) with ESMTPA id 5D45FF2985; Wed, 21 Sep 2016 20:41:15 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <730688AE-3DDE-4677-B4C9-A4173756175A@cooperw.in> Date: Wed, 21 Sep 2016 20:41:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46d6459124394dddbff5e9d7f48bf23b@HUB02.mailcluster.haw-hamburg.de> <71ec7240-8b2d-2f47-034e-f10faba8ea27@haw-hamburg.de> <06B65EC5-1582-4F4A-9325-47453B1ABF6C@cooperw.in> <730688AE-3DDE-4677-B4C9-A4173756175A@cooperw.in> To: Russ Housley X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Thomas C. Schmidt" , "draft-ietf-p2psip-share.all@ietf.org" , IETF SecDir Subject: Re: [secdir] Early SecDir Review of draft-ietf-p2psip-share-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 00:41:19 -0000 Hi Russ, Do you plan to respond to Thomas=92 question? If we don=92t hear back = from you by Sept 28, I=92ll ask him to go ahead with whichever solution = he thinks is best and we=92ll continue progressing the document. Thanks, Alissa > On Aug 31, 2016, at 9:53 AM, Alissa Cooper wrote: >=20 > Hi Russ, >=20 > Any update on this? >=20 > Thanks, > Alissa >=20 >> On Aug 24, 2016, at 10:03 AM, Alissa Cooper = wrote: >>=20 >> Russ, >>=20 >> Any thoughts on the question Thomas poses below? >>=20 >> Thanks, >> Alissa >>=20 >>> On Aug 15, 2016, at 3:20 PM, Thomas C. Schmidt = wrote: >>>=20 >>> Russ, >>>=20 >>> I'm only now coming back to this long delayed issue - sorry for = that. >>>=20 >>> Let me summarize the story about indexing (Section 3.1 in ShaRe): >>>=20 >>> 1. The application use case for shared resources is that of a small = group of peers sharing a data structure, which can be an array. Array = indexing according to Sec. 3.1 uses parts of the Node-ID (the 24 least = significant bits of a SHA-1 hash) to generate isolation among peers, and = at the same time generate an unambiguous, unique binding between a node = and the array elements it is allowed to write. >>>=20 >>> 2. The threat of collisions is that this binding becomes ambiguous = and - if not prevented - would cause an option for theft of = resource/service. There is no threat of privilege escalation, here, as = entries are signed. >>>=20 >>> 3. SHA-1 is collision-resistant and the probability of collisions is = expected to be low [1], but the output is not perfectly random. So I = agree that the ref to the RFC 3550 calculation is a bit too optimistic. = However, neither me nor a crypto colleague could find a rigorous = calculation of the SHA-1 collision probability ... >>>=20 >>> 4. The straight-forward counter measure against theft of resources = in the case of a collision is a refusal of overwriting by the storing = peer (see end of Section 6.1). This may exclude a node with colliding ID = bits from participation in sharing a resource. >>>=20 >>> Now I see two choices: >>>=20 >>> (1) We leave it that way, i.e., clarify the text in Section 3.1 and = point out that a node under collision could re-join the overlay with a = different node-ID. >>>=20 >>> (2) We could advise a procedure to generate non-colliding ID bits by = rehashing the node-ID. I.e., a node that experiences a collision could = rehash its ID to obtain new ID bits and the storing peer could validate = by also iterating the hashing. >>>=20 >>> (2) would complicate the whole process for considerably rare cases, = why I'm in favor of (1). >>>=20 >>> What would you suggest? >>>=20 >>> Thanks, >>> Thomas >>>=20 >>> [1] K. Chung, M. Mitzenmacher, and S. Vadhan: Why Simple Hash = Functions Work: Exploiting the Entropy in a Data Stream, Theory of = Computing , vol 9, pp. 897-945. >>>=20 >>>=20 >>>=20 >>> On 01.04.2016 01:21, Russ Housley wrote: >>>> I reviewed this document for the Security Directorate after a = request >>>> by the ART AD for an early review. >>>>=20 >>>> Version reviewed: draft-ietf-p2psip-share-08 >>>>=20 >>>>=20 >>>> Summary: Not Ready (from a Security Directorate perspective) >>>>=20 >>>>=20 >>>> Major Concerns: >>>>=20 >>>> In Section 3.1, there is an algorithm for assigning index values, = and >>>> the text says that the high-order 24 bits of the Node-ID serve as a >>>> pseudo-random identifier. Since these 24 bits are obtained from = the >>>> certificate that will be used to sign the stored data, the I think = that >>>> the same bits will be used over and over. If I got this correct, = then >>>> they are not pseudo-random. >>>>=20 >>>> In addition, Section 3.1 points to RFC 3550, Section 8.1 for a >>>> discussion of the probability of a collision. The consequences of = a >>>> collision seem to be different in the two documents. The = consequences >>>> of a collision in the index should be clearly described in this >>>> document. >>>>=20 >>>>=20 >>>> Minor Concerns: None >>>>=20 >>>>=20 >>>> Nits: >>>>=20 >>>> Please pick one spelling for Resource-IDs. (This is the spelling = used >>>> in RFC 6940.) However, this document sometimes uses "Resource Id". >>>>=20 >>>> Section 4.1 includes several examples for array indices. All of >>>> them are more than 32 bits: 0x123abc001, 0x123abc002, 0x123abc003, >>>> 0x123abc004, and 0x456def001. The most straightforward solution is >>>> to drop one of the zero digits. >>>>=20 >>>> To improve readability, I think the first sentence of Section 5.1 >>>> should read: "In certain use cases, such as conferencing, it is >>>> desirable..." >>>>=20 >>>> Section 5.1 says: >>>>=20 >>>> When defining the pattern, care must be taken to avoid conflicts >>>> arising from two user names of witch one is a substring of the = other. >>>>=20 >>>> I think this paragraph would be improved with an acceptable example = and >>>> a problematic example. >>>>=20 >>>> In Section 5.3: s/AOR/Address of Record (AOR)/ >>>>=20 >>>> In Section 6.2: s/This allows to invalidate entire subtrees/ >>>> /This allows the invalidation of entire subtrees/ >>>>=20 >>>> In Section 8, please provide a reference for RELOAD. >>>>=20 >>>=20 >>> --=20 >>>=20 >>> Prof. Dr. Thomas C. Schmidt >>> =B0 Hamburg University of Applied Sciences = Berliner Tor 7 =B0 >>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 >>> =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 >>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 >>=20 >=20 From nobody Wed Sep 21 17:42:56 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE27127077; Wed, 21 Sep 2016 17:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-gjhRegFneX; Wed, 21 Sep 2016 17:42:52 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 A0FDF12BC58; Wed, 21 Sep 2016 17:42:52 -0700 (PDT) X-AuditID: 12074424-263ff70000004d93-c6-57e3290a2e04 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id C4.6D.19859.A0923E75; Wed, 21 Sep 2016 20:42:50 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u8M0gnC5013651; Wed, 21 Sep 2016 20:42:50 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u8M0ghMg007884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Sep 2016 20:42:48 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8M0ggqe017791; Wed, 21 Sep 2016 20:42:42 -0400 (EDT) Date: Wed, 21 Sep 2016 20:42:42 -0400 (EDT) From: Benjamin Kaduk To: "Black, David" In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrMul+Tjc4PlsM4uPsxazWDxZ94PN YsaficwWHxY+ZHFg8Zg0cwazx5IlP5kCmKK4bFJSczLLUov07RK4Mo6deMdecE+q4uTRvcwN jK2iXYycHBICJhJ3r+5m62Lk4hASaGOSOHaymQnC2cgo0bV1BiuEc4hJYufEicwQTgOjxJGd bxhB+lkEtCUmXZ/IBmKzCahIzHyzEcjm4BAR0JR4ONcFpJ5ZYB2jROP/NWD1wgLOEhu3zGQC sTkF/CSeNh4D6+UVcJB4uOokC4gtJNDEKLF2OT+ILSqgI7F6/xQWiBpBiZMzn4DZzAJaEsun b2OZwCgwC0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbrmermZJXqpKaWbGEGByu6i soOxu8f7EKMAB6MSD29E96NwIdbEsuLK3EOMkhxMSqK83VuAQnxJ+SmVGYnFGfFFpTmpxYcY JTiYlUR4lZQfhwvxpiRWVqUW5cOkpDlYlMR5u2YcCBcSSE8sSc1OTS1ILYLJynBwKEnw1qgD NQoWpaanVqRl5pQgpJk4OEGG8wANXwlSw1tckJhbnJkOkT/FqCglzvtdDSghAJLIKM2D6wUn kt1Mqq8YxYFeEebtAWnnASYhuO5XQIOZgAZv+fkAZHBJIkJKqoFx+2F9a7nYbxempH+7vOgD n9rP6y8vH9yfUMlkdHa73B82pfS1LoqyDG7OcWo+p1t7heZP3PI78HVUmbN9leSiZVuf34y6 5FDjYKJ1bArLnWXnd155sFm1etZsT/W783RY5xQodc9a78rdobg7cn27lEp2ZOd2V6kfERN7 Slm6N/v9y+ie7W6mxFKckWioxVxUnAgAjzTPaf8CAAA= Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-tsvwg-diffserv-intercon@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-diffserv-intercon-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 00:42:55 -0000 Hi David, On Wed, 21 Sep 2016, Black, David wrote: > Hi Ben, > > Thanks for the review. > > > However, I do think it's worth giving a little bit of new thought to the > > potential privacy considerations -- a new way of marking traffic, in > > abstract, has the potential to leak classification information about the > > traffic in question (e.g., is this IP address doing telephony?). That > > said, the classification added by this document is something that could be > > done by any party with access to the raw network traffic, so I don't think > > there are actually any new considerations in play; it's just something to > > keep in mind. > > On balance, it seems like a good idea to add a sentence or two to point out > that additional traffic classification information is exposed at network > interconnections by comparison to DSCP remarking to zero - if that traffic > classification info is sensitive, remarking DSCPs to zero to hide the classification > is the countermeasure, at the cost of loss of QoS info and traffic handling > on the interconnect. Thanks. I think the document would be fine without such a sentence, but am happy to see one added. > Also, here are a few comments on your editorial suggestions: > > > Top of page 3, last sentence of first paragraph ("This draft assumes that > > latter approach by defining additional DSCPs that are known and expected > > at network interconnection interfaces.") -- I think maybe "subsumes" is a > > better verb than "assumes", as it is true that unknown/unexpected DSCPs > > are remarked to zero, but there is additional functionality in the > > known/expected DSCPs that are preserved. > > Well, "subsumes" isn't quite right either. Here's a longer rewrite that I hope > makes things clearer: > > OLD > This draft assumes that latter approach by defining additional DSCPs > that are known and expected at network interconnection interfaces. > NEW > This draft is based on the latter approach, and defines additional DSCPs > that are known and expected at network interconnection interfaces in > order to reduce the amount of traffic whose DSCPs are remarked to zero. The transition to "and defines additional" could probably be tweaked a bit more, but this is definitely an improvement -- thanks. > > Across the page 3/page 4 boundary, the part after the semicolon is a > > sentence fragment ... I can't even tell what it's trying to say. Maybe, > > "remarking to zero is performed in the absence of [...]" (but put a comma > > before "for"). > > Yes, it's a fragment - here's a suggested rewrite: > > OLD > remarking in the absence of > additional agreement(s) when the MPLS Short Pipe model is used for > reasons explained in this document. > NEW > use of the MPLS Short Pipe model favors remarking unexpected DSCPs > to zero in the absence of additional agreement(s), as explained further > in this document. Makes sense. > > Section 1.1, first paragraph, is this work really intended to *complement* > > RFC 5160? It seems to me that rather it is building upon 5160, or > > implementing its suggestions, or something like that. > > The activities are independent, so "complement" is a reasonable summary. I'll have to take your word for it, since my understanding seems to be incomplete. Sorry for the noise, then. -Ben From nobody Wed Sep 21 17:57:26 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1694412BEEE for ; Wed, 21 Sep 2016 17:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuA2TYCotoWI for ; Wed, 21 Sep 2016 17:57:23 -0700 (PDT) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (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 C70FD12BEE7 for ; Wed, 21 Sep 2016 17:57:23 -0700 (PDT) Received: from smtp25.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 19E1520499; Wed, 21 Sep 2016 20:57:21 -0400 (EDT) Received: from app6.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0F8BE2045D; Wed, 21 Sep 2016 20:57:21 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app6.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.7); Wed, 21 Sep 2016 20:57:21 -0400 Received: from hyperthought.com (localhost [127.0.0.1]) by app6.wa-webapps.iad3a (Postfix) with ESMTP id F125BA0069; Wed, 21 Sep 2016 20:57:20 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Wed, 21 Sep 2016 17:57:20 -0700 (PDT) Date: Wed, 21 Sep 2016 17:57:20 -0700 (PDT) From: "Scott G. Kelly" To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-avtcore-5761-update.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain X-Auth-ID: scott@hyperthought.com Message-ID: <1474505840.985821095@apps.rackspace.com> X-Mailer: webmail/12.5.3-RC Archived-At: Subject: [secdir] secdir review of draft-ietf-avtcore-5761-update-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 00:57:25 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments.=0A=0AFrom the abstract:=0A=0A This document u= pdates RFC 5761 by clarifying the SDP offer/answer=0A negotiation of RTP = and RTCP multiplexing. It makes it clear that an=0A answerer can only in= clude an "a=3Drtcp-mux" attribute in an SDP answer=0A if the associated S= DP offer contained the attribute.=0A=0AThe security considerations section = says=0A=0A The security considerations for RTP and RTCP multiplexing are= =0A described in RFC 5761. This specification does not impact those=0A = security considerations.=0A=0AI agree, I see no new security issues with t= his draft. From nobody Wed Sep 21 18:57:24 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB14312C0C3 for ; Wed, 21 Sep 2016 18:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r-J0gEbe-TX for ; Wed, 21 Sep 2016 18:57:20 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B70212BC7B for ; Wed, 21 Sep 2016 18:57:20 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Sep 2016 19:10:35 -0700 From: Jim Schaad To: 'Stephen Kent' , 'secdir' , 'Justin Richer' , 'Kepeng Li' , 'Kathleen Moriarty' References: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> In-Reply-To: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> Date: Wed, 21 Sep 2016 18:57:10 -0700 Message-ID: <081e01d21474$a3db8440$eb928cc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLn+ErX890UkhHKZArMVoO8r82N055Y1HMw Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: Re: [secdir] secdir review of cose-msg-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 01:57:23 -0000 Changes marked 'done' have been integrated on github. Jim From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Wednesday, September 21, 2016 7:27 AM To: secdir ; Jim Schaad ; = Justin Richer ; Kepeng Li ; = Kathleen Moriarty Subject: secdir review of cose-msg-18 SECDIR review of draft-ietf-cose-msg-18 =20 Typos and suggested rewording. =20 Section 2:=20 =20 The COSE object structure is designed so that there can be a large = amount of common code when parsing and processing the different security messages. -> The COSE object structure is designed so that there can be a large = amount of common code when parsing and processing the different types of = security messages. done =20 COSE messages are also built using the concept of using layers to = =E2=80=A6=20 -> COSE messages are built using the concept of layers to =E2=80=A6 done =20 Section 3: =20 The integer and string values for labels has been divided =E2=80=A6 -> The integer and string values for labels have been divided =E2=80=A6 done =20 Applications SHOULD perform the same checks that the same label = =E2=80=A6 -> Applications SHOULD verify that the same label =E2=80=A6 done =20 Applications should have a statement if the label can be omitted. -> Applications SHOULD (?) have a statement if the label can be omitted. [JLS] I believe that lower case is correct here. This would not be a = requirement on the COSE protocol, but on the application that is using = COSE. It does not make sense to me to have 2119 language for this type = of statement. (Partly from an initial brow beating from Russ.) =20 Integers are from the "CoAP Content-Formats" IANA registry table. (no = reference) [JLS] What do you think should be referenced here? Are you looking for = a URL to iana.org? Not sure that this makes sense. =20 As the IV is authenticated by the encryption process, it can be placed = in the unprotected header bucket. (in general, an encryption process = will not =E2=80=9Cauthenticate=E2=80=9D an IV, but use of a modified IV = will yield mangled plaintext, which can be detected by an integrity = check or a signature. the same comment applies to the similar statement = in the =E2=80=9Cpartial IV=E2=80=9D description.) =20 [JLS] Does this work? The IV can be placed in the unprotected header as modifying the IV will = cause the decryption of the plaintext to fail. =20 Section 4: =20 Edwards Digital Signature Algorithm (EdDSA) signature algorithm and with = the Elliptic Curve Digital Signature Algorithm (ECDSA) signature = algorithm. -> Edwards Digital Signature Algorithm (EdDSA) (cite) and with the = Elliptic Curve Digital Signature Algorithm (ECDSA) (cite). [JLS] I think it is excessive, but done. =20 One of the features supplied in the COSE document is the = ability=E2=80=A6 -> One of the features offered by the COSE format is the ability = =E2=80=A6 done =20 This algorithm takes in the body information =E2=80=A6 -> The signing and verification processes take in the body information = =E2=80=A6 done =20 Counter signatures provide a method of having a different signature = occur on some piece of content. -> Counter signatures provide a method of associating different = signatures generated by different signers with some piece of content. done =20 =20 Section 5 =20 Other: The key is randomly generated. -> Other: The key is randomly or pseudo-randomly generated. =20 done =20 Section 6 =20 (This knowledge of sender assumes that there are only two parties = involved and you did not send the message yourself.) -> (This knowledge of sender assumes that there are only two parties = involved and you did not send the message to yourself.) =20 done =20 Section 15: =20 It is intended that a profile of this document be created that defines the interopability -> It is intended that a profile of this document be created that defines the interoperability done From nobody Thu Sep 22 00:31:40 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E8612D903; Thu, 22 Sep 2016 00:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTc-2VmR5ege; Thu, 22 Sep 2016 00:31:33 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 970D912D8FE; Thu, 22 Sep 2016 00:31:32 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u8M7VSGk002527 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 22 Sep 2016 09:31:29 +0200 X-Hashcash: 1:22:160922:iesg@ietf.org::8gsWeRiWxqRk2Bv8:hfx X-Hashcash: 1:22:160922:secdir@ietf.org::J/JP5R1z7GCPsBG/:qlj6 X-Hashcash: 1:22:160922:draft-harkins-salted-eap-pwd.all@ietf.org::N9IQRO2+FCut9MDI:861A From: Simon Josefsson To: iesg@ietf.org, secdir@ietf.org, draft-harkins-salted-eap-pwd.all@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Thu, 22 Sep 2016 09:31:26 +0200 Message-ID: <87fuosqtkh.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.99.2 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [secdir] secdir review of draft-harkins-salted-eap-pwd-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 07:31:35 -0000 --=-=-= Content-Type: text/plain Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document adds support for salted password databases to EAP-pwd (RFC5931). I believe the document is Not Ready for the following reasons: 1) The introduction and security considerations fails to acknowledge that password salting is not sufficient to protect against real-world password recovery attacks. Iterative constructs are needed. This knowledge is old, PBKDF2/RFC2898 (which is one standard technique to address the problem) was published in 2000 and has been widely deployed since then. The document should mention this aspect. There have been many successful attacks against pure-salted password databases in the real world, for example: https://en.wikipedia.org/wiki/2012_LinkedIn_hack 2) Code points for the pre-processing techniques PBKDF2 (RFC 2898) and scrypt (RFC 7914) should be added, to support use of best security practices. 3) There are interop concerns with crypt() when discussion about which crypt algorithms (DES, MD5, etc) are to be used is lacking. The page mentions a couple of algorithms, but several others exist out there. Consider if the server tells the client to use an exotic crypt() schema like BSDi or NTHASH, and the client does not support this algorithm. The document should discuss the sub-negotiation problem. The document should mention what happens when the server choses an algorithm the client doesn't support. The document should recommend that servers use widely-implemented schemas, like DES, md5, or sha256. 4) Introducing a new pre-processing technique like OpaqueString+SHA1 or OpaqueString+crypt() add complexity. As far as I understand, there are no password databases with OpaqueString-processed passwords which are hashed with SHA-1 or crypt out there today. Thus there is no interop argument for introducing the methods. Please confirm that the intention is to introduce these methods as new ideas. Then let me suggest that you only describe OpaqueString+SHA256 and skip OpaqueString+SHA1, OpaqueString+SHA512, OpaqueString+crypt. This reduces complexity and does not cause a reduction of security. Further, password databases with HTTP Digest MD5 passwords are widely used. For added legacy compatibility, consider support it too. This is not a show stopper, but failure to mentioning it in the context of deployed password databases appears to me like an elephant in the room. Where there conscious reasons for not including it? It may be worth stating those reasons in the document, if that is the case. Cheers, /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJX44jOAAoJEIYLf7sy+BGdjU0IAImC7C229Tea+5xE2aBFvfoL KSROVSruitP3lRhDkaxp58GJ6ajLFwk+keI7fCVS9atagh/LXK9UQbHC9pnQbRtE m4HUhL5jHDhNFn0zDNrLpkbOXsiPIvWdPMo4PK1kAZuB8Nf2DDec7LwFk1uGkAZQ BfhStzYySrxJc/mXDYWEyj7rxyFXvumWYOB1HcwkRFUdCLtdkorpem6BConHxzDI OmHH/2+EV4OQyrO3Cq97x6fYwhxHbUwH7RqmneEgxj95w0FRFQyNr1wF/nSZUemi nvu+3f1PgEqYAe6h9HTJ1lFazghcUEF6GYrke+En8Gq3HQtgjFbZ7KrjCvhP0KY= =gsD/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 22 01:35:50 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D6912B0DC; Thu, 22 Sep 2016 01:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id padbHK4EYd2B; Thu, 22 Sep 2016 01:35:40 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 7FD3012B4C3; Thu, 22 Sep 2016 01:35:39 -0700 (PDT) X-AuditID: c1b4fb3a-ab7ff7000000099a-ff-57e397d8dc71 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 43.31.02458.8D793E75; Thu, 22 Sep 2016 10:35:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0301.000; Thu, 22 Sep 2016 10:35:35 +0200 From: Christer Holmberg To: "Scott G. Kelly" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-avtcore-5761-update.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-avtcore-5761-update-01 Thread-Index: AQHSFHG01HDNcf5b90qz3MBjkMOv3aCFQgkA Date: Thu, 22 Sep 2016 08:35:35 +0000 Message-ID: References: <1474505840.985821095@apps.rackspace.com> In-Reply-To: <1474505840.985821095@apps.rackspace.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-ID: <4DCDF196CEFA134C95E24B9B13519622@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2J7oO7N6Y/DDe69MLP48WADm8WMPxOZ Lb5umcBo8WHhQxYHFo8dO06xeCxZ8pPJ48vlz2wBzFFcNimpOZllqUX6dglcGefudrMUdHJU TLl7n62BcTtbFyMnh4SAicSK6+9Zuhi5OIQE1jNKLHj1iQnCWcwocebGGuYuRg4ONgELie5/ 2iBxEYFHjBJX5z5lBukWFrCX+P/6HZgtIuAg0TV/HZRtJNH1/xaYzSKgKtHSsJkFxOYVsJJ4 fPAQ2GYhAVOJ9cta2EDmcwqYSfS2RoCEGQXEJL6fWsMEYjMLiEvcejKfCeJQAYkle84zQ9ii Ei8f/2MFsUUF9CS+f50NFVeU2Hm2nRmiV0diwe5PbBC2tcTex3vZIWxtiWULXzNDnCMocXLm E5YJjGKzkKybhaR9FpL2WUjaZyFpX8DIuopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMOoO bvlttYPx4HPHQ4wCHIxKPLwJkx6FC7EmlhVX5h5ilOBgVhLh3T/pcbgQb0piZVVqUX58UWlO avEhRmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwcnFINjLEHdFMruuMeSlhIz+lJv9j/xeio bXdAJNeLRVIMMiHfNacc9exJk97Rrzoh4U2Zxeun6g5H5nfN5Nq6RPpJ7Mo8V1bpnbl9YVKs Z294+5Zfm3DgHtMH658LEmWCpvbIpmwMUnZgFjLb66S55QpLT+xbBqkgF9HVXyM2r9gbqTuL 3zbdhy1biaU4I9FQi7moOBEAlNaxI7YCAAA= Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-avtcore-5761-update-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 08:35:41 -0000 Thanks! :) Regards, Christer On 22/09/16 03:57, "Scott G. Kelly" 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. > >From the abstract: > > This document updates RFC 5761 by clarifying the SDP offer/answer > negotiation of RTP and RTCP multiplexing. It makes it clear that an > answerer can only include an "a=3Drtcp-mux" attribute in an SDP answer > if the associated SDP offer contained the attribute. > >The security considerations section says > > The security considerations for RTP and RTCP multiplexing are > described in RFC 5761. This specification does not impact those > security considerations. > >I agree, I see no new security issues with this draft. > From nobody Thu Sep 22 08:58:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADB612B810 for ; Thu, 22 Sep 2016 08:58:05 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJQ-cvlXyEtS for ; Thu, 22 Sep 2016 08:58:03 -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 F25F712B886 for ; Thu, 22 Sep 2016 08:57:59 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8MFvuZf009746 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 22 Sep 2016 18:57:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8MFvthT003959; Thu, 22 Sep 2016 18:57:55 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22499.65411.689224.615637@fireball.acr.fi> Date: Thu, 22 Sep 2016 18:57:55 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 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, 22 Sep 2016 15:58:05 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sandy Murphy is next in the rotation. For telechat 2016-09-29 Reviewer LC end Draft Dan Harkins T 2016-09-21 draft-ietf-pals-rfc4447bis-05 Charlie Kaufman T 2016-09-29 draft-ietf-6lo-paging-dispatch-04 Warren Kumari T 2016-09-28 draft-ietf-ipsecme-ddos-protection-09 Sandy Murphy T 2016-08-12 draft-ietf-tsvwg-gre-in-udp-encap-18 Radia Perlman TR2016-08-15 draft-ietf-i2rs-protocol-security-requirements-11 Carl Wallace TR2016-08-11 draft-ietf-radext-ip-port-radius-ext-11 Dacheng Zhang T 2016-08-22 draft-ietf-core-http-mapping-14 For telechat 2016-10-13 Matt Lepinski T 2016-09-29 draft-ietf-ipsecme-safecurves-04 Chris Lonvick T 2016-10-04 draft-ietf-lisp-crypto-07 David Mandelberg T 2016-10-04 draft-ietf-lisp-lcaf-15 Takeshi Takahashi TR2016-05-31 draft-ietf-tsvwg-rfc5405bis-17 Tina TSOU T 2016-08-15 draft-ietf-ospf-two-part-metric-09 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-11 Catherine Meadows 2016-09-30 draft-ietf-opsawg-capwap-alt-tunnel-08 Matthew Miller 2016-10-06 draft-ietf-stox-7248bis-12 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-14 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-05 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-09 -- kivinen@iki.fi From nobody Thu Sep 22 13:59:59 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358BC12B65C for ; Thu, 22 Sep 2016 13:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8PVOp4Jy2D7 for ; Thu, 22 Sep 2016 13:59:53 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) by ietfa.amsl.com (Postfix) with ESMTP id B2CEE12B5B5 for ; Thu, 22 Sep 2016 13:59:52 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d44 with ME id mksL1t00517Lgi403ksLLe; Thu, 22 Sep 2016 22:52:22 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Thu, 22 Sep 2016 22:52:22 +0200 X-ME-IP: 92.170.5.52 To: Barry Leiba References: <20981db3190142193043f1445abadaa3@trigofacile.com> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: Date: Thu, 22 Sep 2016 22:52:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-murchison-nntp-compress.all@ietf.org, IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-murchison-nntp-compress-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 20:59:57 -0000 Hi Barry, Thanks for your answer. I'll have a deeper look at it soon. As for the remaining "small points" of rewording (SHOULD, MUST, etc.), I'll calmly see them when updating the draft after Last Call. In case I have a doubt for the best wording, I'll ask Ken (co-author) and Michael (write-up shepherd) their preference. We'll obviously manage to come up with the "final" rewording as we'll have 3 votes for 2 choices. Now that I think about it, wouldn't it be worth adding something about possible "out of memory" attacks in the Security Considerations Section? According to , "a 50MB file filled with zeros [...] a version of run-length encoding optimized for this sort of unusual data file [...] could encode the test file in five bytes. That would be a compression factor of 10,000,000:1". So sending just 5 bytes may require an expansion to 50MB. Implementations therefore really need to check that the uncompressed data does not exceed an upper bound limit. RFC 1951 (DEFLATE) does not mention it in its Security Considerations, and I don't remember having seen that in other RFCs too. Maybe we should say a word for it in the NNTP COMPRESS extension. -- Julien ÉLIE « Un voyage de mille lieues commence toujours par un premier pas. » (Lao Zi) From nobody Fri Sep 23 08:24:33 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001C712B368 for ; Fri, 23 Sep 2016 08:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGwXtXGYeBx0 for ; Fri, 23 Sep 2016 08:24:30 -0700 (PDT) Received: from nm12-vm6.bullet.mail.ne1.yahoo.com (nm12-vm6.bullet.mail.ne1.yahoo.com [98.138.91.105]) (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 19A8112B31C for ; Fri, 23 Sep 2016 08:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1474644269; bh=lRUbiFWmdpFXuFcMraCpOI2uVJZ3RvucyEx4+lQOex8=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=mGGYq+JF9LM9VXMnY8oinjlU6U3IUeB9DvPqjqMLm6s1HMzuXqzqOKWdZbtRDqa84/lfsOpU3gK34TWIywzlA0HtRWYOez98gsV70rL1eA14JLQaBzmQr7ZZKdTDy8l3bkmBbjz5vqd8sZm/DADygMaBiTlxaserKBUp8Zerb4A+sqJDmrI8y86BUbu9Wuta0SNcNbJQy/fllKg5Q6XBRo2/ixUv/M7t27DpjMLJ38z8z0XGv8A+8RnUZusxbi9fYIO1eV9M+e2XfATC3rufC3N+A6H3SvzjhS1ZxeZ0+NgfSPXglnkupwarNfqH0dgfVxwdzLcp25875OQ2lFJJ4Q== Received: from [98.138.100.111] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 23 Sep 2016 15:24:29 -0000 Received: from [98.138.226.161] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 23 Sep 2016 15:24:29 -0000 Received: from [127.0.0.1] by omp1062.mail.ne1.yahoo.com with NNFMP; 23 Sep 2016 15:24:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 180228.27091.bm@omp1062.mail.ne1.yahoo.com X-YMail-OSG: lsCbeegVM1neEpvQa8QTPQQBxTTdcwabTzzY88qxMSdgKhkVNOlQQ5czliU_.v0 5OOdnwcVpmYz2DnbqhGxTZFjiG9gmJm_vpNM3NC9L.3QrZslHOzYa9jSqYoGV4LJkVs7CAtOKfv6 ydXm4oWfktFeKd6ThMag6ZSYZhhLB1R9sTRSN_L3WExzMQZ6wPb.xQYinxTiVSGPlkKfLgkRUE7G vSHLVwvMwLBYpjBqxQ_P94fX0xhUqFRhEQflxhk3sE5BFpZF2ypQcMQup.IGjaYFDOSSkMJ_qDSf MxUDTv3_IwardSCje2bM2dAwanWJxEsnUfMON6KavB_w7iT74h__2zlgLWPLBZq7bHTGWGSU12PP Ztmv5znxAl.zzVvjwEQ0.VbDYp9cP8yrllymIsUTG.MoeIq_BonjTkEEtke_2MizAeP6Z8MwGa1n uPNPrCn0vWBZn_cyOM_Q_I20.symae7dymUbCs9uxp2XXnCXI6T_nzT_X_Py7JKiDWT6nDs_Fqsd 5LXnNp44SXnyR.ZZ.3zZfdZ4Kv1vi1v560qUUV1UxrVyn4tdUiMtnQuthoqFTsb9bs4IXtXBq Received: from jws10035.mail.ne1.yahoo.com by sendmailws103.mail.ne1.yahoo.com; Fri, 23 Sep 2016 15:24:28 +0000; 1474644268.780 Date: Fri, 23 Sep 2016 15:24:28 +0000 (UTC) From: To: Tero Kivinen , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" Message-ID: <1264225155.363685.1474644268281@mail.yahoo.com> In-Reply-To: <22495.62038.771947.984586@fireball.acr.fi> References: <22495.62038.771947.984586@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 15:24:32 -0000 Tero, Thanks for your comments. We have posted a new draft with corrections at: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-06 Our responses inline. Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Tero Kivinen To: iesg@ietf.org; secdir@ietf.org; draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org Sent: Monday, September 19, 2016 7:12 AM Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-05 >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 document describes adding new IPv6 destination option header to >allow performance metrics calculations. >I think this document has serious issues. >It proposes that the new Destination option MUST be put before the ESP >so it is sent in clear. This will leak out the traffic information >from the ESP, allowing easy traffic analysis of encrypted packets, as >passive attacker can see which encrypted ESP packets belong to which >5-tuple flow. The PDM option header includes the incrementing sequence >numbers, so checking those will allow see which packet belongs to >which flow. It is not clear to me how knowing which ESP packets belong to which traffic flow helps a passive attacker. The attacker still does not know what is in the packet - the contents of the payload. Indeed, ESP would normally mask TCP or UDP ports. With PDM you can tell that there ARE multiple flows but you don't know if they are TCP, UDP, ICMP or anything else. Most importantly, you don't know what is in the payload. If one follows the thinking of your objection, isn't any encrypted flow over TCP or UDP a problem since a passive attacker knows the 5-tuple for such flows? For example, all TLS flows can be analyzed for traffic in your sense. So, a flow over TLS (without PDM) actually leaks more information than an ESP flow WITH PDM. Because with TLS, we even know that the flow is TCP and the port number. Neither of which you know with PDM with ESP. >It claims that PDM MUST be placed before the ESP header in order to >work, which is untrue. This is destination option, thus it is meant to >be checked on the destination host, i.e., the packet capture after the >ESP decryption will allow seeing the PDM header values without issues. -- >Also the Time Base definations seem to be inconsistent. The section >3.2 says: > That is, for a value of 00 in the Time Base field, a value of 1 in > the DELTA fields indicates 1 microsecond. > Section 4.4 on other hand claims: > That is, for a value of 00 in the Time Base field, a value of 1 in > the DELTA fields indicates 1 picosecond. >On the other hand looking at the table in both 3.2 and 4.4 it seems >that time base value field value of 00 means milliseconds, not >microseconds or picoseconds. >Again section 4.5 says that "TimeBase of picosecond (or 00)", and >again I think picoseconds was supposed to be Time Base of 11... Thanks for catching those. Should now be fixed. >The whole section 4 seems to be wierd. It is talking about different >encodings, and time units on different systems, and it also talks >about the limitations on TCP Timestamp Option, but this option uses >different encoding so I have no idea why this text is here. It would >be more useful to count what are the limits on the encoding method >used here (16 bit value, 7 bit signed scaling value), instead of what >some other option use. Thanks. Should now be fixed. >In section 5.3 in the example it converts 4 seconds to hex value of >3A35 and scale of 25. On the other hand it is using milliseconds as >Time Base, so I think those values are wrong, i.e. 4 seconds in >milliseconds is 4000 milliseconds, thus FA0 with scale of 0 would be >correct represetnation. Same mistake in 5.4. Thanks. Should now be fixed. -- I skipped most of the section 6 and 7, so cannot say if similar mistakes are in those sections. -- >The section 8 is wrong as it claims > "PDM does not introduce any new security weakness." >while this will leak lots of information about the traffic flows >inside the encrypted transport mode ESP packets. Please see above. >Also another thing the PDM leaks is exact host timings, i.e., it can>be used to launch timing attacks against crypto protocols. In general >those are hard as it is very hard to know how much of n ms rtt is >network delay and how much was the actual host processing the packet. >Now if we can see that that host used 123 nanoseconds to process the >signature verification packet, and next time it uses 1755 nanoseconds, >this might allow attacker to get information out from the key. The >actual round trip times might have been 123 ms in both cases, and the >1 microsecond difference in the processing time would have been lost >by the network latencies. 1. The intent of PDM is as a diagnostic feature. PDM is OFF initially at the end hosts (client and server). It is turned ON for diagnostics and then turned OFF afterwards. If someone chooses to leave PDM ON always, then that is explicitly chosen. Also, PDM is an OPTIONAL feature. Either client or server operating system may choose not to implement it or use it. 2. In your example above, it assumes that the signature verification packet (please let me know which exact packet and protocol you are referring to) is passing in the clear so that the attacker knows that it is the signature verification packet. Possibly this is also a problem. 3. Protocols often use blinding techniques to remove correlations between key and encryption time. Other cryptographic algorithms can be implemented (or masked by a proxy) in a way that reduces or eliminates data dependent timing information. So if timing information is being leaked, this is a flaw in the algorithm or the protocol. In this case, we may be "blaming the messenger". PDM is only reporting what is done. The algorithm or protocol is the problem. >In addition to that the abstract is not very clear, it does not do >very good job of telling that this draft tries to do, and having the >Background section to duplicate most of that text does not still what >this document really tries to do. If you can give me a hint as to what is not clear or what you think this draft DOES propose, then we will be happy to rewrite the abstract / background section. -- kivinen@iki.fi From nobody Fri Sep 23 10:37:37 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D16112BD1E; Fri, 23 Sep 2016 10:37:30 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXgIQNSh_mIe; Fri, 23 Sep 2016 10:37:27 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A530212BCF5; Fri, 23 Sep 2016 10:37:27 -0700 (PDT) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 0A0D31FE01F0; Fri, 23 Sep 2016 10:37:26 -0700 (PDT) To: Simon Josefsson , iesg@ietf.org, secdir@ietf.org, draft-harkins-salted-eap-pwd.all@ietf.org References: <87fuosqtkh.fsf@latte.josefsson.org> From: Dan Harkins Message-ID: <66a779c8-d87b-7c70-c7cf-7eabc48f9880@lounge.org> Date: Fri, 23 Sep 2016 10:37:25 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <87fuosqtkh.fsf@latte.josefsson.org> Content-Type: multipart/alternative; boundary="------------8DC7B18469FB0F134BA64983" Archived-At: Subject: Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 17:37:30 -0000 This is a multi-part message in MIME format. --------------8DC7B18469FB0F134BA64983 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Simon, On 9/22/16 12:31 AM, Simon Josefsson wrote: > Hello, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. Thank you for your review and comments. > > This document adds support for salted password databases to EAP-pwd > (RFC5931). I believe the document is Not Ready for the following > reasons: > > 1) The introduction and security considerations fails to acknowledge > that password salting is not sufficient to protect against real-world > password recovery attacks. Iterative constructs are needed. This > knowledge is old, PBKDF2/RFC2898 (which is one standard technique to > address the problem) was published in 2000 and has been widely > deployed since then. The document should mention this aspect. There > have been many successful attacks against pure-salted password > databases in the real world, for example: > https://en.wikipedia.org/wiki/2012_LinkedIn_hack The intent is to support existing databases that RFC 5931 could not. I guess it deserves to be mentioned in case someone wants to create a new salted password database. I will add something regarding real-world attacks to recover passwords given a salted/encrypted database. > > 2) Code points for the pre-processing techniques PBKDF2 (RFC 2898) and > scrypt (RFC 7914) should be added, to support use of best security > practices. Great suggestion, I will add these. > > 3) There are interop concerns with crypt() when discussion about which > crypt algorithms (DES, MD5, etc) are to be used is lacking. The page > mentions a couple of > algorithms, but several others exist out there. Consider if the > server tells the client to use an exotic crypt() schema like BSDi or > NTHASH, and the client does not support this algorithm. The document > should discuss the sub-negotiation problem. The document should > mention what happens when the server choses an algorithm the client > doesn't support. The document should recommend that servers use > widely-implemented schemas, like DES, md5, or sha256. Yes, there needs to be something to deal with failure of a client to support a server's crypt algorithm. Since this is not a dynamic sort of thing-- oh, you don't like BSDi, how about sha256?-- so I think the only option is failure, but it should be mentioned. > > 4) Introducing a new pre-processing technique like OpaqueString+SHA1 > or OpaqueString+crypt() add complexity. As far as I understand, there > are no password databases with OpaqueString-processed passwords which > are hashed with SHA-1 or crypt out there today. Thus there is no > interop argument for introducing the methods. Please confirm that the > intention is to introduce these methods as new ideas. Then let me > suggest that you only describe OpaqueString+SHA256 and skip > OpaqueString+SHA1, OpaqueString+SHA512, OpaqueString+crypt. This > reduces complexity and does not cause a reduction of security. Actually no, these aren't for new databases. There has to be some canonical way to deal with "international" character sets. RFC 5931 used to refer to SASLprep but that's been obsoleted. So I MUST now refer to OpaqueString. I went to the OpaqueString tutorial a couple of IETFs ago and asked whether passwords treated with SASLprep would map 1:1 to passwords treated with OpaqueString and the answer I got was something like, "uhm, well, I'm not sure. I think so." So the expectation is that a passphrase of "Eu amo São Paulo" (with the problematic diacritical) in an existing database created by SASLprep could be used with salted EAP-pwd and the corresponding OpaqueString pre-processing technique. And that means that every non-internationalized salting technique needs an OpaqueString version, including SHA1 and crypt. > Further, password databases with HTTP Digest MD5 passwords are widely > used. For added legacy compatibility, consider support it too. This is > not a show stopper, but failure to mentioning it in the context of > deployed password databases appears to me like an elephant in the room. > Where there conscious reasons for not including it? It may be worth > stating those reasons in the document, if that is the case. Good suggestion. I'll add MD5 too. regards, Dan. > > Cheers, > /Simon > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --------------8DC7B18469FB0F134BA64983 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
  Hi Simon,

On 9/22/16 12:31 AM, Simon Josefsson wrote:
Hello,

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

  Thank you for your review and comments.

 

This document adds support for salted password databases to EAP-pwd
(RFC5931).  I believe the document is Not Ready for the following
reasons:

  1) The introduction and security considerations fails to acknowledge
  that password salting is not sufficient to protect against real-world
  password recovery attacks.  Iterative constructs are needed.  This
  knowledge is old, PBKDF2/RFC2898 (which is one standard technique to
  address the problem) was published in 2000 and has been widely
  deployed since then.  The document should mention this aspect.  There
  have been many successful attacks against pure-salted password
  databases in the real world, for example:
  https://en.wikipedia.org/wiki/2012_LinkedIn_hack

  The intent is to support existing databases that RFC 5931 could not.
I guess it deserves to be mentioned in case someone wants to create a
new salted password database. I will add something regarding real-world
attacks to recover passwords given a salted/encrypted database.

 

  2) Code points for the pre-processing techniques PBKDF2 (RFC 2898) and
  scrypt (RFC 7914) should be added, to support use of best security
  practices.

  Great suggestion, I will add these.

  3) There are interop concerns with crypt() when discussion about which
  crypt algorithms (DES, MD5, etc) are to be used is lacking.  The page
  <https://en.wikipedia.org/wiki/Crypt_%28C%29> mentions a couple of
  algorithms, but several others exist out there.  Consider if the
  server tells the client to use an exotic crypt() schema like BSDi or
  NTHASH, and the client does not support this algorithm.  The document
  should discuss the sub-negotiation problem.  The document should
  mention what happens when the server choses an algorithm the client
  doesn't support.  The document should recommend that servers use
  widely-implemented schemas, like DES, md5, or sha256.

  Yes, there needs to be something to deal with failure of a client
to support a server's crypt algorithm. Since this is not a dynamic sort
of thing-- oh, you don't like BSDi, how about sha256?-- so I think the
only option is failure, but it should be mentioned.

 

  4) Introducing a new pre-processing technique like OpaqueString+SHA1
  or OpaqueString+crypt() add complexity.  As far as I understand, there
  are no password databases with OpaqueString-processed passwords which
  are hashed with SHA-1 or crypt out there today.  Thus there is no
  interop argument for introducing the methods.  Please confirm that the
  intention is to introduce these methods as new ideas.  Then let me
  suggest that you only describe OpaqueString+SHA256 and skip
  OpaqueString+SHA1, OpaqueString+SHA512, OpaqueString+crypt.  This
  reduces complexity and does not cause a reduction of security.

  Actually no, these aren't for new databases. There has to be some
canonical way to deal with "international" character sets. RFC 5931
used to refer to SASLprep but that's been obsoleted. So I MUST now
refer to OpaqueString.

  I went to the OpaqueString tutorial a couple of IETFs ago and asked
whether passwords treated with SASLprep would map 1:1 to passwords
treated with OpaqueString and the answer I got was something like, "uhm,
well, I'm not sure. I think so." So the expectation is that a passphrase
of "Eu amo São Paulo" (with the problematic diacritical) in an existing
database created by SASLprep could be used with salted EAP-pwd and the
corresponding OpaqueString pre-processing technique. And that means that
every non-internationalized salting technique needs an OpaqueString
version, including SHA1 and crypt.

 
Further, password databases with HTTP Digest MD5 passwords are widely
used.  For added legacy compatibility, consider support it too.  This is
not a show stopper, but failure to mentioning it in the context of
deployed password databases appears to me like an elephant in the room.
Where there conscious reasons for not including it?  It may be worth
stating those reasons in the document, if that is the case.

  Good suggestion. I'll add MD5 too.

  regards,

  Dan.

 

Cheers,
/Simon



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

--------------8DC7B18469FB0F134BA64983-- From nobody Fri Sep 23 10:54:55 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA7912B747 for ; Fri, 23 Sep 2016 10:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4kQpNPBJDNg for ; Fri, 23 Sep 2016 10:54:51 -0700 (PDT) Received: from bos-mailout2.raytheon.com (bos-mailout2.raytheon.com [199.46.198.208]) (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 C402E12B883 for ; Fri, 23 Sep 2016 10:54:50 -0700 (PDT) Received: from ma-mailout10.rtnmail.ray.com (ma-mailout10.rtnmail.ray.com [147.25.130.27]) by bos-mailout2.raytheon.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u8NHsSnV002843 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Sep 2016 17:54:28 GMT Received: from smtp.bbn.com ([128.33.1.81]) by ma-mailout10.rtnmail.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id u8NHsQQa030868 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Fri, 23 Sep 2016 17:54:27 GMT Received: from ssh.bbn.com ([192.1.122.15]:50999 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bnUg6-0009f5-6i; Fri, 23 Sep 2016 13:54:26 -0400 From: Stephen Kent To: Jim Schaad , "'secdir'" , "'Justin Richer'" , "'Kepeng Li'" , "'Kathleen Moriarty'" References: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> <081e01d21474$a3db8440$eb928cc0$@augustcellars.com> Message-ID: Date: Fri, 23 Sep 2016 13:54:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <081e01d21474$a3db8440$eb928cc0$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-23_07:, , signatures=0 Archived-At: Subject: Re: [secdir] secdir review of cose-msg-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 17:54:53 -0000 Jim, Thanks for making the changes you describe as done. Comments below on the few remaining items. > Applications should have a statement if the label can be omitted. > -> Applications SHOULD (?) have a statement if the label can be omitted. > > [JLS] I believe that lower case is correct here. This would not be a requirement on the COSE protocol, but on the application that is using COSE. It does not make sense to me to have 2119 language for this type of statement. (Partly from an initial brow beating from Russ.) OK. > Integers are from the "CoAP Content-Formats" IANA registry table. (no reference) > > [JLS] What do you think should be referenced here? Are you looking for a URL to iana.org? Not sure that this makes sense. When you refer to IANA registries defined in the doc you cite the relevant section of the doc. Since this registry already exists I think it would be appropriate to include a pointer to it: http://www.iana.org/assignments/core-parameters/core-parameters.xhtml > As the IV is authenticated by the encryption process, it can be placed in the unprotected header bucket. (in general, an encryption process will not “authenticate†an IV, but use of a modified IV will yield mangled plaintext, which can be detected by an integrity check or a signature. the same comment applies to the similar statement in the “partial IV†description.) > > [JLS] Does this work? > > The IV can be placed in the unprotected header as modifying the IV will cause the decryption of the plaintext to fail. How about: The IV can be placed in the unprotected header as modifying the IV will cause the decryption to yield plaintext that is readily detectable as garbled. The decryption process will not, itself, detect any error, so it will not "fail" per se. Steve From nobody Fri Sep 23 10:55:16 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060F312BBEF for ; Fri, 23 Sep 2016 10:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhbnPPwnnhZZ for ; Fri, 23 Sep 2016 10:55:13 -0700 (PDT) Received: from lax-mailout2.raytheon.com (lax-mailout2.raytheon.com [199.46.200.208]) (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 95EF812B89E for ; Fri, 23 Sep 2016 10:55:13 -0700 (PDT) Received: from ca-mailout10.rtnmail.ray.com (ca-mailout10.rtnmail.ray.com [147.25.146.12]) by lax-mailout2.raytheon.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u8NHt5ch019006 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Sep 2016 17:55:05 GMT Received: from smtp.bbn.com ([128.33.0.80]) by ca-mailout10.rtnmail.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id u8NHt0KK008707 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Fri, 23 Sep 2016 17:55:04 GMT Received: from ssh.bbn.com ([192.1.122.15]:51257 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bnUge-0000q7-Hq; Fri, 23 Sep 2016 13:55:00 -0400 From: Stephen Kent To: Jim Schaad , "'secdir'" , "'Justin Richer'" , "'Kepeng Li'" , "'Kathleen Moriarty'" References: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> <080101d21461$de39f850$9aade8f0$@augustcellars.com> Message-ID: <2228fec7-f5ef-c5e2-91bd-7499e7cb9f19@bbn.com> Date: Fri, 23 Sep 2016 13:55:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <080101d21461$de39f850$9aade8f0$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-23_07:, , signatures=0 Archived-At: Subject: Re: [secdir] secdir review of cose-msg-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 17:55:15 -0000 Jim, How's harvest going? > [JLS] This was the approach that I had originally intended to take, bre= aking the document in two pieces towards the end when things were settled= =2E My memory is that this was discussed in the working group, and it wa= s determined that one document was preferable to having two different doc= uments. I believe that this practice started with CMS and it was done th= ere to deal with the question of how to advance to standards track for th= e format document and still allow the algorithm document to be updated. = This has not seemed to be how things have worked in practice, or has been= necessary as protocol documents such as S/MIME is where the implementati= on requirements on algorithms are specified rather than in the format dra= ft (CMS). I therefore have less problems with the fact that this is one = draft from that standpoint. It would have been nicer just from a length = prospective, but people thought that being able to reference back and for= th in a single HTML page to be better than flipping between different pag= es. I hear from you and others that this is what the WG wanted. So, please=20 add text at the beginning of the algs discussion noting that when it=20 becomes necessary to add or remove algs the plan is to ... > [JLS] There was a long discussion about what to do with the CDDL gramm= ar portions of the document. Like me, it would appear that you are a str= ong advocate of doing formal languages and making them normative rather t= han making descriptive text normative. Given the state of CDDL making it= a normative reference would be difficult since it is still being transfo= rmed. I have argued with the authors to try and get what is there publis= hed but have not been successful. I reread Section 1.3 and I see that you did say that the text describing = COSE structures, not the CDDL, is normative. Since CDDL might change, do = you feel that 1.3 provides enough background so that a reader need not=20 refer the CDDL I-D? What's the plan if the RFC version of CDDL differs=20 from the current version in a way that causes the descriptions in this=20 document to no longer be accurate descriptions of COSE structures? > [JLS] I thought about making this change in the past but had an issue w= ith the fact that this might make people think that the Signed Data objec= t version could only be used if there were two or more signers. It allow= s for one or more signers so it is a bit of a misnomer to say that it is = a multiple signer version. The structures are build in such a way that o= ne cannot switch between the versions so you cannot just go from the Sing= le Signer to the Multiple Signer when a second signature is added. > > I can understand the issue you are raising, but the solution has simila= r issues. The term "One or More Signer Data Object" seems to be a bit un= wieldy. Other suggestions would be welcome. Multi-signer Data Object seems concise to me ;-) > Section 5 describes the COSE encryption objects. I disagree with one ch= oice of terminology adopted here: =E2=80=9Crecipient algorithm classes=E2= =80=9D which is described in 5.1.1. This is really a discussion of classe= s of key distribution/management algorithms, focusing on how each recipie= nt of an encrypted message acquires the CEK used to decrypt the message. = I=E2=80=99d prefer a less obscure name for this sub-section. Otherwise th= is section is well written and provide lots of useful details about how t= o encrypt and decrypt messages for two classes of encryption algorithms. > > [JLS] I agree that the term is not optimal. There was a long discussio= n about this in the WG on the mailing list. The original term used was "= key management classes" (if memory serves) and there were issues raised b= ecause this is not key management in the world of how does a client get a= symmetric or public key. The fact that the term was ambiguous as to the= problem being solved was thought to be an issue. After a long discussio= n the term "recipient algorithm classes" was adopted. I think "content key distribution methods" is the right title for this,=20 having re-read section 13. That's what you're describing. Steve From nobody Fri Sep 23 12:20:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A12D12B47C for ; Fri, 23 Sep 2016 12:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PSmkox-XqqF for ; Fri, 23 Sep 2016 12:20:40 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F9512B419 for ; Fri, 23 Sep 2016 12:20:39 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 23 Sep 2016 12:33:58 -0700 From: Jim Schaad To: 'Stephen Kent' , 'secdir' , 'Justin Richer' , 'Kepeng Li' , 'Kathleen Moriarty' References: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> <081e01d21474$a3db8440$eb928cc0$@augustcellars.com> In-Reply-To: Date: Fri, 23 Sep 2016 12:20:30 -0700 Message-ID: <0aae01d215cf$8e4f2210$aaed6630$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLn+ErX890UkhHKZArMVoO8r82N0wHmsi+KAgV97+6ePEzSQA== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: Re: [secdir] secdir review of cose-msg-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 19:20:42 -0000 > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Friday, September 23, 2016 10:54 AM > To: Jim Schaad ; 'secdir' ; = 'Justin > Richer' ; 'Kepeng Li' ; = 'Kathleen > Moriarty' > Subject: Re: secdir review of cose-msg-18 >=20 > Jim, >=20 > Thanks for making the changes you describe as done. Comments below on = the > few remaining items. >=20 > > Applications should have a statement if the label can be omitted. > > -> Applications SHOULD (?) have a statement if the label can be = omitted. > > > > [JLS] I believe that lower case is correct here. This would not be = a > > requirement on the COSE protocol, but on the application that is = using > > COSE. It does not make sense to me to have 2119 language for this > > type of statement. (Partly from an initial brow beating from Russ.) > OK. > > Integers are from the "CoAP Content-Formats" IANA registry table. = (no > > reference) > > > > [JLS] What do you think should be referenced here? Are you looking = for a URL > to iana.org? Not sure that this makes sense. > When you refer to IANA registries defined in the doc you cite the = relevant > section of the doc. Since this registry already exists I think it = would be > appropriate to include a pointer to it: > http://www.iana.org/assignments/core-parameters/core-parameters.xhtml I am not overwhelmed, but I will do this > > As the IV is authenticated by the encryption process, it can be = placed > > in the unprotected header bucket. (in general, an encryption process > > will not =E2=80=9Cauthenticate=E2=80=9D an IV, but use of a modified = IV will yield > > mangled plaintext, which can be detected by an integrity check or a > > signature. the same comment applies to the similar statement in the > > =E2=80=9Cpartial IV=E2=80=9D description.) > > > > [JLS] Does this work? > > > > The IV can be placed in the unprotected header as modifying the IV = will cause > the decryption of the plaintext to fail. > How about: >=20 > The IV can be placed in the unprotected header as modifying the IV = will cause > the decryption to yield plaintext that is readily detectable as = garbled. That works for me. Will do >=20 >=20 > The decryption process will not, itself, detect any error, so it will = not "fail" per > se. >=20 > Steve From nobody Sat Sep 24 02:16:54 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEA112B6A4; Sat, 24 Sep 2016 02:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk-9ivDcabpm; Sat, 24 Sep 2016 02:16:45 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 9E80412B65A; Sat, 24 Sep 2016 02:16:44 -0700 (PDT) Received: from latte.josefsson.org ([IPv6:2001:9b0:104:42::a86]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u8O9GSq0029158 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 24 Sep 2016 11:16:30 +0200 Date: Sat, 24 Sep 2016 11:16:22 +0200 From: Simon Josefsson To: Dan Harkins Message-ID: <20160924111622.6d1308ce@latte.josefsson.org> In-Reply-To: <66a779c8-d87b-7c70-c7cf-7eabc48f9880@lounge.org> References: <87fuosqtkh.fsf@latte.josefsson.org> <66a779c8-d87b-7c70-c7cf-7eabc48f9880@lounge.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/jFWRtLRbl4z4umFBeer7kxB"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.99.2 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: draft-harkins-salted-eap-pwd.all@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2016 09:16:47 -0000 --Sig_/jFWRtLRbl4z4umFBeer7kxB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Den Fri, 23 Sep 2016 10:37:25 -0700 skrev Re: [secdir] secdir review of draft-harkins-salted-eap-pwd-06: >=20 > Hi Simon, >=20 > On 9/22/16 12:31 AM, Simon Josefsson wrote: > > Hello, > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should > > treat these comments just like any other last call comments. >=20 > Thank you for your review and comments. Hi Dan. Thanks for quick response. > > This document adds support for salted password databases to EAP-pwd > > (RFC5931). I believe the document is Not Ready for the following > > reasons: > > > > 1) The introduction and security considerations fails to > > acknowledge that password salting is not sufficient to protect > > against real-world password recovery attacks. Iterative constructs > > are needed. This knowledge is old, PBKDF2/RFC2898 (which is one > > standard technique to address the problem) was published in 2000 > > and has been widely deployed since then. The document should > > mention this aspect. There have been many successful attacks > > against pure-salted password databases in the real world, for > > example: https://en.wikipedia.org/wiki/2012_LinkedIn_hack >=20 > The intent is to support existing databases that RFC 5931 could > not. I guess it deserves to be mentioned in case someone wants to > create a new salted password database. I will add something regarding > real-world attacks to recover passwords given a salted/encrypted > database. Thank you. I believe the experience and understanding in this field is that it is not responsible to publish a document suggesting to use only salted password databases today, or even 10 years ago. Anything in that direction should come with serious warnings that you are doing something that the community believe is a bad idea, combined with guidelines on how to do it properly (PBKDF2/scrypt). It seems we are on the same page here, and the detail is how to get the document to say that. > > 2) Code points for the pre-processing techniques PBKDF2 (RFC > > 2898) and scrypt (RFC 7914) should be added, to support use of best > > security practices. >=20 > Great suggestion, I will add these. Thank you. Some way to encode the PBKDF2/scrypt parameters in the salt field is required, which require some additional specification work. I am happy to review text here. > > 3) There are interop concerns with crypt() when discussion about > > which crypt algorithms (DES, MD5, etc) are to be used is lacking. > > The page mentions a > > couple of algorithms, but several others exist out there. Consider > > if the server tells the client to use an exotic crypt() schema like > > BSDi or NTHASH, and the client does not support this algorithm. > > The document should discuss the sub-negotiation problem. The > > document should mention what happens when the server choses an > > algorithm the client doesn't support. The document should > > recommend that servers use widely-implemented schemas, like DES, > > md5, or sha256. >=20 > Yes, there needs to be something to deal with failure of a client > to support a server's crypt algorithm. Since this is not a dynamic > sort of thing-- oh, you don't like BSDi, how about sha256?-- so I > think the only option is failure, but it should be mentioned. Agreed. Failure appears like the only option, but it should be made clear. It should also be made clear that servers ought to pick common algorithms to avoid this problem, even though the strategy isn't 100%. > > 4) Introducing a new pre-processing technique like > > OpaqueString+SHA1 or OpaqueString+crypt() add complexity. As far > > as I understand, there are no password databases with > > OpaqueString-processed passwords which are hashed with SHA-1 or > > crypt out there today. Thus there is no interop argument for > > introducing the methods. Please confirm that the intention is to > > introduce these methods as new ideas. Then let me suggest that you > > only describe OpaqueString+SHA256 and skip OpaqueString+SHA1, > > OpaqueString+SHA512, OpaqueString+crypt. This reduces complexity > > and does not cause a reduction of security. >=20 > Actually no, these aren't for new databases. There has to be some > canonical way to deal with "international" character sets. RFC 5931 > used to refer to SASLprep but that's been obsoleted. So I MUST now > refer to OpaqueString. >=20 > I went to the OpaqueString tutorial a couple of IETFs ago and asked > whether passwords treated with SASLprep would map 1:1 to passwords > treated with OpaqueString and the answer I got was something like, > "uhm, well, I'm not sure. I think so." So the expectation is that a > passphrase of "Eu amo S=C3=A3o Paulo" (with the problematic diacritical) > in an existing database created by SASLprep could be used with salted > EAP-pwd and the corresponding OpaqueString pre-processing technique. > And that means that every non-internationalized salting technique > needs an OpaqueString version, including SHA1 and crypt. I do not understand. Are you saying that you know of implemented/deployed password databases that uses PRECIS OpaqueString processed passwords that are salted and then hashed, the way described by your document? This would surprise me greatly, but of course it is not impossible. In my experience, people who are aware of PRECIS/OpaqueString for password processing are aware of iterated password processing algorithms like PBKDF2. I would say more people are aware of PBKDF2 than PRECIS/OpaqueString. Or are you saying that your intent is to support existing deployed SASLprep prepared databases? Do you know of any that use each of SHA1, SHA256, SHA512 or crypt()? Or was the addition of all algorithms for completness? SASLprep and OpaqueString are not the same algorithm, and they don't map 1:1, otherwise there wouldn't be any need to have two algorithms. If the intent is to support existing salted+hashed password databases with SASLprep, refering to OpaqueString won't work. This may be a similar situation as with iterated vs non-iterated algorithms. You could include SASLprep for legacy reasons, but recommend use of OpaqueString going forward. Same as including SHA1(salt|password) for legacy but recommend use of PBKDF2/scrypt going forward. > > Further, password databases with HTTP Digest MD5 passwords are > > widely used. For added legacy compatibility, consider support it > > too. This is not a show stopper, but failure to mentioning it in > > the context of deployed password databases appears to me like an > > elephant in the room. Where there conscious reasons for not > > including it? It may be worth stating those reasons in the > > document, if that is the case. >=20 > Good suggestion. I'll add MD5 too. Refer to RFC 7616 for details, it is not as easy as MD5(salt|password), and the document covers SHA-256 and SHA-512/256 too. If you add this, you will need to discuss what the username and realm should be. I don't think you must add this if you have no direct use for it, but acknowledging this widely deployed salted password database appears relevant. It is more important to add PBKDF2/scrypt in my opinion. Thanks, /Simon --Sig_/jFWRtLRbl4z4umFBeer7kxB Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX5kRmAAoJEIYLf7sy+BGdFEkH/iAkWpHDzBtP7fUZeDbDrbpg sq2LoclT8px/pkqmIG5wnYeXYPx1CLpTvg2yr9ybe7U/e5k1uVMKbp2G7HCRvWX3 dNYIrQHGGH14Sz+rLAW8fNdJBDIgHOcMm+WlBPnYva1+kKGCb28OaZw9sB9gyc5B M0n8PsbEVf+UNKhM5bV3ondnld9lVIMvwil/05NqIbtFJE9I7GsoTzy3ipIJfNvS rSbLJXfEuK/jovziv+jT8Zvlbfa2dCEWCepycgie5u7xQ6TybBPPz2QXDpoonQq4 UaIzW80cw/D/9f2JT7Q+0SvpTCs9x/Q9a3CjUB7CBISh1NKtVeLh7LreTQNxWIk= =1Jye -----END PGP SIGNATURE----- --Sig_/jFWRtLRbl4z4umFBeer7kxB-- From nobody Sat Sep 24 07:37:53 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B6212BCF8; Sat, 24 Sep 2016 07:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJRO_uUREL1h; Sat, 24 Sep 2016 07:37:46 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 7FE5612BCF6; Sat, 24 Sep 2016 07:37:46 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id oz2so48883728pac.2; Sat, 24 Sep 2016 07:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version; bh=XB15zBaMqIMfoqwFTb2/qwjdfLGMybQQWvjxY267Yuo=; b=U063NAaPjU5PJPq53V/t+5ZH0csEO77WXp/P6yHH1GRxE6smzELGPMbkgm+HB+s/CE jT2PGhnP2oxsQ4sXbylipm2127ocN4tu/3ZHU9YkGdLxI41g6+aVflwQUSrGmI4ZjS/5 Vwm9LVIlNdD8i4rOLt+vhUcdmK7A1f5ABJjB20YO9+kYWlPlo2i5soBwrUUxpFbAfVUP bzd+s0WGzHn1h9v5Pi9bpWktkKqeHJldudV+9Kl7F4ejNUXnWXNIOogcqm1a/ivTL2MX PEzayDrmspgPP5WdVsIarcMN33saV72gA1n2wQ6SSK/C3igQ8AgMrf06Ou9nLhC7q8Pa Zvew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=XB15zBaMqIMfoqwFTb2/qwjdfLGMybQQWvjxY267Yuo=; b=DhakXgthhOZHcBhaJnMzk1ldzFiJzkwK52DYHUIbPnOWOI7TIk4IpV87UPkASxBJIK Q4chYPFggzRAogiTmK3rPLk0JwBBsLrVOsxzmFb7gWD5Ci+uxH6vMWlG3AhE07a1YxXN yby7LlXJDN0U/Bsub+mFmYV7FtMU2eq+pikv/Zwo/MivwmV7D0uQkZ3DmqhIjDR0QYWG 7CFTBGfcYByjkEud3GWSnH8K8mH7ay2jIdH9I1fU+GkvEY3WhMHDM5TQGUVuKMShcJQ+ NMwj4u1BM5YQp3FZVq6SsU8zPTUPJj2BjFoRNzzOtlf53F9SDJDVgqnH03tS4LDFjBIy 1p3Q== X-Gm-Message-State: AE9vXwPDhlpNpxh9ewCcnMNHYhkkbznLGp5gEiiOlw+3dQqFVt/M1sExf2wO2MioxFMJkA== X-Received: by 10.66.224.101 with SMTP id rb5mr22115046pac.45.1474727866118; Sat, 24 Sep 2016 07:37:46 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:5831:d12a:dde3:e542]) by smtp.googlemail.com with ESMTPSA id k80sm19159202pfk.27.2016.09.24.07.37.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Sep 2016 07:37:45 -0700 (PDT) To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-lisp-crypto.all@etf.org From: Chris Lonvick Message-ID: <57E68FB7.10408@gmail.com> Date: Sat, 24 Sep 2016 09:37:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020206010006070807020704" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-lisp-crypto-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2016 14:37:49 -0000 This is a multi-part message in MIME format. --------------020206010006070807020704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Dino, Brian, and 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 is acceptable for an Experimental RFC. I don't follow LISP so I'm not sure if there is an actual mechanism for a device receiving a map request packet to decline an offered cipher suite. If there is, I didn't see it explained in the draft. You should address this in a future draft. This will be needed for when new cipher suites are added and a receiving device does not have the capability to handle the new cipher suite, or the case where an old cipher suite has been administratively disabled; like if it's been compromised and shouldn't be used. There are several ways to do this. There are a few nits in the draft you may want to take care of. First, Section 6 talks about setting the R bit to 0. Current: The 'R' bit is not used for this use-case of the Security Type LCAF but is reserved for [LISP-DDT ] security. Therefore, the R bit is transmitted as 0 and ignored on receipt. Proposed: The 'R' bit is not used for this use-case of the Security Type LCAF but is reserved for [LISP-DDT ] security. Therefore, the R bit SHOULD be transmitted as 0 and MUST be ignored on receipt. A few other things I found: s/assymmetric/asymmetric/ s/Soon as an ETR or RTR/As soon as an ETR or RTR/ s/followed by key-id 2, an finally key-id 3/followed by key-id 2, and finally key-id 3/ Best regards, Chris --------------020206010006070807020704 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Dino, Brian, and 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 is acceptable for an Experimental RFC.

I don't follow LISP so I'm not sure if there is an actual mechanism for a device receiving a map request packet to decline an offered cipher suite. If there is, I didn't see it explained in the draft. You should address this in a future draft. This will be needed for when new cipher suites are added and a receiving device does not have the capability to handle the new cipher suite, or the case where an old cipher suite has been administratively disabled; like if it's been compromised and shouldn't be used. There are several ways to do this.

There are a few nits in the draft you may want to take care of. First, Section 6 talks about setting the R bit to 0.
Current:
   The 'R' bit is not used for this use-case of the Security Type LCAF
   but is reserved for [LISP-DDT] security.  Therefore, the R bit is
   transmitted as 0 and ignored on receipt.
Proposed:
   The 'R' bit is not used for this use-case of the Security Type LCAF but is
   reserved for [LISP-DDT] security. Therefore, the R bit SHOULD be transmitted
   as 0 and MUST be ignored on receipt.

A few other things I found:
s/assymmetric/asymmetric/
s/Soon as an ETR or RTR/As soon as an ETR or RTR/
s/followed by key-id 2, an finally key-id 3/followed by key-id 2, and finally key-id 3/

Best regards,
Chris

--------------020206010006070807020704-- From nobody Sat Sep 24 07:42:04 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0140B12BD2C; Sat, 24 Sep 2016 07:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew-FZlDyy3ES; Sat, 24 Sep 2016 07:41:56 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 7147B12BD05; Sat, 24 Sep 2016 07:41:53 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id oz2so48899974pac.2; Sat, 24 Sep 2016 07:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=vCmSMvu34oiwsgWYdrNIYt1qdY+cYzDhqbJLO+jPqrw=; b=vhAkDy9Zh35Dx8XJmXGxsAZIWVBUl0dCVYP+nfug96+tvldZIu8fWas5CiinkQz0Gs My7+oFC5dn6M43gRn/z40OoC55FVMQ9juxVd6zF0cWPhMYVjFfVK4mLlHt+Ywk7/LVj3 xGz7P5FzCXtsYy6BIt0aIUGhytYMJ8sOHoOdiF7GVvw588Xc8TV1Jemmp6O0FK13Ttoo OzVpXsMcTCxTWhpm3yV9SxlL42AvZ9cqBN0luRz3Gk/78Igkq2WnV5gvcqO0e6JuovYS VdVuYIWSUdurhyJE6OsKtcDloTqo4pyC9HEgO2V9/Pc95nCYkH0P2ZWr71u6jwL5iAaR I3OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=vCmSMvu34oiwsgWYdrNIYt1qdY+cYzDhqbJLO+jPqrw=; b=OWooPIovHQRG84cYejz6VB///wgUtJznZN4h6WzFWrqJxDPA5AJbRryq/yiigZSEB7 LC7G2WjSUEPoi1vQQSktg0AvvjDliDcpjlxg56gSENDwXl6RjWBGJvzF+JgGPpvt2XAS r+rQ30nFdHTq4ejbI532hGN5x2orjLZQrWq5hiPjKWiR0qDrrQDhT4sA1sY34WLaGmSD OIWiTiY/QMqSOfaYmESPSUzK4kTTtZlzk4O/GNw/XFcTzTaXJwtXwp4wTGtLqYarP5vF PPF6zLjMBxhqxYPsD8dCCQXO9UrvgoRY8QPjmgfmtsMJnzYpExHMpZqWWCFhcUo1JZ7S 6ZTA== X-Gm-Message-State: AE9vXwNt29V5omkxSpwD4GnYfkALSj4Zza5HEmy5jCurmCGr1BsaOFwFbE3CxNQH83NkQQ== X-Received: by 10.66.159.1 with SMTP id wy1mr22358904pab.20.1474728112781; Sat, 24 Sep 2016 07:41:52 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:5831:d12a:dde3:e542]) by smtp.googlemail.com with ESMTPSA id a137sm19124693pfa.72.2016.09.24.07.41.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Sep 2016 07:41:52 -0700 (PDT) To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-lisp-crypto.all@ietf.org References: <57E68FB7.10408@gmail.com> From: Chris Lonvick Message-ID: <57E690AD.2030207@gmail.com> Date: Sat, 24 Sep 2016 09:41:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57E68FB7.10408@gmail.com> Content-Type: multipart/alternative; boundary="------------040608090405050902030209" Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2016 14:41:59 -0000 This is a multi-part message in MIME format. --------------040608090405050902030209 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cut-n-pasted wrong. Resending. Thanks, Chris On 9/24/16 9:37 AM, Chris Lonvick wrote: > Hi Dino, Brian, and 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 is acceptable for an Experimental RFC. > > I don't follow LISP so I'm not sure if there is an actual mechanism > for a device receiving a map request packet to decline an offered > cipher suite. If there is, I didn't see it explained in the draft. You > should address this in a future draft. This will be needed for when > new cipher suites are added and a receiving device does not have the > capability to handle the new cipher suite, or the case where an old > cipher suite has been administratively disabled; like if it's been > compromised and shouldn't be used. There are several ways to do this. > > There are a few nits in the draft you may want to take care of. First, > Section 6 talks about setting the R bit to 0. > Current: > The 'R' bit is not used for this use-case of the Security Type LCAF > but is reserved for [LISP-DDT > ] security. Therefore, the R bit is > transmitted as 0 and ignored on receipt. > Proposed: > The 'R' bit is not used for this use-case of the Security Type LCAF > but is > reserved for [LISP-DDT > ] > security. Therefore, the R bit SHOULD be transmitted > as 0 and MUST be ignored on receipt. > > A few other things I found: > s/assymmetric/asymmetric/ > s/Soon as an ETR or RTR/As soon as an ETR or RTR/ > s/followed by key-id 2, an finally key-id 3/followed by key-id 2, and > finally key-id 3/ > > Best regards, > Chris > --------------040608090405050902030209 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Cut-n-pasted wrong. Resending.
Thanks,
Chris

On 9/24/16 9:37 AM, Chris Lonvick wrote:
Hi Dino, Brian, and 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 is acceptable for an Experimental RFC.

I don't follow LISP so I'm not sure if there is an actual mechanism for a device receiving a map request packet to decline an offered cipher suite. If there is, I didn't see it explained in the draft. You should address this in a future draft. This will be needed for when new cipher suites are added and a receiving device does not have the capability to handle the new cipher suite, or the case where an old cipher suite has been administratively disabled; like if it's been compromised and shouldn't be used. There are several ways to do this.

There are a few nits in the draft you may want to take care of. First, Section 6 talks about setting the R bit to 0.
Current:
   The 'R' bit is not used for this use-case of the Security Type LCAF
   but is reserved for [LISP-DDT] security.  Therefore, the R bit is
   transmitted as 0 and ignored on receipt.
Proposed:
   The 'R' bit is not used for this use-case of the Security Type LCAF but is
   reserved for [LISP-DDT] security. Therefore, the R bit SHOULD be transmitted
   as 0 and MUST be ignored on receipt.

A few other things I found:
s/assymmetric/asymmetric/
s/Soon as an ETR or RTR/As soon as an ETR or RTR/
s/followed by key-id 2, an finally key-id 3/followed by key-id 2, and finally key-id 3/

Best regards,
Chris


--------------040608090405050902030209-- From nobody Sat Sep 24 11:53:37 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A12F12B025 for ; Sat, 24 Sep 2016 11:53:32 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcdyvqmAgvFb for ; Sat, 24 Sep 2016 11:53:31 -0700 (PDT) Received: from nm6-vm3.access.bullet.mail.bf1.yahoo.com (nm6-vm3.access.bullet.mail.bf1.yahoo.com [216.109.114.146]) (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 7401112B027 for ; Sat, 24 Sep 2016 11:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1474743208; bh=ctB9D+43zKgfQRaOIUOAp3vHsOC8KMQ6Aa+czouNiws=; h=To:From:Subject:Date:From:Subject; b=hAdTfjJ3hoVduonfkOZhQ7YsS/IGwSpbwYMN5AQAv8xQ8p6WdfT+iITko5jRrab5QRWKHttN4+0eRjnBhO/Bx/0uvCKF+ZOSBX/teBm6HAm4SCyg+AxSn2tL5GtC8OkkvwphQE3VJH/f/q6VxH+WCXRk3dhcT3+h6Cavt8pfvQpnbsu7ivEGnW2l6OwQLJZUXXvo0KMuU/HjSA6ocg4CNNPaoEqeKc7aWt1EYkJRKl7EY2MamwOFfgmYDoIAiaFocV/NBFQwvXEpAdOmbIuz0P7yD5PeEHKpHbFzK5dO8FCpk5m/PMvbb8ZNw/qkZbDXFjcwd1bbLlzobsb/Byn7cw== Received: from [66.196.81.161] by nm6.access.bullet.mail.bf1.yahoo.com with NNFMP; 24 Sep 2016 18:53:28 -0000 Received: from [98.138.226.244] by tm7.access.bullet.mail.bf1.yahoo.com with NNFMP; 24 Sep 2016 18:53:28 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 24 Sep 2016 18:53:28 -0000 X-Yahoo-Newman-Id: 780553.12739.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: SlvL690VM1m4E1wmHLvbtHK6.0Lwgo9SPkt82yeuYQu0D4Y RnKVQq216WmLGH0xzaVHOy..2aEYp.G.DNFdC9tiXQQvLamQVmXnWjLaDcBY teHFne9nN_Fyi6ryFv0i1_4W6c3eTgtWF9pZTdRY6KHtNyb_Vot3JLb.IEnC BhgO_o32N.86qC0w6XvRB7b82QaVnbslKkht4PpdpIq_LQOTOSVL8JHls4_q 4dpoJlk_czdu_4wy_4LRNRllHVAzSi58GH8HL_uFtLK6dVn91gQnb7Kyy5J9 hqUQEj187Bs8MXhQjS7Ep7jxhoWz8Lf_fw1mx5C8vOJJ8joGXSy9TFdp7A0i lbjYC3Pe04oA1pedvDiwejEqWsISH2m7rwOr1tzpo64KmBvcUXC30KClAJJ4 BAy1iLxz.VOrwOBtndiPGzF7GxttJcvcdG9Zvrw_zJ7ppiGtBrFBwtI.accg ZMOnYOy5zmx_BM.tc_.f6nERvtwJc_Mgnn7xnW5KWVrb6yL61DEK3zReDK9a taNlEd3vYVOqiDuA7D_fTI.rwb_OBXWFaRZnFOUwhlFuXieBV_jNeZU.iDlR 7K5YplrnRxa1dpTmimtYIxvS5bQ-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.153] (209-6-88-55.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.88.55]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 981251C6045; Sat, 24 Sep 2016 14:53:27 -0400 (EDT) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-lisp-lcaf.all@ietf.org From: David Mandelberg Message-ID: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> Date: Sat, 24 Sep 2016 14:53:23 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DwSatSTx3v4Md3nGMrjvq2XPwHSdAhn09" Archived-At: Subject: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2016 18:53:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DwSatSTx3v4Md3nGMrjvq2XPwHSdAhn09 Content-Type: multipart/mixed; boundary="tISn36lG0w7ju20PlijCpO5RPLEhQu3Oe" From: David Mandelberg To: iesg@ietf.org, secdir@ietf.org, draft-ietf-lisp-lcaf.all@ietf.org Message-ID: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> Subject: secdir review of draft-ietf-lisp-lcaf-15 --tISn36lG0w7ju20PlijCpO5RPLEhQu3Oe Content-Type: text/plain; charset=utf-8 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 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 found one issue in various parts of the document (described below), but I'm not sure it's relevant to security. If it is, then I think this document is Almost Ready. If not, then I think this document is Ready With Nits. There are multiple places in the document where it's possible to encode semantically equivalent information in multiple ways, despite the word "canonical" being in the title of the document. Is there anything that relies on these addresses being canonical for security purposes? Multiple places in the document (sections 4.1, 4.5, and 4.8) specify mask lengths, but do not specify that the masked out bits MUST be set to zero. Section 4.4: The description of RTR RLOC Address gives two different ways to encode an address with zero RTRs. Section 4.10.5: If I understand the compatibility mode correctly, this explicitly creates a second way to encode a semantically identical addres= s. Section 5.4: There are many different ways to encode equivalent JSON data here. Section 6 (Security Considerations): There is no discussion of these addresses being canonical, and what other systems might or might not rely on these addresses being canonical. I also have some questions/nits: Section 3: Shouldn't the LCAF sort-key of {afi, LCAF-Type} also include the RLOC-address or LCAF payload? Section 4.3: Altitude is described as a signed integer, but this document doesn't specify the encoding. I assume it's two's complement, but that should probably be made explicit. Section 4.7: The Key Count description talks about "Key sections," but doesn't say which fields are part of the key section (and can thus be repeated). I have a guess which fields are part of the key section, but it's not entirely clear. Section 4.7: The Key Algorithm description doesn't point to a registry of valid values or otherwise say how to interpret values in that field. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --tISn36lG0w7ju20PlijCpO5RPLEhQu3Oe-- --DwSatSTx3v4Md3nGMrjvq2XPwHSdAhn09 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 iEYEARECAAYFAlfmy6MACgkQRKlmUHCg4sAVQgCfWQCSynSiL0V3JeEFUrVIswqV WqIAoJhEQeLS2P5js2fxo56KyIqWmv6j =mRjK -----END PGP SIGNATURE----- --DwSatSTx3v4Md3nGMrjvq2XPwHSdAhn09-- From nobody Sat Sep 24 12:11:58 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C35B12B01C; Sat, 24 Sep 2016 12:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqPDq4YoPJvp; Sat, 24 Sep 2016 12:11:50 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 5F18812B025; Sat, 24 Sep 2016 12:11:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 448431C5B87; Sat, 24 Sep 2016 12:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1474744310; bh=r7jR4Eo0KK8c9uaJcegv9cIey/7bhGzGIE+aBTCBT+Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=cUsKO8iRV8DRLCCzZfujKltI7e8L4Dpvg+Yw/g7V3c0NFDVg/BwMKd7kGBwvHLqLH Fxqh0tPchJiPbofdm4WmscwFIeU6052gGu4XzrZTZ07qDCLZs863BLBjtFoMgO/JFB 15pisZ7ZDnTeAOstxEMBEXu6yENn1SAEj/V9JDc0= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 927071C031A; Sat, 24 Sep 2016 12:11:49 -0700 (PDT) To: David Mandelberg , iesg@ietf.org, secdir@ietf.org, draft-ietf-lisp-lcaf.all@ietf.org References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> From: "Joel M. Halpern" Message-ID: <28c0b4b6-c4b8-94a2-fc7c-629b66085b50@joelhalpern.com> Date: Sat, 24 Sep 2016 15:13:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2016 19:11:52 -0000 As I understand it, the multiple representations are deliberate. I do think we should add a little text in the security considerations section noting that the representation has to be preserved if the information is signed. Your comment on the algorithm ID in section 4.7 seems cogent. I will let the authors respond. On 9/24/16 2:53 PM, David Mandelberg wrote: > 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 found one issue in various parts of the document (described below), > but I'm not sure it's relevant to security. If it is, then I think this > document is Almost Ready. If not, then I think this document is Ready > With Nits. > > There are multiple places in the document where it's possible to encode > semantically equivalent information in multiple ways, despite the word > "canonical" being in the title of the document. Is there anything that > relies on these addresses being canonical for security purposes? > > Multiple places in the document (sections 4.1, 4.5, and 4.8) specify > mask lengths, but do not specify that the masked out bits MUST be set to > zero. > > Section 4.4: The description of RTR RLOC Address gives two different > ways to encode an address with zero RTRs. > > Section 4.10.5: If I understand the compatibility mode correctly, this > explicitly creates a second way to encode a semantically identical address. > > Section 5.4: There are many different ways to encode equivalent JSON > data here. > > Section 6 (Security Considerations): There is no discussion of these > addresses being canonical, and what other systems might or might not > rely on these addresses being canonical. > > > I also have some questions/nits: > > Section 3: Shouldn't the LCAF sort-key of {afi, LCAF-Type} also include > the RLOC-address or LCAF payload? > > Section 4.3: Altitude is described as a signed integer, but this > document doesn't specify the encoding. I assume it's two's complement, > but that should probably be made explicit. > > Section 4.7: The Key Count description talks about "Key sections," but > doesn't say which fields are part of the key section (and can thus be > repeated). I have a guess which fields are part of the key section, but > it's not entirely clear. > > Section 4.7: The Key Algorithm description doesn't point to a registry > of valid values or otherwise say how to interpret values in that field. > From nobody Sun Sep 25 14:38:04 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0829712B01F; Sun, 25 Sep 2016 14:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcHKIRv_c9Bx; Sun, 25 Sep 2016 14:37:51 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e: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 21EBA12B03C; Sun, 25 Sep 2016 14:37:49 -0700 (PDT) Received: by mail-pa0-x22b.google.com with SMTP id qn7so38456000pac.3; Sun, 25 Sep 2016 14:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=zlCl7CPkR3JE/qFRMSkbdPR9LQSCNqQkG+ewcxOchjU=; b=StKsnneVwQLPLg/a54yszkaIt8v9ZJ+McB0fFuKkwEAxKFXThD1o/0w2NKcAuA6b9D aOHDm7W6GosP0XX0hcQQCa5ihzdmSw9IPnZUkhOKTl4qlay/AfcoJzMKTRDneLkktg3j 0cT5NGHotfNBSYfttuPEzF8ICLRRHrYerteMQkNZG3py0riKYOHaa9mGnXO93KvwG+Kw 8x+VcfAsOK60/uRgr/cNLGwZEqbXc/2MfypNKOcJIY+XiLgv5aMVnfZ8uyr5xZE/4TNC gjvVuOGL/+oJkc8REjk/owWm2my0PyomJsy8+cMB4KmcYRlslipahFKO5nwf+PzrBZU5 Z+5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=zlCl7CPkR3JE/qFRMSkbdPR9LQSCNqQkG+ewcxOchjU=; b=CLbS5rOgN+/QjcVvx2LwMCdePpQficT88FT4DyJFKfDAL98Qh0xxodiInDJZPJtyb3 v2xSch1U2lW/uckv/Gg0Grl8pq5iFa+b+iyniqs4f4WGnhbqNznBKvPvch5qR8Qq2xuR 7DRcE0itfHQ8izYBKmzBhQCy8onadlBtF72mNmi2gXHRhhlBdVQPLF3XW9WFFkI/sJSO Aj6mIb2/9A/RSFpBHTQPdlBmG7dOvOAWH7SFbFLM/AwjgiLRC8M/rAmuu3sq+FVpWYyb Ckr4owR+sxB4iGTEAg5dMPrz7J70LSEc0uj9tFTxqJaFuOxflHzWVxEmQG7PV+BwfYT4 5zmQ== X-Gm-Message-State: AA6/9RniEEpmQY+Y5r8aoEyV3Q7jZkTa+3tHV0xHB096KV08jlZGSwvjSVUqwOHzF36P5Q== X-Received: by 10.66.191.135 with SMTP id gy7mr13696940pac.21.1474839468424; Sun, 25 Sep 2016 14:37:48 -0700 (PDT) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by smtp.gmail.com with ESMTPSA id ra13sm25669683pac.29.2016.09.25.14.37.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 25 Sep 2016 14:37:47 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_DF123D10-5132-4803-B280-F98BC2FA86DA" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <57E690AD.2030207@gmail.com> Date: Sun, 25 Sep 2016 14:37:45 -0700 Message-Id: <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com> References: <57E68FB7.10408@gmail.com> <57E690AD.2030207@gmail.com> To: Chris Lonvick X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-lisp-crypto.all@ietf.org, "iesg@ietf.org" , Dino Farinacci , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 21:37:57 -0000 --Apple-Mail=_DF123D10-5132-4803-B280-F98BC2FA86DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Cut-n-pasted wrong. Resending. > Thanks, > Chris Thanks Chris, glad you did since I didn=E2=80=99t see the original. >> Hi Dino, Brian, and All, >>=20 >> I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >>=20 >> The document is acceptable for an Experimental RFC.=20 Okay, great. >> I don't follow LISP so I'm not sure if there is an actual mechanism = for a device receiving a map request packet to decline an offered cipher = suite. If there is, I didn't see it explained in the=20 Yes, there is. If the Map-Reply this is returned contains no Security = LCAF that means to the ITR that it either needs to go unencrypted = encapsulating packets to the ETR or try another cipher text. >> draft. You should address this in a future draft. This will be needed = for when new cipher suites are=20 Understand the need. We intentionally wanted to support this. >> added and a receiving device does not have the capability to handle = the new cipher suite, or the case where an old cipher suite has been = administratively disabled; like if it's been compromised and shouldn't = be used. There are several ways to do this. We have this in section x of the draft. Is it not sufficient? If an ITR, PITR, or RTR sends a Map-Request with the Security Type LCAF included and the ETR or RTR does not want to have encapsulated traffic encrypted, they will return a Map-Reply with no RLOC records encoded with the Security Type LCAF. This signals to the ITR, PITR or RTR not to encrypt traffic (it cannot encrypt traffic anyways since no ETR public-key was returned). >> There are a few nits in the draft you may want to take care of. = First, Section 6 talks about setting the R bit to 0.=20 >> Current: >> The 'R' bit is not used for this use-case of the Security Type = LCAF >> but is reserved for [ >> LISP-DDT >> ] security. Therefore, the R bit is >> transmitted as 0 and ignored on receipt. >>=20 >> Proposed:=20 >> The 'R' bit is not used for this use-case of the Security Type = LCAF but is=20 >> reserved for [LISP-DDT] security. Therefore, the R bit SHOULD be = transmitted=20 >> as 0 and MUST be ignored on receipt.=20 >>=20 >> A few other things I found: >> s/assymmetric/asymmetric/=20 >> s/Soon as an ETR or RTR/As soon as an ETR or RTR/=20 >> s/followed by key-id 2, an finally key-id 3/followed by key-id 2, and = finally key-id 3/=20 >>=20 >> Best regards, >> Chris All fixed. I did not submit -08 because I wanted to see if you thought = the paragraph above was sufficient. A diff and txt file in enclosed. Thanks again, Dino --Apple-Mail=_DF123D10-5132-4803-B280-F98BC2FA86DA Content-Disposition: attachment; filename=draft-ietf-lisp-crypto-08.txt Content-Type: text/plain; name="draft-ietf-lisp-crypto-08.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force D. Farinacci Internet-Draft lispers.net Intended status: Experimental B. Weis Expires: March 29, 2017 cisco Systems September 25, 2016 LISP Data-Plane Confidentiality draft-ietf-lisp-crypto-08 Abstract This document describes a mechanism for encrypting LISP encapsulated traffic. The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data-plane from third-party surveillance attacks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 29, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Farinacci & Weis Expires March 29, 2017 [Page 1] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 4 6. Encoding and Transmitting Key Material . . . . . . . . . . . 5 7. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 7 8. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 9 9. Procedures for Encryption and Decryption . . . . . . . . . . 10 10. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 11 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 12 12.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 16 B.1. Changes to draft-ietf-lisp-crypto-08.txt . . . . . . . . 16 B.2. Changes to draft-ietf-lisp-crypto-07.txt . . . . . . . . 17 B.3. Changes to draft-ietf-lisp-crypto-06.txt . . . . . . . . 17 B.4. Changes to draft-ietf-lisp-crypto-05.txt . . . . . . . . 17 B.5. Changes to draft-ietf-lisp-crypto-04.txt . . . . . . . . 17 B.6. Changes to draft-ietf-lisp-crypto-03.txt . . . . . . . . 17 B.7. Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . 18 B.8. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 18 B.9. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 18 B.10. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 18 B.11. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The Locator/ID Separation Protocol [RFC6830] defines a set of functions for routers to exchange information used to map from non- routable Endpoint Identifiers (EIDs) to routable Routing Locators (RLOCs). LISP Ingress Tunnel Routers (ITRs) and Proxy Ingress Tunnel Routers (PITRs) encapsulate packets to Egress Tunnel Routers (ETRs) and Reencapsulating Tunnel Routers (RTRs). Packets that arrive at the ITR or PITR are typically not modified, which means no protection or privacy of the data is added. If the source host encrypts the data stream then the encapsulated packets can be encrypted but would be redundant. However, when plaintext packets are sent by hosts, this design can encrypt the user payload to maintain privacy on the Farinacci & Weis Expires March 29, 2017 [Page 2] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 path between the encapsulator (the ITR or PITR) to a decapsulator (ETR or RTR). The encrypted payload is unidirectional. However, return traffic uses the same procedures but with different key values by the same xTRs or potentially different xTRs when the paths between LISP sites are asymmetric. This document has the following requirements (as well as the general requirements from [RFC6973]) for the solution space: o Do not require a separate Public Key Infrastructure (PKI) that is out of scope of the LISP control-plane architecture. o The budget for key exchange MUST be one round-trip time. That is, only a two packet exchange can occur. o Use symmetric keying so faster cryptography can be performed in the LISP data plane. o Avoid a third-party trust anchor if possible. o Provide for rekeying when secret keys are compromised. o Support Authenticated Encryption with packet integrity checks. o Support multiple cipher suites so new crypto algorithms can be easily introduced. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definition of Terms AEAD: Authenticated Encryption with Additional Data. ICV: Integrity Check Value. LCAF: LISP Canonical Address Format ([LCAF]). xTR: A general reference to ITRs, ETRs, RTRs, and PxTRs. 4. Overview The approach proposed in this document is to NOT rely on the LISP mapping system (or any other key infrastructure system) to store security keys. This will provide for a simpler and more secure Farinacci & Weis Expires March 29, 2017 [Page 3] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 mechanism. Secret shared keys will be negotiated between the ITR and the ETR in Map-Request and Map-Reply messages. Therefore, when an ITR needs to obtain the RLOC of an ETR, it will get security material to compute a shared secret with the ETR. The ITR can compute 3 shared-secrets per ETR the ITR is encapsulating to. When the ITR encrypts a packet before encapsulation, it will identify the key it used for the crypto calculation so the ETR knows which key to use for decrypting the packet after decapsulation. By using key-ids in the LISP header, we can also get fast rekeying functionality. The key management described in this documemnt is unidirectional from the ITR (the encapsulator) to the ETR (the decapsultor). 5. Diffie-Hellman Key Exchange LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and computation for computing a shared secret. The Diffie-Hellman parameters will be passed via Cipher Suite code-points in Map-Request and Map-Reply messages. Here is a brief description how Diff-Hellman works: +----------------------------+---------+----------------------------+ | ITR | | ETR | +------+--------+------------+---------+------------+---------------+ |Secret| Public | Calculates | Sends | Calculates | Public |Secret| +------|--------|------------|---------|------------|--------|------+ | i | p,g | | p,g --> | | | e | +------|--------|------------|---------|------------|--------|------+ | i | p,g,I |g^i mod p=3DI | I --> | | p,g,I | e = | +------|--------|------------|---------|------------|--------|------+ | i | p,g,I | | <-- E |g^e mod p=3DE | p,g | e = | +------|--------|------------|---------|------------|--------|------+ | i,s |p,g,I,E |E^i mod p=3Ds | |I^e mod p=3Ds |p,g,I,E | = e,s | +------|--------|------------|---------|------------|--------|------+ Public-key exchange for computing a shared private key [DH] Diffie-Hellman parameters 'p' and 'g' must be the same values used by the ITR and ETR. The ITR computes public-key 'I' and transmits 'I' in a Map-Request packet. When the ETR receives the Map-Request, it uses parameters 'p' and 'g' to compute the ETR's public key 'E'. The ETR transmits 'E' in a Map-Reply message. At this point, the ETR has enough information to compute 's', the shared secret, by using 'I' as the base and the ETR's private key 'e' as the exponent. When the ITR receives the Map-Reply, it uses the ETR's public-key 'E' with the Farinacci & Weis Expires March 29, 2017 [Page 4] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 ITR's private key 'i' to compute the same 's' shared secret the ETR computed. The value 'p' is used as a modulus to create the width of the shared secret 's' (see Section 6). 6. Encoding and Transmitting Key Material The Diffie-Hellman key material is transmitted in Map-Request and Map-Reply messages. Diffie-Hellman parameters are encoded in the LISP Security Type LCAF [LCAF]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 11 | Rsvd2 | 6 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Count | Rsvd3 | Cipher Suite | Rsvd4 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Length | Public Key Material ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Public Key Material | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Locator Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cipher Suite field contains DH Key Exchange and Cipher/Hash Functions The 'Key Count' field encodes the number of {'Key-Length', 'Key- Material'} fields included in the encoded LCAF. The maximum number of keys that can be encoded are 3, each identified by key-id 1, followed by key-id 2, and finally key-id 3. The 'R' bit is not used for this use-case of the Security Type LCAF but is reserved for [LISP-DDT] security. Therefore, the R bit SHOULD be transmitted as 0 and MUST be ignored on receipt. Farinacci & Weis Expires March 29, 2017 [Page 5] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 Cipher Suite 0: Reserved Cipher Suite 1: Diffie-Hellman Group: 2048-bit MODP [RFC3526] Encryption: AES with 128-bit keys in CBC mode [AES-CBC] Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256 IV length: 16 bytes Cipher Suite 2: Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Encryption: AES with 128-bit keys in CBC mode [AES-CBC] Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256 IV length: 16 bytes Cipher Suite 3: Diffie-Hellman Group: 2048-bit MODP [RFC3526] Encryption: AES with 128-bit keys in GCM mode [RFC5116] Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM IV length: 12 bytes Cipher Suite 4: Diffie-Hellman Group: 3072-bit MODP [RFC3526] Encryption: AES with 128-bit keys in GCM mode [RFC5116] Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM IV length: 12 bytes Cipher Suite 5: Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Encryption: AES with 128-bit keys in GCM mode [RFC5116] Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM IV length: 12 bytes Cipher Suite 6: Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] Encryption: Chacha20-Poly1305 [CHACHA-POLY] [RFC7539] Integrity: Integrated with [CHACHA-POLY] AEAD_CHACHA20_POLY1305 IV length: 8 bytes The "Public Key Material" field contains the public key generated by one of the Cipher Suites defined above. The length of the key in octets is encoded in the "Key Length" field. When an ITR, PITR, or RTR sends a Map-Request, they will encode their own RLOC in the Security Type LCAF format within the ITR-RLOCs field. When a ETR or RTR sends a Map-Reply, they will encode their RLOCs in Farinacci & Weis Expires March 29, 2017 [Page 6] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 Security Type LCAF format within the RLOC-record field of each EID- record supplied. If an ITR, PITR, or RTR sends a Map-Request with the Security Type LCAF included and the ETR or RTR does not want to have encapsulated traffic encrypted, they will return a Map-Reply with no RLOC records encoded with the Security Type LCAF. This signals to the ITR, PITR or RTR not to encrypt traffic (it cannot encrypt traffic anyways since no ETR public-key was returned). Likewise, if an ITR or PITR wish to include multiple key-ids in the Map-Request but the ETR or RTR wish to use some but not all of the key-ids, they return a Map-Reply only for those key-ids they wish to use. 7. Shared Keys used for the Data-Plane When an ITR or PITR receives a Map-Reply accepting the Cipher Suite sent in the Map-Request, it is ready to create data plane keys. The same process is followed by the ETR or RTR returning the Map-Reply. The first step is to create a shared secret, using the peer's shared Diffie-Hellman Public Key Material combined with device's own private keying material as described in Section 5. The Diffie-Hellman parameters used is defined in the cipher suite sent in the Map- Request and copied into the Map-Reply. The resulting shared secret is used to compute an AEAD-key for the algorithms specified in the cipher suite. A Key Derivation Function (KDF) in counter mode as specified by [NIST-SP800-108] is used to generate the data-plane keys. The amount of keying material that is derived depends on the algorithms in the cipher suite. The inputs to the KDF are as follows: o KDF function. This is HMAC-SHA-256. o A key for the KDF function. This is the computed Diffie-Hellman shared secret. o Context that binds the use of the data-plane keys to this session. The context is made up of the following fields, which are concatenated and provided as the data to be acted upon by the KDF function. Context: o A counter, represented as a two-octet value in network byte order. Farinacci & Weis Expires March 29, 2017 [Page 7] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 o The null-terminated string "lisp-crypto". o The ITR's nonce from the Map-Request the cipher suite was included in. o The number of bits of keying material required (L), represented as a two-octet value in network byte order. The counter value in the context is first set to 1. When the amount of keying material exceeds the number of bits returned by the KDF function, then the KDF function is called again with the same inputs except that the counter increments for each call. When enough keying material is returned, it is concatenated and used to create keys. For example, AES with 128-bit keys requires 16 octets (128 bits) of keying material, and HMAC-SHA1-96 requires another 16 octets (128 bits) of keying material in order to maintain a consistent 128-bits of security. Since 32 octets (256 bits) of keying material are required, and the KDF function HMAC-SHA-256 outputs 256 bits, only one call is required. The inputs are as follows: key-material =3D HMAC-SHA-256(dh-shared-secret, context) where: context =3D 0x0001 || "lisp-crypto" || || = 0x0100 In contrast, a cipher suite specifying AES with 256-bit keys requires 32 octets (256 bits) of keying material, and HMAC-SHA256-128 requires another 32 octets (256 bits) of keying material in order to maintain a consistent 256-bits of security. Since 64 octets (512 bits) of keying material are required, and the KDF function HMAC-SHA-256 outputs 256 bits, two calls are required. key-material-1 =3D HMAC-SHA-256(dh-shared-secret, context) where: context =3D 0x0001 || "lisp-crypto" || || = 0x0200 key-material-2 =3D HMAC-SHA-256(dh-shared-secret, context) where: context =3D 0x0002 || "lisp-crypto" || || = 0x0200 key-material =3D key-material-1 || key-material-2 If the key-material is longer than the required number of bits (L), then only the most significant L bits are used. =46rom the derived key-material, the most significant 256 bits are = used for the AEAD-key by AEAD ciphers. The 256-bit AEAD-key is divided Farinacci & Weis Expires March 29, 2017 [Page 8] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 into a 128-bit encryption key and a 128-bit integrity check key internal to the cipher used by the ITR. 8. Data-Plane Operation The LISP encapsulation header [RFC6830] requires changes to encode the key-id for the key being used for encryption. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L / |N|L|E|V|I|R|K|K| Nonce/Map-Version |\ \ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A S \ | Instance ID/Locator-Status-Bits | |D P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |/ | Initialization Vector (IV) | I E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C n / | | V c | | | r | Packet Payload with EID Header ... | | y | | | p \ | |/ t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ K-bits indicate when packet is encrypted and which key used When the KK bits are 00, the encapsulated packet is not encrypted. When the value of the KK bits are 1, 2, or 3, it encodes the key-id of the secret keys computed during the Diffie-Hellman Map-Request/ Map-Reply exchange. When the KK bits are not 0, the payload is prepended with an Initialization Vector (IV). The length of the IV field is based on the cipher suite used. Since all cipher suites defined in this document do Authenticated Encryption (AEAD), an ICV field does not need to be present in the packet since it is included in the ciphertext. The Additional Data (AD) used for the ICV is shown above and includes the LISP header, the IV field and the packet payload. When an ITR or PITR receives a packet to be encapsulated, they will first decide what key to use, encode the key-id into the LISP header, and use that key to encrypt all packet data that follows the LISP header. Therefore, the outer header, UDP header, and LISP header travel as plaintext. Farinacci & Weis Expires March 29, 2017 [Page 9] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 There is an open working group item to discuss if the data encapsulation header needs change for encryption or any new applications. This document proposes changes to the existing header so experimentation can continue without making large changes to the data-plane at this time. This document allocates 2 bits of the previously unused 3 flag bits (note the R-bit above is still a reserved flag bit as documented in [RFC6830]) for the KK bits. 9. Procedures for Encryption and Decryption When an ITR, PITR, or RTR encapsulate a packet and have already computed an AEAD-key (detailed in section Section 7) that is associated with a destination RLOC, the following encryption and encapsulation procedures are performed: 1. The encapsulator creates an IV and prepends the IV value to the packet being encapsulated. For GCM and Chacha cipher suites, the IV is incremented for every packet (beginning with a value of 1 in the first packet) and sent to the destination RLOC. For CBC cipher suites, the IV is a new random number for every packet sent to the destination RLOC. For the Chacha cipher suite, the IV is an 8-byte random value that is appended to a 4-byte counter that is incremented for every packet (beginning with a value of 1 in the first packet). 2. Next encrypt with cipher function AES or Chacha20 using the AEAD- key over the packet payload following the AEAD specification referenced in the cipher suite definition. This does not include the IV. The IV must be transmitted as plaintext so the decrypter can use it as input to the decryption cipher. The payload should be padded to an integral number of bytes a block cipher may require. The result of the AEAD operation may contain an ICV, the size of which is defined by the referenced AEAD specification. Note that the AD (i.e. the LISP header exactly as will be prepended in the next step and the IV) must be given to the AEAD encryption function as the "associated data" argument. 3. Prepend the LISP header. The key-id field of the LISP header is set to the key-id value that corresponds to key-pair used for the encryption cipher. 4. Lastly, prepend the UDP header and outer IP header onto the encrypted packet and send packet to destination RLOC. When an ETR, PETR, or RTR receive an encapsulated packet, the following decapsulation and decryption procedures are performed: Farinacci & Weis Expires March 29, 2017 [Page 10] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 1. The outer IP header, UDP header, LISP header, and IV field are stripped from the start of the packet. The LISP header and IV are retained and given to the AEAD decryption operation as the "associated data" argument. 2. The packet is decrypted using the AEAD-key and the IV from the packet. The AEAD-key is obtained from a local-cache associated with the key-id value from the LISP header. The result of the decryption function is a plaintext packet payload if the cipher returned a verified ICV. Otherwise, the packet has been tampered with and is discarded. If the AEAD specification included an ICV, the AEAD decryption function will locate the ICV in the ciphertext and compare it to a version of the ICV that the AEAD decryption function computes. If the computed ICV is different than the ICV located in the ciphertext, then it will be considered tampered. 3. If the packet was not tampered with, the decrypted packet is forwarded to the destination EID. 10. Dynamic Rekeying Since multiple keys can be encoded in both control and data messages, an ITR can encapsulate and encrypt with a specific key while it is negotiating other keys with the same ETR. As soon as an ETR or RTR returns a Map-Reply, it should be prepared to decapsulate and decrypt using the new keys computed with the new Diffie-Hellman parameters received in the Map-Request and returned in the Map-Reply. RLOC-probing can be used to change keys or cipher suites by the ITR at any time. And when an initial Map-Request is sent to populate the ITR's map-cache, the Map-Request flows across the mapping system where a single ETR from the Map-Reply RLOC-set will respond. If the ITR decides to use the other RLOCs in the RLOC-set, it MUST send a Map-Request directly to negotiate security parameters with the ETR. This process may be used to test reachability from an ITR to an ETR initially when a map-cache entry is added for the first time, so an ITR can get both reachability status and keys negotiated with one Map-Request/Map-Reply exchange. A rekeying event is defined to be when an ITR or PITR changes the cipher suite or public-key in the Map-Request. The ETR or RTR compares the cipher suite and public-key it last received from the ITR for the key-id, and if any value has changed, it computes a new public-key and cipher suite requested by the ITR from the Map-Request and returns it in the Map-Reply. Now a new shared secret is computed and can be used for the key-id for encryption by the ITR and decryption by the ETR. When the ITR or PITR starts this process of Farinacci & Weis Expires March 29, 2017 [Page 11] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 negotiating a new key, it must not use the corresponding key-id in encapsulated packets until it receives a Map-Reply from the ETR with the same cipher suite value it expects (the values it sent in a Map- Request). Note when RLOC-probing continues to maintain RLOC reachability and rekeying is not desirable, the ITR or RTR can either not include the Security Type LCAF in the Map-Request or supply the same key material as it received from the last Map-Reply from the ETR or RTR. This approach signals to the ETR or RTR that no rekeying event is requested. 11. Future Work For performance considerations, newer Elliptic-Curve Diffie-Hellman (ECDH) groups can be used as specified in [RFC4492] and [RFC6090] to reduce CPU cycles required to compute shared secret keys. For better security considerations as well as to be able to build faster software implementations, newer approaches to ciphers and authentication methods will be researched and tested. Some examples are Chacha20 and Poly1305 [CHACHA-POLY] [RFC7539]. 12. Security Considerations 12.1. SAAG Support The LISP working group received security advice and guidance from the Security Area Advisory Group (SAAG). The SAAG has been involved early in the design process and their input and reviews have been included in this document. Comments from the SAAG included: 1. Do not use asymmetric ciphers in the data-plane. 2. Consider adding ECDH early in the design. 3. Add cipher suites because ciphers are created more frequently than protocols that use them. 4. Consider the newer AEAD technology so authentication comes with doing encryption. Farinacci & Weis Expires March 29, 2017 [Page 12] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 12.2. LISP-Crypto Security Threats Since ITRs and ETRs participate in key exchange over a public non- secure network, a man-in-the-middle (MITM) could circumvent the key exchange and compromise data-plane confidentiality. This can happen when the MITM is acting as a Map-Replier, provides its own public key so the ITR and the MITM generate a shared secret key among each other. If the MITM is in the data path between the ITR and ETR, it can use the shared secret key to decrypt traffic from the ITR. Since LISP can secure Map-Replies by the authentication process specified in [LISP-SEC], the ITR can detect when a MITM has signed a Map-Reply for an EID-prefix it is not authoritative for. When an ITR determines the signature verification fails, it discards and does not reuse the key exchange parameters, avoids using the ETR for encapsulation, and issues a severe log message to the network administrator. Optionally, the ITR can send RLOC-probes to the compromised RLOC to determine if can reach the authoritative ETR. And when the ITR validates the signature of a Map-Reply, it can begin encrypting and encapsulating packets to the RLOC of ETR. 13. IANA Considerations This document describes a mechanism for encrypting LISP encapsulated packets based on Diffie-Hellman key exchange procedures. During the exchange the devices have to agree on a Cipher Suite used (i.e. the cipher and hash functions used to encrypt/decrypt and to sign/verify packets). The 8-bit Cipher Suite field is reserved for such purpose in the security material section of the Map-Request and Map-Reply messages. This document requests IANA to create and maintain a new registry (as outlined in [RFC5226]) entitled "LISP Crypto Cipher Suite". Initial values for the registry are provided below. Future assignments are to be made on a First Come First Served Basis. Farinacci & Weis Expires March 29, 2017 [Page 13] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 +-----+--------------------------------------------+------------+ |Value| Suite | Definition | +-----+--------------------------------------------+------------+ | 0 | Reserved | Section 6 | +-----+--------------------------------------------+------------+ | 1 | LISP_2048MODP_AES128_CBC_SHA256 | Section 6 | +-----+--------------------------------------------+------------+ | 2 | LISP_EC25519_AES128_CBC_SHA256 | Section 6 | +-----+--------------------------------------------+------------+ | 3 | LISP_2048MODP_AES128_GCM | Section 6 | +-----+--------------------------------------------+------------+ | 4 | LISP_3072MODP_AES128_GCM M-3072 | Section 6 | +-----+--------------------------------------------+------------+ | 5 | LISP_256_EC25519_AES128_GCM | Section 6 | +-----+--------------------------------------------+------------+ | 6 | LISP_256_EC25519_CHACHA20_POLY1305 | Section 6 | +-----+--------------------------------------------+------------+ LISP Crypto Cipher Suites 14. References 14.1. Normative References [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-ietf-lisp-lcaf-13.txt (work in progress). [NIST-SP800-108] "National Institute of Standards and Technology, "Recommendation for Key Derivation Using Pseudorandom Functions NIST SP800-108"", NIST SP 800-108, October 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, DOI 10.17487/RFC2631, June 1999, . [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, DOI 10.17487/RFC3526, May 2003, . Farinacci & Weis Expires March 29, 2017 [Page 14] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, . 14.2. Informative References [AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead- aes-cbc-hmac-sha2-05.txt (work in progress). [CHACHA-POLY] Langley, A., "ChaCha20 and Poly1305 based Cipher Suites for TLS", draft-agl-tls-chacha20poly1305-04 (work in progress). Farinacci & Weis Expires March 29, 2017 [Page 15] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 [CURVE25519] Bernstein, D., "Curve25519: new Diffie-Hellman speed records", Publication http://www.iacr.org/cryptodb/archive/2006/ PKC/3351/3351.pdf. [DH] "Diffie-Hellman key exchange", Wikipedia http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange. [LISP-DDT] Fuller, V., Lewis, D., Ermaagan, V., and A. Jain, "LISP Delegated Database Tree", draft-fuller-lisp-ddt-04 (work in progress). [LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, "LISP-Secuirty (LISP-SEC)", draft-ietf-lisp-sec-10 (work in progress). Appendix A. Acknowledgments The authors would like to thank Dan Harkins, Joel Halpern, Fabio Maino, Ed Lopez, Roger Jorgensen, and Watson Ladd for their interest, suggestions, and discussions about LISP data-plane security. An individual thank you to LISP WG chair Luigi Iannone for shepherding this document as well as contributing to the IANA Considerations section. The authors would like to give a special thank you to Ilari Liusvaara for his extensive commentary and discussion. He has contributed his security expertise to make lisp-crypto as secure as the state of the art in cryptography. In addition, the support and suggestions from the SAAG working group were helpful and appreciative. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] B.1. Changes to draft-ietf-lisp-crypto-08.txt o Posted September 2016. o Addressed comments from Security Directorate reviewer Chris Lonvick. Farinacci & Weis Expires March 29, 2017 [Page 16] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 B.2. Changes to draft-ietf-lisp-crypto-07.txt o Posted September 2016. o Addressed comments from Routing Directorate reviewer Danny McPherson. B.3. Changes to draft-ietf-lisp-crypto-06.txt o Posted June 2016. o Fixed IDnits errors. B.4. Changes to draft-ietf-lisp-crypto-05.txt o Posted June 2016. o Update document which reflects comments Luigi provided as document shepherd. B.5. Changes to draft-ietf-lisp-crypto-04.txt o Posted May 2016. o Update document timer from expiration. B.6. Changes to draft-ietf-lisp-crypto-03.txt o Posted December 2015. o Changed cipher suite allocations. We now have 2 AES-CBC cipher suites for compatibility, 3 AES-GCM cipher suites that are faster ciphers that include AE and a Chacha20-Poly1305 cipher suite which is the fastest but not totally proven/accepted.. o Remove 1024-bit DH keys for key exchange. o Make clear that AES and chacha20 ciphers use AEAD so part of encrytion/decryption does authentication. o Make it more clear that separate key pairs are used in each direction between xTRs. o Indicate that the IV length is different per cipher suite. o Use a counter based IV for every packet for AEAD ciphers. Previously text said to use a random number. But CBC ciphers, use a random number. Farinacci & Weis Expires March 29, 2017 [Page 17] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 o Indicate that key material is sent in network byte order (big endian). o Remove A-bit from Security Type LCAF. No need to do authentication only with the introduction of AEAD ciphers. These ciphers can do authentication. So you get ciphertext for free. o Remove language that refers to "encryption-key" and "integrity- key". Used term "AEAD-key" that is used by the AEAD cipher suites that do encryption and authenticaiton internal to the cipher. B.7. Changes to draft-ietf-lisp-crypto-02.txt o Posted September 2015. o Add cipher suite for Elliptic Curve 25519 DH exchange. o Add cipher suite for Chacha20/Poly1305 ciphers. B.8. Changes to draft-ietf-lisp-crypto-01.txt o Posted May 2015. o Create cipher suites and encode them in the Security LCAF. o Add IV to beginning of packet header and ICV to end of packet. o AEAD procedures are now part of encrpytion process. B.9. Changes to draft-ietf-lisp-crypto-00.txt o Posted January 2015. o Changing draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto- 00. This draft has become a working group document o Add text to indicate the working group may work on a new data encapsulation header format for data-plane encryption. B.10. Changes to draft-farinacci-lisp-crypto-01.txt o Posted July 2014. o Add Group-ID to the encoding format of Key Material in a Security Type LCAF and modify the IANA Considerations so this draft can use key exchange parameters from the IANA registry. Farinacci & Weis Expires March 29, 2017 [Page 18] =0C Internet-Draft LISP Data-Plane Confidentiality September 2016 o Indicate that the R-bit in the Security Type LCAF is not used by lisp-crypto. o Add text to indicate that ETRs/RTRs can negotiate less number of keys from which the ITR/PITR sent in a Map-Request. o Add text explaining how LISP-SEC solves the problem when a man-in- the-middle becomes part of the Map-Request/Map-Reply key exchange process. o Add text indicating that when RLOC-probing is used for RLOC reachability purposes and rekeying is not desired, that the same key exchange parameters should be used so a reallocation of a pubic key does not happen at the ETR. o Add text to indicate that ECDH can be used to reduce CPU requirements for computing shared secret-keys. B.11. Changes to draft-farinacci-lisp-crypto-00.txt o Initial draft posted February 2014. Authors' Addresses Dino Farinacci lispers.net San Jose, California 95120 USA Phone: 408-718-2001 Email: farinacci@gmail.com Brian Weis cisco Systems 170 West Tasman Drive San Jose, California 95124-1706 USA Phone: 408-526-4796 Email: bew@cisco.com Farinacci & Weis Expires March 29, 2017 [Page 19] --Apple-Mail=_DF123D10-5132-4803-B280-F98BC2FA86DA Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_DF123D10-5132-4803-B280-F98BC2FA86DA Content-Disposition: attachment; filename=rfcdiff.html Content-Type: text/html; name="rfcdiff.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-crypto-07.txt - = draft-ietf-lisp-crypto-08.txt=20 =20 =20 =20 =20 =20 =20 = =
< draft-ietf-lisp-crypto-07.txt  =  draft-ietf-lisp-crypto-08.txt >
=
Internet = Engineering Task Force D. Farinacci = Internet Engineering Task Force = D. Farinacci
Internet-Draft = lispers.net Internet-Draft = lispers.net
Intended status: = Experimental B. Weis = Intended status: Experimental = B. Weis
Expires: March = 23, 2017 = cisco Systems Expires: March 29, 2017 = cisco Systems
= September 19, 2016 = September 25, 2016
=
= LISP Data-Plane Confidentiality = LISP Data-Plane Confidentiality
= draft-ietf-lisp-crypto-07 = = draft-ietf-lisp-crypto-08
=
Abstract = Abstract
=
This document = describes a mechanism for encrypting LISP encapsulated This document describes a mechanism for encrypting = LISP encapsulated
traffic. The = design describes how key exchange is achieved using traffic. The design describes how key exchange is = achieved using
existing LISP = control-plane mechanisms as well as how to secure the existing LISP control-plane mechanisms as well as how = to secure the
LISP = data-plane from third-party surveillance attacks. LISP data-plane from third-party surveillance = attacks.
=
Status of This = Memo Status of This Memo
=
=
skipping to = change at = page 1, line 34 =C2=B6 = skipping to change at page 1, line 34 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = http://datatracker.ietf.org/drafts/current/. Drafts is at = http://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on March 23, = 2017. This Internet-Draft will = expire on March 29, 2017.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://trustee.ietf.org/license-info) in = effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 27 =C2=B6 = skipping to change at page 2, line 27 =C2=B6
11. Future = Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 = 11. Future Work . . . . . . . . . . . . . . = . . . . . . . . . . . 12
12. Security = Considerations . . . . . . . . . . . . . . . . . . . 12 = 12. Security Considerations . . . . . . . . = . . . . . . . . . . . 12
12.1. SAAG = Support . . . . . . . . . . . . . . . . . . . . . . 12 = 12.1. SAAG Support . . . . . . . . . . . = . . . . . . . . . . . 12
12.2. = LISP-Crypto Security Threats . . . . . . . . . . . . . . 13 = 12.2. LISP-Crypto Security Threats . . . = . . . . . . . . . . . 13
13. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 13 = 13. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 13
14. References = . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . = . . . . . . 14
14.1. = Normative References . . . . . . . . . . . . . . . . . . 14 = 14.1. Normative References . . . . . . . = . . . . . . . . . . . 14
14.2. = Informative References . . . . . . . . . . . . . . . . . 15 = 14.2. Informative References . . . . . . = . . . . . . . . . . . 15
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 16 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 16
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 16 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 16
B.1. = Changes to draft-ietf-lisp-crypto-07.txt = . . . . . . . . 16 B.1. = Changes to draft-ietf-lisp-crypto-08.txt = . . . . . . . . 16
B.2. = Changes to draft-ietf-lisp-crypto-06.txt = . . . . . . . . 17 B.2. = Changes to draft-ietf-lisp-crypto-07.txt = . . . . . . . . 17
B.3. = Changes to draft-ietf-lisp-crypto-05.txt = . . . . . . . . 17 B.3. = Changes to draft-ietf-lisp-crypto-06.txt = . . . . . . . . 17
B.4. = Changes to draft-ietf-lisp-crypto-04.txt = . . . . . . . . 17 B.4. = Changes to draft-ietf-lisp-crypto-05.txt = . . . . . . . . 17
B.5. = Changes to draft-ietf-lisp-crypto-03.txt = . . . . . . . . 17 B.5. = Changes to draft-ietf-lisp-crypto-04.txt = . . . . . . . . 17
B.6. = Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . 18 = B.6. Changes to draft-ietf-lisp-crypto-03.txt . . . . . . . . = 17
B.7. Changes to draft-ietf-lisp-crypto-01.txt = . . . . . . . . 18 B.7. Changes to = draft-ietf-lisp-crypto-02.txt . . . . . . . . 18
B.8. Changes to draft-ietf-lisp-crypto-00.txt = . . . . . . . . 18 B.8. Changes to draft-ietf-lisp-crypto-01.txt = . . . . . . . . 18
B.9. Changes to = draft-farinacci-lisp-crypto-01.txt . . . . . . 18 B.9. Changes to = draft-ietf-lisp-crypto-00.txt . . . . . . . . 18
B.10. Changes to = draft-farinacci-lisp-crypto-00.txt . . . . . . 19 B.10. Changes to = draft-farinacci-lisp-crypto-01.txt . . . . . . 18
= B.11. = Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 19
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 19
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [RFC6830] defines a set of The Locator/ID Separation Protocol [RFC6830] defines = a set of
functions for = routers to exchange information used to map from non- functions for routers to exchange information used to = map from non-
routable = Endpoint Identifiers (EIDs) to routable Routing Locators = routable Endpoint Identifiers (EIDs) to = routable Routing Locators
(RLOCs). LISP = Ingress Tunnel Routers (ITRs) and Proxy Ingress Tunnel (RLOCs). LISP Ingress Tunnel Routers (ITRs) and = Proxy Ingress Tunnel
Routers = (PITRs) encapsulate packets to Egress Tunnel Routers (ETRs) = Routers (PITRs) encapsulate packets to = Egress Tunnel Routers (ETRs)
and = Reencapsulating Tunnel Routers (RTRs). Packets that arrive at = and Reencapsulating Tunnel Routers (RTRs). = Packets that arrive at
=
skipping to = change at = page 5, line 34 =C2=B6 = skipping to change at page 5, line 35 =C2=B6
| = ... Public Key Material | | ... Public Key Material = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Locator Address ... | | AFI =3D x | Locator = Address ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Cipher Suite = field contains DH Key Exchange and Cipher/Hash Functions = Cipher Suite field contains DH Key Exchange = and Cipher/Hash Functions
=
The 'Key = Count' field encodes the number of {'Key-Length', 'Key- = The 'Key Count' field encodes the number of = {'Key-Length', 'Key-
Material'} = fields included in the encoded LCAF. The maximum number = Material'} fields included in the encoded = LCAF. The maximum number
of keys that = can be encoded are 3, each identified by key-id 1, of keys that can be encoded are 3, each identified by = key-id 1,
followed by = key-id 2, an finally key-id 3. = followed by key-id 2, and finally key-id = 3.
=
The 'R' bit is = not used for this use-case of the Security Type LCAF The 'R' bit is not used for this use-case of the = Security Type LCAF
but is = reserved for [LISP-DDT] security. Therefore, the R bit is but is = reserved for [LISP-DDT] security. Therefore, the R bit SHOULD
transmitted = as 0 and ignored on receipt. be transmitted as 0 and MUST be ignored on receipt.
=
Cipher Suite = 0: Cipher Suite 0:
= Reserved Reserved
=
Cipher Suite = 1: Cipher Suite 1:
= Diffie-Hellman Group: 2048-bit MODP [RFC3526] Diffie-Hellman Group: 2048-bit MODP = [RFC3526]
Encryption: = AES with 128-bit keys in CBC mode [AES-CBC] Encryption: AES with 128-bit keys in CBC mode = [AES-CBC]
Integrity: = Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256 = Integrity: Integrated with [AES-CBC] = AEAD_AES_128_CBC_HMAC_SHA_256
IV length: = 16 bytes IV length: 16 = bytes
=
=
skipping to = change at = page 11, line 29 =C2=B6 = skipping to change at page 11, line = 29 =C2=B6
than the = ICV located in the ciphertext, then it will be than the ICV located in the ciphertext, then it = will be
considered = tampered. considered = tampered.
=
3. If the = packet was not tampered with, the decrypted packet is 3. If the packet was not tampered with, the = decrypted packet is
forwarded = to the destination EID. = forwarded to the destination EID.
=
10. Dynamic = Rekeying 10. Dynamic Rekeying
=
Since multiple = keys can be encoded in both control and data messages, Since multiple keys can be encoded in both control = and data messages,
an ITR can = encapsulate and encrypt with a specific key while it is = an ITR can encapsulate and encrypt with a = specific key while it is
negotiating = other keys with the same ETR. Soon as an = ETR or RTR negotiating other keys = with the same ETR. As soon as an ETR or = RTR
returns a = Map-Reply, it should be prepared to decapsulate and decrypt = returns a Map-Reply, it should be prepared = to decapsulate and decrypt
using the new = keys computed with the new Diffie-Hellman parameters using the new keys computed with the new = Diffie-Hellman parameters
received in = the Map-Request and returned in the Map-Reply. received in the Map-Request and returned in the = Map-Reply.
=
RLOC-probing = can be used to change keys or cipher suites by the ITR RLOC-probing can be used to change keys or cipher = suites by the ITR
at any time. = And when an initial Map-Request is sent to populate the = at any time. And when an initial = Map-Request is sent to populate the
ITR's = map-cache, the Map-Request flows across the mapping system = ITR's map-cache, the Map-Request flows = across the mapping system
where a single = ETR from the Map-Reply RLOC-set will respond. If the where a single ETR from the Map-Reply RLOC-set will = respond. If the
ITR decides to = use the other RLOCs in the RLOC-set, it MUST send a ITR decides to use the other RLOCs in the RLOC-set, = it MUST send a
Map-Request = directly to negotiate security parameters with the ETR. = Map-Request directly to negotiate security = parameters with the ETR.
=
skipping to = change at = page 12, line 38 =C2=B6 = skipping to change at page 12, line = 38 =C2=B6
=
12.1. SAAG = Support 12.1. SAAG Support
=
The LISP = working group received security advice and guidance from the = The LISP working group received security = advice and guidance from the
Security Area = Advisory Group (SAAG). The SAAG has been involved Security Area Advisory Group (SAAG). The SAAG has = been involved
early in the = design process and their input and reviews have been early in the design process and their input and = reviews have been
included in = this document. included in this = document.
=
Comments from = the SAAG included: Comments from = the SAAG included:
=
1. Do not = use assymmetric ciphers in the = data-plane. 1. Do not use = asymmetric ciphers in the data-plane.
=
2. Consider = adding ECDH early in the design. 2. = Consider adding ECDH early in the design.
=
3. Add cipher = suites because ciphers are created more frequently 3. Add cipher suites because ciphers are created = more frequently
than = protocols that use them. than = protocols that use them.
=
4. Consider = the newer AEAD technology so authentication comes with 4. Consider the newer AEAD technology so = authentication comes with
doing = encryption. doing = encryption.
=
12.2. = LISP-Crypto Security Threats 12.2. = LISP-Crypto Security Threats
=
skipping to = change at = page 16, line 45 =C2=B6 = skipping to change at page 16, line = 45 =C2=B6
security = expertise to make lisp-crypto as secure as the state of the = security expertise to make lisp-crypto as = secure as the state of the
art in = cryptography. art in = cryptography.
=
In addition, = the support and suggestions from the SAAG working group = In addition, the support and suggestions = from the SAAG working group
were helpful = and appreciative. were helpful and = appreciative.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-crypto-07.txt B.1. = Changes to draft-ietf-lisp-crypto-08.txt
=
= o Posted September = 2016.
=
= o Addressed = comments from Security Directorate reviewer Chris
= = Lonvick.
=
= B.2. Changes to = draft-ietf-lisp-crypto-07.txt
=
o Posted = September 2016. o Posted September = 2016.
=
o Addressed = comments from Routing Directorate reviewer Danny o Addressed comments from Routing Directorate = reviewer Danny
= McPherson. McPherson.
=
B.2. Changes to = draft-ietf-lisp-crypto-06.txt B.3. Changes to = draft-ietf-lisp-crypto-06.txt
=
o Posted June = 2016. o Posted June 2016.
=
o Fixed = IDnits errors. o Fixed IDnits = errors.
=
B.3. Changes to = draft-ietf-lisp-crypto-05.txt B.4. Changes to = draft-ietf-lisp-crypto-05.txt
=
o Posted June = 2016. o Posted June 2016.
=
o Update = document which reflects comments Luigi provided as document = o Update document which reflects comments = Luigi provided as document
= shepherd. shepherd.
=
B.4. Changes to = draft-ietf-lisp-crypto-04.txt B.5. Changes to = draft-ietf-lisp-crypto-04.txt
=
o Posted May = 2016. o Posted May 2016.
=
o Update = document timer from expiration. o = Update document timer from expiration.
=
B.5. Changes to = draft-ietf-lisp-crypto-03.txt B.6. Changes to = draft-ietf-lisp-crypto-03.txt
=
o Posted = December 2015. o Posted December = 2015.
=
o Changed = cipher suite allocations. We now have 2 AES-CBC cipher = o Changed cipher suite allocations. We now = have 2 AES-CBC cipher
suites for = compatibility, 3 AES-GCM cipher suites that are faster suites for compatibility, 3 AES-GCM cipher suites = that are faster
ciphers = that include AE and a Chacha20-Poly1305 cipher suite which = ciphers that include AE and a = Chacha20-Poly1305 cipher suite which
is the = fastest but not totally proven/accepted.. is the fastest but not totally = proven/accepted..
=
o Remove = 1024-bit DH keys for key exchange. = o Remove 1024-bit DH keys for key exchange.
=
=
skipping to = change at = page 18, line 9 =C2=B6 = skipping to change at page 18, line = 16 =C2=B6
= endian). endian).
=
o Remove = A-bit from Security Type LCAF. No need to do o Remove A-bit from Security Type LCAF. No need to = do
= authentication only with the introduction of AEAD ciphers. = These authentication only with = the introduction of AEAD ciphers. These
ciphers can = do authentication. So you get ciphertext for free. ciphers can do authentication. So you get = ciphertext for free.
=
o Remove = language that refers to "encryption-key" and "integrity- = o Remove language that refers to = "encryption-key" and "integrity-
key". Used = term "AEAD-key" that is used by the AEAD cipher suites key". Used term "AEAD-key" that is used by the = AEAD cipher suites
that do = encryption and authenticaiton internal to the cipher. that do encryption and authenticaiton internal to = the cipher.
=
B.6. Changes to = draft-ietf-lisp-crypto-02.txt B.7. Changes to = draft-ietf-lisp-crypto-02.txt
=
o Posted = September 2015. o Posted September = 2015.
=
o Add cipher = suite for Elliptic Curve 25519 DH exchange. o Add cipher suite for Elliptic Curve 25519 DH = exchange.
=
o Add cipher = suite for Chacha20/Poly1305 ciphers. = o Add cipher suite for Chacha20/Poly1305 ciphers.
=
B.7. Changes to = draft-ietf-lisp-crypto-01.txt B.8. Changes to = draft-ietf-lisp-crypto-01.txt
=
o Posted May = 2015. o Posted May 2015.
=
o Create = cipher suites and encode them in the Security LCAF. o Create cipher suites and encode them in the = Security LCAF.
=
o Add IV to = beginning of packet header and ICV to end of packet. o Add IV to beginning of packet header and ICV to = end of packet.
=
o AEAD = procedures are now part of encrpytion process. o AEAD procedures are now part of encrpytion = process.
=
B.8. Changes to = draft-ietf-lisp-crypto-00.txt B.9. Changes to = draft-ietf-lisp-crypto-00.txt
=
o Posted = January 2015. o Posted January = 2015.
=
o Changing = draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto- = o Changing draft-farinacci-lisp-crypto-01 = to draft-ietf-lisp-crypto-
00. This = draft has become a working group document 00. This draft has become a working group = document
=
o Add text to = indicate the working group may work on a new data o Add text to indicate the working group may work on = a new data
= encapsulation header format for data-plane encryption. encapsulation header format for data-plane = encryption.
=
B.9. Changes to = draft-farinacci-lisp-crypto-01.txt B.10. Changes to = draft-farinacci-lisp-crypto-01.txt
=
o Posted July = 2014. o Posted July 2014.
=
o Add = Group-ID to the encoding format of Key Material in a Security = o Add Group-ID to the encoding format of = Key Material in a Security
Type LCAF = and modify the IANA Considerations so this draft can use = Type LCAF and modify the IANA = Considerations so this draft can use
key = exchange parameters from the IANA registry. key exchange parameters from the IANA = registry.
=
o Indicate = that the R-bit in the Security Type LCAF is not used by = o Indicate that the R-bit in the Security = Type LCAF is not used by
= lisp-crypto. = lisp-crypto.
=
=
skipping to = change at = page 19, line 17 =C2=B6 = skipping to change at page 19, line = 23 =C2=B6
= process. process.
=
o Add text = indicating that when RLOC-probing is used for RLOC o Add text indicating that when RLOC-probing is used = for RLOC
= reachability purposes and rekeying is not desired, that the = same reachability purposes and = rekeying is not desired, that the same
key = exchange parameters should be used so a reallocation of a = key exchange parameters should be used so = a reallocation of a
pubic key = does not happen at the ETR. = pubic key does not happen at the ETR.
=
o Add text to = indicate that ECDH can be used to reduce CPU o Add text to indicate that ECDH can be used to = reduce CPU
= requirements for computing shared secret-keys. requirements for computing shared = secret-keys.
=
B.10. Changes to = draft-farinacci-lisp-crypto-00.txt B.11. Changes to = draft-farinacci-lisp-crypto-00.txt
=
o Initial = draft posted February 2014. o = Initial draft posted February 2014.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
= lispers.net lispers.net
San Jose, = California 95120 San Jose, = California 95120
USA = USA
=
 End of changes. 18 change blocks. 
29 lines changed or = deleted 37 lines changed or = added

This = html diff was produced by rfcdiff 1.45. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_DF123D10-5132-4803-B280-F98BC2FA86DA Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_DF123D10-5132-4803-B280-F98BC2FA86DA-- From nobody Sun Sep 25 14:42:21 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2AE12B03C; Sun, 25 Sep 2016 14:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lK-JYn2RDhh; Sun, 25 Sep 2016 14:42:17 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 553E312B02E; Sun, 25 Sep 2016 14:42:17 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id l25so10360434pfb.1; Sun, 25 Sep 2016 14:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s4grrBslcPTs66nIkj1NTmpRogSah0N4f3zfc4p+UXA=; b=xgvffpE1QlGHWnqFk3CU/v17WhVZqtbv9lSLy67Ym9blrtdGbe213zeqavzk+p4KRI ljOZ4H3S7DJR7vVcn3ntI+yfBsR5yG6Q7nOvsuOe5hwfMuybiRB9e9Yep9jkJCRNZL6E tx17YbHzqQiMNLIw/l3KqhzzXkmobYmiRosFwTw2Ybnv4qWtGX6BLdZFVVEVcEtIZgb1 3KRNJdT4PYvKvIm66cII7YLDE+CnHu6YOTHiTPbciZgfdYeLWOeCyTVntUyKV3P5z2Jx /4wDvlc1AP8q+xYdS7C/Tppekoq/JiGsVf2g1nhuMFx+6f6eFfzayZiTZ/tYGC8dPzgh J0dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s4grrBslcPTs66nIkj1NTmpRogSah0N4f3zfc4p+UXA=; b=SBYNgVvfwN8gVzuJ9mCo1Tssp3Huk7P1R+T6yziixdUJZKKJGKmYz/4Antq2XMo8PY EbAPeJZNu1p3WpaiiL/gjmJNgt9m9CniYWAJP06RleTdIrL5eM2+Z/83MlMRc+hYNHym lKqNbS+a2A2FbZ4x3ceqhMiKyY60iiPH6W6rvsi3KSqOoxdDwF+Y1rrUi1As19yPWZ7N 7AQE1UBX1xqiqmxPkI7R/1WZ8UHJK7XtDk8bU8x3kUEqwtrmUkNmswX731JzXZqb5Nzy 1Fl81Gin9KnJ8kXXgVG1AD1GRHGBcyEqM+5s760D3Om9GDhpchzNlxZmCYFaxBaptlNH uSog== X-Gm-Message-State: AE9vXwNCqBGkEkNMytNcjaYTmfHomB58WQVevfj0cM2P7jOD7YhxfJt70oG3llUsJQJZSg== X-Received: by 10.98.62.194 with SMTP id y63mr32234144pfj.99.1474839736949; Sun, 25 Sep 2016 14:42:16 -0700 (PDT) Received: from ?IPv6:2601:646:8d01:89f0:7958:5e82:524d:c6d5? ([2601:646:8d01:89f0:7958:5e82:524d:c6d5]) by smtp.gmail.com with ESMTPSA id xn11sm25645222pac.38.2016.09.25.14.42.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 25 Sep 2016 14:42:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <28c0b4b6-c4b8-94a2-fc7c-629b66085b50@joelhalpern.com> Date: Sun, 25 Sep 2016 14:42:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <28c0b4b6-c4b8-94a2-fc7c-629b66085b50@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: secdir@ietf.org, The IESG , draft-ietf-lisp-lcaf.all@ietf.org, David Mandelberg Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 21:42:19 -0000 > As I understand it, the multiple representations are deliberate. I do = think we should add a little text in the security considerations section = noting that the representation has to be preserved if the information is = signed. I assume Joel=E2=80=99s comment is relating to this David comment: > There are multiple places in the document where it's possible to = encode > semantically equivalent information in multiple ways, despite the word > "canonical" being in the title of the document. Is there anything that > relies on these addresses being canonical for security purposes? Yes, multiple representations is deliberate. I=E2=80=99ll comment in = more detail to my response to David=E2=80=99s email. > Your comment on the algorithm ID in section 4.7 seems cogent. I will = let the authors respond. I=E2=80=99ll make the Key Sections more clear. Stay tuned for another = response. Dino From nobody Sun Sep 25 15:15:18 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F8112B02F; Sun, 25 Sep 2016 15:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_HTML_ATTACH=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia-qz06TJ_NV; Sun, 25 Sep 2016 15:15:05 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 18CD812B01F; Sun, 25 Sep 2016 15:15:05 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id oz2so56069555pac.2; Sun, 25 Sep 2016 15:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=QLg4BVl5h93mOJhpow6pj7/91TzCZJ/WMt2YMinI5j0=; b=pRZlZsNF/+5i9tldwbUbVFl5PgRxosedOQOsCVRacjX+TYFs1CWdy6gDwlaUSnV/ym Jpiue3tRjeWRC4li4tpVM0jr+AuxScKXC7suGmkTCBSwEastuFSzXirTMStTxDcGL3pS 79IwGmZ9tHFNEsbbbM3oQ5HKBKCsCVrhHlxdGGxeSx6urq58iIp0JpzzB/30FjRxVMF4 i65d9D3v+7Z4ky0Rm93Dh3Bsd66IV4kOsUU2b2KqQZimAqeHBxPpMU8NNqEU9gTxLMK0 YSDglD4s5m+DWCaOA7zQYjlr+2FZuVtDazCC9Tdmiq024IU+mfUfFJFgg/Yenbt9WwqK wNuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=QLg4BVl5h93mOJhpow6pj7/91TzCZJ/WMt2YMinI5j0=; b=jpE3TrQSj/ZoLjr4MxBC+Pu5Fxprma1SyA1sXbT96Yx6GQxKImtnD9BtJiTrvSksH/ 0BiOFWqXgYCEKSqDw/zH5UX7eC8sJBHcjpg7WtICKUdPqi5hSjlbmSYpgBXeBeA/r3bF UlxmnR6gP0Cii/MaIcKwiShZVk+GVcmmX794mBGV+UEsvpam647iu/ipKqNv9DqHQHMy ggJWZc9Kf9FvVlqpfVZfS2Bdjm599frnI/X0E5m5MP53NhAxHALizCISPCli8OtPIVJD l9anR/ItY6cDQF/hIWlVGtnnnEfb1GRWYLUqTWmTH/JarwR1yecyYLVlOIVvSytd5hFq 2CDA== X-Gm-Message-State: AA6/9Rl+ZXwd85YNdYLod/tJPG4jN4q9fsMloAQvq3QWNL36Vmzp4j104b1PJTwVLCCilw== X-Received: by 10.66.227.132 with SMTP id sa4mr11054842pac.176.1474841704696; Sun, 25 Sep 2016 15:15:04 -0700 (PDT) Received: from ?IPv6:2601:646:8d01:89f0:7958:5e82:524d:c6d5? ([2601:646:8d01:89f0:7958:5e82:524d:c6d5]) by smtp.gmail.com with ESMTPSA id p128sm25691595pfg.38.2016.09.25.15.15.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 25 Sep 2016 15:15:03 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_C7271863-ADC2-4658-B35F-55679EB2C47D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> Date: Sun, 25 Sep 2016 15:15:02 -0700 Message-Id: <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> To: David Mandelberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Dino Farinacci , The IESG , draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 22:15:12 -0000 --Apple-Mail=_C7271863-ADC2-4658-B35F-55679EB2C47D Content-Transfer-Encoding: quoted-printable 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. Thanks a lot for your comments. See responses inline. > I found one issue in various parts of the document (described below), > but I'm not sure it's relevant to security. If it is, then I think = this > document is Almost Ready. If not, then I think this document is Ready > With Nits. >=20 > There are multiple places in the document where it's possible to = encode > semantically equivalent information in multiple ways, despite the word > "canonical" being in the title of the document. Is there anything that > relies on these addresses being canonical for security purposes? No not for security purposes. There are multiple ways because we allow = some nesting of information as well as allow for compatibility for older = implementations that can=E2=80=99t parse some AFIs and LCAFs but is = required to parse the AFI-List LCAF type. > Multiple places in the document (sections 4.1, 4.5, and 4.8) specify > mask lengths, but do not specify that the masked out bits MUST be set = to > zero. Hmm, by definition, a mask-length of say 24 if a mask of 0xffffff00. And = in 4.1: IID mask-len: if the AFI is set to 0, then this format is not encoding an extended EID-prefix but rather an instance-ID range where the 'IID mask-len' indicates the number of high-order bits used in the Instance ID field for the range. It is clear that the high-order bits are used that cover the mask-length = and the low-order bits are ignored. Is this not clear to you? Would you = want me to say the high-order bits are added with a mask and the bits = not covered by the mask are set to 0? > Section 4.4: The description of RTR RLOC Address gives two different > ways to encode an address with zero RTRs. Correct. Since a list of RTRs can be encoded, you could have this = encoding (which is valid and needs to be dealt with, hence the = language): afi=3D1, IPv4 RTR afi=3D0, nothing follows afi=3D2, IPv6 RTR The above is a list of 2 RTRs but encoded with 3 entries. > Section 4.10.5: If I understand the compatibility mode correctly, this > explicitly creates a second way to encode a semantically identical = address. Right, if an implementation does not support the Geo-Coordinates LCAF = encoding but wants to encapsulate to the RLOC encoded, it knows how to = skip over the Geo-Coordinates section and get to an AFI encoded address = that it knows how to parse and use. > Section 5.4: There are many different ways to encode equivalent JSON > data here. Maybe, but can you be more clear. I don=E2=80=99t think it is a bug. Do = you? > Section 6 (Security Considerations): There is no discussion of these > addresses being canonical, and what other systems might or might not > rely on these addresses being canonical. In this respect =E2=80=9Ccanonical=E2=80=9D is relative to how LISP = defines to encode both simple AFI encoded addresses or more = complex/flexible addresses that accompany information. > I also have some questions/nits: >=20 > Section 3: Shouldn't the LCAF sort-key of {afi, LCAF-Type} also = include > the RLOC-address or LCAF payload? It cannot because each LCAF-Type has a complex set of attributes. = Sometimes a list of RLOCs. > Section 4.3: Altitude is described as a signed integer, but this > document doesn't specify the encoding. I assume it's two's complement, > but that should probably be made explicit. Yes, I have fixed the text. > Section 4.7: The Key Count description talks about "Key sections," but > doesn't say which fields are part of the key section (and can thus be > repeated). I have a guess which fields are part of the key section, = but > it's not entirely clear. I added some text to clarify this. > Section 4.7: The Key Algorithm description doesn't point to a registry > of valid values or otherwise say how to interpret values in that = field. We have put that in a use-case document. This Security Key LCAF is used = by 2 use-cases. It is used for LISP-DDT and for lisp-crypto. In the = lisp-crypto document we have a registry for cipher suites used. > --=20 > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ See enclosed a -16 txt file and rfcdiff.html file. Thanks again, Dino --Apple-Mail=_C7271863-ADC2-4658-B35F-55679EB2C47D Content-Disposition: attachment; filename=draft-ietf-lisp-lcaf-16.txt Content-Type: text/plain; name="draft-ietf-lisp-lcaf-16.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft lispers.net Intended status: Experimental D. Meyer Expires: March 29, 2017 Brocade J. Snijders NTT Communications September 25, 2016 LISP Canonical Address Format (LCAF) draft-ietf-lisp-lcaf-16 Abstract This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 29, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Farinacci, et al. Expires March 29, 2017 [Page 1] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5 4. LISP Canonical Address Applications . . . . . . . . . . . . . 7 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 9 4.3. Assigning Geo Coordinates to Locator Addresses . . . . . 10 4.4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 12 4.5. Multicast Group Membership Information . . . . . . . . . 14 4.6. Traffic Engineering using Re-encapsulating Tunnels . . . 16 4.7. Storing Security Data in the Mapping Database . . . . . . 17 4.8. Source/Destination 2-Tuple Lookups . . . . . . . . . . . 19 4.9. Replication List Entries for Multicast Forwarding . . . . 21 4.10. Applications for AFI List Type . . . . . . . . . . . . . 22 4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 22 4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 24 4.10.4. Using Recursive LISP Canonical Address Encodings . . 25 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 26 5. Experimental LISP Canonical Address Applications . . . . . . 27 5.1. Convey Application Specific Data . . . . . . . . . . . . 27 5.2. Generic Database Mapping Lookups . . . . . . . . . . . . 28 5.3. PETR Admission Control Functionality . . . . . . . . . . 30 5.4. Data Model Encoding . . . . . . . . . . . . . . . . . . . 31 5.5. Encoding Key/Value Address Pairs . . . . . . . . . . . . 32 5.6. Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . 37 8.2. Informative References . . . . . . . . . . . . . . . . . 38 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40 B.1. Changes to draft-ietf-lisp-lcaf-16.txt . . . . . . . . . 40 B.2. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . 40 B.3. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . 40 B.4. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . 40 B.5. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . 40 Farinacci, et al. Expires March 29, 2017 [Page 2] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.6. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . 40 B.7. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 41 B.8. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . 41 B.9. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . 41 B.10. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . 41 B.11. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 41 B.12. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 41 B.13. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 42 B.14. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 42 B.15. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 42 B.16. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 42 B.17. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction The LISP architecture and protocols [RFC6830] introduces two new numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes Address Family Identifier (AFI), length, and value fields. Currently defined AFIs include IPv4 and IPv6 addresses, which are formatted according to code-points assigned in [AFI] as follows: IPv4 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 29, 2017 [Page 3] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 IPv6 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 2 | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document describes the currently-defined AFIs the LISP protocol uses along with their encodings and introduces the LISP Canonical Address Format (LCAF) that can be used to define the LISP-specific encodings for arbitrary AFI values. 2. Definition of Terms Address Family Identifier (AFI): a term used to describe an address encoding in a packet. Address families are defined for IPv4 and IPv6. See [AFI] and [RFC3232] for details. The reserved AFI value of 0 is used in this specification to indicate an unspecified encoded address where the length of the address is 0 bytes following the 16-bit AFI value of 0. Unspecified Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Farinacci, et al. Expires March 29, 2017 [Page 4] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. 3. LISP Canonical Address Format Encodings IANA has assigned AFI value 16387 (0x4003) to the LISP architecture and protocols. This specification defines the encoding format of the LISP Canonical Address (LCA). This section defines all types for which an initial allocation in the LISP-LCAF registry is requested. See IANA Considerations section for the complete list of such types. The Address Family AFI definitions from [AFI] only allocate code- points for the AFI value itself. The length of the address or entity that follows is not defined and is implied based on conventional experience. When the LISP protocol uses LCAF definitions from this document, the AFI-based address lengths are specified in this document. When new LCAF definitions are defined in other use-case documents, the AFI-based address lengths for any new AFI encoded addresses are specified in those documents. The first 6 bytes of an LISP Canonical Address are followed by a variable number of fields of variable length: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1: this 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Flags: this 8-bit field is for future definition and use. For now, set to zero on transmission and ignored on receipt. Type: this 8-bit field is specific to the LISP Canonical Address formatted encodings, currently allocated values are: Type 0: Null Body Type Farinacci, et al. Expires March 29, 2017 [Page 5] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Type 1: AFI List Type Type 2: Instance ID Type Type 3: AS Number Type Type 4: Application Data Type Type 5: Geo Coordinates Type Type 6: Opaque Key Type Type 7: NAT-Traversal Type Type 8: Nonce Locator Type Type 9: Multicast Info Type Type 10: Explicit Locator Path Type Type 11: Security Key Type Type 12: Source/Dest Key Type Type 13: Replication List Entry Type Type 14: JSON Data Model Type Type 15: Key/Value Address Pair Type Type 16: Encapsulation Format Type Rsvd2: this LCAF Type dependent 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. See specific LCAF Type for specific bits not reserved. Length: this 16-bit field is in units of bytes and covers all of the LISP Canonical Address payload, starting and including the byte after the Length field. When including the AFI, an LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0. The 8 bytes include the AFI, Flags, Type, Reserved, and Length fields. When the AFI is not next to encoded address in a control message, then the encoded address will have a minimum length of 6 bytes when the Length field is 0. The 6 bytes include the Flags, Type, Reserved, and Length fields. [RFC6830] states RLOC records are sorted when encoded in control messages so the locator-set has consistent order across all xTRs for Farinacci, et al. Expires March 29, 2017 [Page 6] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 a given EID. The sort order is based on sort-key {afi, RLOC- address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF- Type}. Therefore, when a locator-set has a mix of AFI records and LCAF records, they are ordered from smallest to largest AFI value. 4. LISP Canonical Address Applications 4.1. Segmentation using LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces must remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI based address unique. Another use for the Instance ID LISP Canonical Address Format is when creating multiple segmented VPNs inside of a LISP site where keeping EID-prefix based subnets is desirable. Farinacci, et al. Expires March 29, 2017 [Page 7] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Instance ID LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 2 | IID mask-len | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IID mask-len: if the AFI is set to 0, then this format is not encoding an extended EID-prefix but rather an instance-ID range where the 'IID mask-len' indicates the number of high-order bits used in the Instance ID field for the range. Length value n: length in bytes of the AFI address that follows the Instance ID field including the AFI field itself. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The reason for the length difference is so that the maximum number of instances supported per mapping system is 2^32 while conserving space in the LISP data header. This comes at the expense of limiting the maximum number of instances per xTR to 2^24. If an xTR is configured with multiple instance-IDs where the value in the high-order 8 bits are the same, then the low-order 24 bits MUST be unique. AFI =3D x: x can be any AFI value from [AFI]. This LISP Canonical Address Type can be used to encode either EID or RLOC addresses. Usage: When used as a lookup key, the EID is regarded as a extended- EID in the mapping system. This encoding is used in EID records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 29, 2017 [Page 8] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.2. Carrying AS Numbers in the Mapping Database When an AS number is stored in the LISP Mapping Database System for either policy or documentation reasons, it can be encoded in a LISP Canonical Address. AS Number LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 3 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the AS Number field including the AFI field itself. AS Number: the 32-bit AS number of the autonomous system that has been assigned either the EID or RLOC that follows. AFI =3D x: x can be any AFI value from [AFI]. The AS Number Canonical Address Type can be used to encode either EID or RLOC addresses. The former is used to describe the LISP-ALT AS number the EID-prefix for the site is being carried for. The latter is used to describe the AS that is carrying RLOC based prefixes in the underlying routing system. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 29, 2017 [Page 9] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.3. Assigning Geo Coordinates to Locator Addresses If an ETR desires to send a Map-Reply describing the Geo Coordinates for each locator in its locator-set, it can use the Geo Coordinate Type to convey physical location information. Coordinates are specified using the WGS-84 (World Geodetic System) reference coordinate system [WGS-84]. Geo Coordinate LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Longitude and Latitude fields including the AFI field itself. N: When set to 1 means North, otherwise South. Latitude Degrees: Valid values range from 0 to 90 degrees above or below the equator (northern or southern hemisphere, respectively). Latitude Minutes: Valid values range from 0 to 59. Latitude Seconds: Valid values range from 0 to 59. E: When set to 1 means East, otherwise West. Longitude Degrees: Value values are from 0 to 180 degrees right or left of the Prime Meridian. Longitude Minutes: Valid values range from 0 to 59. Longitude Seconds: Valid values range from 0 to 59. Farinacci, et al. Expires March 29, 2017 [Page 10] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Altitude: Height relative to sea level in meters. This is a two's complement signed integer meaning that the altitude could be below sea level. A value of 0x7fffffff indicates no Altitude value is encoded. AFI =3D x: x can be any AFI value from [AFI]. The Geo Coordinates Canonical Address Type can be used to encode either EID or RLOC addresses. When used for EID encodings, you can determine the physical location of an EID along with the topological location by observing the locator-set. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 29, 2017 [Page 11] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.4. NAT Traversal Scenarios When a LISP system is conveying global address and mapped port information when traversing through a NAT device, the NAT-Traversal LCAF Type is used. See [I-D.ermagan-lisp-nat-traversal] for details. NAT-Traversal Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 7 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MS UDP Port Number | ETR UDP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Global ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | MS RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Private ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI addresses that follows the UDP Port Number field including the AFI fields themselves. MS UDP Port Number: this is the UDP port number of the Map-Server and is set to 4342. ETR UDP Port Number: this is the port number returned to a LISP system which was copied from the source port from a packet that has flowed through a NAT device. AFI =3D x: x can be any AFI value from [AFI]. Global ETR RLOC Address: this is an address known to be globally unique built by NAT-traversal functionality in a LISP router. MS RLOC Address: this is the address of the Map-Server used in the destination RLOC of a packet that has flowed through a NAT device. Farinacci, et al. Expires March 29, 2017 [Page 12] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Private ETR RLOC Address: this is an address known to be a private address inserted in this LCAF format by a LISP router that resides on the private side of a NAT device. RTR RLOC Address: this is an encapsulation address used by an ITR or PITR which resides behind a NAT device. This address is known to have state in a NAT device so packets can flow from it to the LISP ETR behind the NAT. There can be one or more NAT Reencapsulating Tunnel Router (RTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these set of fields. The number of RTRs encoded is determined by the LCAF length field. When there are no RTRs supplied, the RTR fields can be omitted and reflected by the LCAF length field or an AFI of 0 can be used to indicate zero RTRs encoded. Usage: This encoding can be used in Info-Request and Info-Reply messages. The mapping system does not store this information. The information is used by an xTR and Map-Server to convey private and public address information when traversing NAT and firewall devices. Farinacci, et al. Expires March 29, 2017 [Page 13] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.5. Multicast Group Membership Information Multicast group information can be published in the mapping database. So a lookup on an group address EID can return a replication list of RLOC group addresses or RLOC unicast addresses. The intent of this type of unicast replication is to deliver packets to multiple ETRs at receiver LISP multicast sites. The locator-set encoding for this EID record type can be a list of ETRs when they each register with "Merge Semantics". The encoding can be a typical AFI encoded locator address. When an RTR list is being registered (with multiple levels according to [I-D.coras-lisp-re]), the Replication List Entry LCAF type is used for locator encoding. This LCAF encoding can be used to send broadcast packets to all members of a subnet when each EIDs are away from their home subnet location. Multicast Info Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 9 | Rsvd2 | 8 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source MaskLen| Group MaskLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source/Subnet Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Group Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The use of the Instance-ID in this LCAF type is to associate a multicast forwarding entry for a given VPN. The instance-ID describes the VPN and is registered to the mapping database system as a 3-tuple of (Instance-ID, S-prefix, G-prefix). Source MaskLen: the mask length of the source prefix that follows. Farinacci, et al. Expires March 29, 2017 [Page 14] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Group MaskLen: the mask length of the group prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Source/Subnet Address is the source address or prefix for encoding a (S,G) multicast entry. Group Address is the group address or group prefix for encoding (S,G) or (*,G) multicast entries. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 29, 2017 [Page 15] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.6. Traffic Engineering using Re-encapsulating Tunnels For a given EID lookup into the mapping database, this LCAF format can be returned to provide a list of locators in an explicit re- encapsulation path. See [I-D.farinacci-lisp-te] for details. Explicit Locator Path (ELP) Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 10 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI =3D x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI =3D x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Lookup bit (L): this is the Lookup bit used to indicate to the user of the ELP to not use this address for encapsulation but to look it up in the mapping database system to obtain an encapsulating RLOC address. RLOC-Probe bit (P): this is the RLOC-probe bit which means the Reencap Hop allows RLOC-probe messages to be sent to it. When the R-bit is set to 0, RLOC-probes must not be sent. When a Reencap Hop is an anycast address then multiple physical Reencap Hops are using the same RLOC address. In this case, RLOC-probes are not needed because when the closest RLOC address is not reachable another RLOC address can be reachable. Strict bit (S): this is the strict bit which means the associated Rencap Hop is required to be used. If this bit is 0, the reencapsulator can skip this Reencap Hop and go to the next one in the list. Farinacci, et al. Expires March 29, 2017 [Page 16] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. This encoding does not need to be understood by the mapping system for mapping database lookups since this LCAF type is not a lookup key. 4.7. Storing Security Data in the Mapping Database When a locator in a locator-set has a security key associated with it, this LCAF format will be used to encode key material. See [I-D.ietf-lisp-ddt] for details. Farinacci, et al. Expires March 29, 2017 [Page 17] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Security Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 11 | Rsvd2 | 6 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Length | Key Material ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Key Material | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Locator Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that start with the Key Material field. Key Count: the Key Count field declares the number of Key sections included in this LCAF. A key section is made up the "Key Length" and "Key Material" fields. Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Key Algorithm: the Algorithm field identifies the key's cryptographic algorithm and specifies the format of the Public Key field. Rsvd4: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. R bit: this is the revoke bit and, if set, it specifies that this Key is being Revoked. Key Length: this field determines the length in bytes of the Key Material field. Key Material: the Key Material field stores the key material. The format of the key material stored depends on the Key Algorithm field. AFI =3D x: x can be any AFI value from [AFI].This is the locator address that owns the encoded security key. Farinacci, et al. Expires March 29, 2017 [Page 18] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. 4.8. Source/Destination 2-Tuple Lookups When both a source and destination address of a flow needs consideration for different locator-sets, this 2-tuple key is used in EID fields in LISP control messages. When the Source/Dest key is registered to the mapping database, it can be encoded as a source- prefix and destination-prefix. When the Source/Dest is used as a key for a mapping database lookup the source and destination come from a data packet. Farinacci, et al. Expires March 29, 2017 [Page 19] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Source/Dest Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 12 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source-ML | Dest-ML | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Destination-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. Source-ML: the mask length of the source prefix that follows. Dest-ML: the mask length of the destination prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Refer to [I-D.farinacci-lisp-te] for usage details of this LCAF type. Farinacci, et al. Expires March 29, 2017 [Page 20] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.9. Replication List Entries for Multicast Forwarding The Replication List Entry LCAF type is an encoding for a locator being used for unicast replication according to the specification in [I-D.coras-lisp-re]. This locator encoding is pointed to by a Multicast Info LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs) that are participating in an overlay distribution tree. Each RTR will register its locator address and its configured level in the distribution tree. Replication List Entry Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 13 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2,3,4}: must be set to zero and ignore on receipt. Level Value: this value is associated with the level within the overlay distribution tree hierarchy where the RTR resides. The level numbers are ordered from lowest value being close to the ITR (meaning that ITRs replicate to level-0 RTRs) and higher levels are further downstream on the distribution tree closer to ETRs of multicast receiver sites. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. For efficiency reasons, all RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map- Reply message. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. Farinacci, et al. Expires March 29, 2017 [Page 21] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10. Applications for AFI List Type 4.10.1. Binding IPv4 and IPv6 Addresses When header translation between IPv4 and IPv6 is desirable a LISP Canonical Address can use the AFI List Type to carry a variable number of AFIs in one LCAF AFI. Address Binding LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 4 + 2 + 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | AFI =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI encoded addresses are used. This type of address format can be included in a Map-Request when the address is being used as an EID, but the Mapping Database System lookup destination can use only the IPv4 address. This is so a Mapping Database Service Transport System, such as LISP-ALT [RFC6836], can use the Map-Request destination address to route the control message to the desired LISP site. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. See subsections in this section for specific use cases. Farinacci, et al. Expires March 29, 2017 [Page 22] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.2. Layer-2 VPNs When MAC addresses are stored in the LISP Mapping Database System, the AFI List Type can be used to carry AFI 6. MAC Address LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 6 | Layer-2 MAC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Layer-2 MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 8 when MAC address AFI encoded addresses are used. This address format can be used to connect layer-2 domains together using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. In this use-case, a MAC address is being used as an EID, and the locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or even another MAC address being used as an RLOC. See [I-D.portoles-lisp-eid-mobility] for how layer-2 VPNs operate when doing EID mobility. Farinacci, et al. Expires March 29, 2017 [Page 23] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.3. ASCII Names in the Mapping Database If DNS names or URIs are stored in the LISP Mapping Database System, the AFI List Type can be used to carry an ASCII string where it is delimited by length 'n' of the LCAF Length encoding. ASCII LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 17 | DNS Name or URI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes AFI=3D17 field and the = null-terminated ASCII string (the last byte of 0 is included). Farinacci, et al. Expires March 29, 2017 [Page 24] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.4. Using Recursive LISP Canonical Address Encodings When any combination of above is desirable, the AFI List Type value can be used to carry within the LCAF AFI another LCAF AFI (for example, Application Specific Data see Section 5.1. Recursive LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 8 + 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 12 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 QQS or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 18 when an AFI=3D1 IPv4 address = is included. This format could be used by a Mapping Database Transport System, such as LISP-ALT [RFC6836], where the AFI=3D1 IPv4 address is used as an EID and placed in the Map-Request destination address by the sending LISP system. The ALT system can deliver the Map-Request to the LISP destination site independent of the Application Data Type AFI payload values. When this AFI is processed by the destination LISP site, it can return different locator-sets based on the type of application or level of service that is being requested. Farinacci, et al. Expires March 29, 2017 [Page 25] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.5. Compatibility Mode Use Case A LISP system should use the AFI List Type format when sending to LISP systems that do not support a particular LCAF Type used to encode locators. This allows the receiving system to be able to parse a locator address for encapsulation purposes. The list of AFIs in an AFI List LCAF Type has no semantic ordering and a receiver should parse each AFI element no matter what the ordering. Compatibility Mode Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 8 + 14 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | AFI =3D 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a system does not recognized the Geo Coordinate LCAF Type that is accompanying a locator address, an encoder can include the Geo Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in the list is encoded with a valid AFI value to identify the locator address. A LISP system is required to support the AFI List LCAF Type to use this procedure. It would skip over 10 bytes of the Geo Coordinate LCAF Type to get to the locator address encoding (an IPv4 locator address). A LISP system that does support the Geo Coordinate LCAF Type can support parsing the locator address within the Geo Coordinate LCAF encoding or in the locator encoding that follows in the AFI List LCAF. Farinacci, et al. Expires March 29, 2017 [Page 26] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5. Experimental LISP Canonical Address Applications 5.1. Convey Application Specific Data When a locator-set needs to be conveyed based on the type of application or the Per-Hop Behavior (PHB) of a packet, the Application Data Type can be used. Application Data LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 12 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 TC, or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Application Data fields including the AFI field itself. IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow Label used in an IPv6 header. Local Port/Remote Port Ranges: these fields are from the TCP, UDP, or SCTP transport header. A range can be specified by using a lower value and an upper value. When a single port is encoded, the lower and upper value fields are the same. AFI =3D x: x can be any AFI value from [AFI]. The Application Data Canonical Address Type is used for an EID encoding when an ITR wants a locator-set for a specific application. When used for an RLOC encoding, the ETR is supplying a locator-set for each specific application is has been configured to advertise. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended Farinacci, et al. Expires March 29, 2017 [Page 27] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 EIDs are used in Map-Referral messages. This LCAF type is used as a lookup key to the mapping system that can return a longest-match or exact-match entry. 5.2. Generic Database Mapping Lookups When the LISP Mapping Database system holds information accessed by a generic formatted key (where the key is not the usual IPv4 or IPv6 address), an opaque key may be desirable. Opaque Key LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 6 | Rsvd2 | 3 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Field Num | Key Wildcard Fields | Key . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the type's payload. The value n is the number of bytes that follow this Length field. Farinacci, et al. Expires March 29, 2017 [Page 28] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Key Field Num: the value of this field is the the number of "Key" sub-fields minus 1, the "Key" field can be broken up into. So if this field has a value of 0, there is 1 sub-field in the "Key". The width of the sub-fields are fixed length. So for a key size of 8 bytes, with a Key Field Num of 3, allows 4 sub-fields of 2 bytes each in length. Allowing for a reasonable number of 16 sub- field separators, valid values range from 0 to 15. Key Wildcard Fields: describes which fields in the key are not used as part of the key lookup. This wildcard encoding is a bitfield. Each bit is a don't-care bit for a corresponding field in the key. Bit 0 (the low-order bit) in this bitfield corresponds the first field, the low-order field in the key, bit 1 the second field, and so on. When a bit is set in the bitfield it is a don't-care bit and should not be considered as part of the database lookup. When the entire 16-bits is set to 0, then all bits of the key are used for the database lookup. Key: the variable length key used to do a LISP Database Mapping lookup. The length of the key is the value n (as shown above). Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 29, 2017 [Page 29] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.3. PETR Admission Control Functionality When a public PETR device wants to verify who is encapsulating to it, it can check for a specific nonce value in the LISP encapsulated packet. To convey the nonce to admitted ITRs or PITRs, this LCAF format is used in a Map-Register or Map-Reply locator-record. Nonce Locator Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 8 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the Nonce field including the AFI field itself. Reserved: must be set to zero and ignore on receipt. Nonce: this is a nonce value returned by an ETR in a Map-Reply locator-record to be used by an ITR or PITR when encapsulating to the locator address encoded in the AFI field of this LCAF type. This nonce value is inserted in the nonce field in the LISP header encapsulation. AFI =3D x: x can be any AFI value from [AFI]. Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 29, 2017 [Page 30] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.4. Data Model Encoding This type allows a JSON data model to be encoded either as an EID or RLOC. JSON Data Model Type Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 14 | Rsvd2 |B| 2 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JSON length | JSON binary/text encoding ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Optional Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the fields that follow the "JSON length" field. Rsvd{1,2}: must be set to zero and ignore on receipt. B bit: indicates that the JSON field is binary encoded according to [JSON-BINARY] when the bit is set to 1. Otherwise the encoding is based on text encoding according to [RFC7159]. JSON length: length in octets of the following 'JSON binary/text encoding' field. JSON binary/text encoding field: a variable length field that contains either binary or text encodings. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 29, 2017 [Page 31] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.5. Encoding Key/Value Address Pairs The Key/Value pair is for example useful for attaching attributes to other elements of LISP packets, such as EIDs or RLOCs. When attaching attributes to EIDs or RLOCs, it's necessary to distinguish between the element that should be used as EID or RLOC, and hence as key for lookups, and additional attributes. This is especially the case when the difference cannot be determined from the types of the elements, such as when two IP addresses are being used. Key/Value Pair Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 15 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address as Key ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D y | Address as Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2}: must be set to zero and ignore on receipt. AFI =3D x: x is the "Address as Key" AFI that can have any value = from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map- Reply message. Address as Key: this AFI encoded address will be attached with the attributes encoded in "Address as Value" which follows this field. AFI =3D y: y is the "Address of Value" AFI that can have any value from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Address as Value: this AFI encoded address will be the attribute address that goes along with "Address as Key" which precedes this field. Farinacci, et al. Expires March 29, 2017 [Page 32] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Usage: This is an experimental type where the usage has not been defined yet. 5.6. Multiple Data-Planes Overlays are becoming popular in many parts of the network which have created an explosion of data-plane encapsulation headers. Since the LISP mapping system can hold many types of address formats, it can represent the encapsulation format supported by an RLOC as well. When an encapsulator receives a Map-Reply with an Encapsulation Format LCAF Type encoded in an RLOC-record, it can select an encapsulation format, that it can support, from any of the encapsulation protocols which have the bit set to 1 in this LCAF type. Farinacci, et al. Expires March 29, 2017 [Page 33] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Encapsulation Format Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 16 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved-for-Future-Encapsulations |U|G|N|v|V|l|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1/Rsvd2: must be set to zero and ignored on receipt. Length value n: length in bytes of the AFI address that follows the next 32-bits including the AFI field itself. Reserved-for-Future-Encapsulations: must be set to zero and ignored on receipt. This field will get bits allocated to future encapsulations, as they are created. L: The RLOCs listed in the AFI encoded addresses in the next longword can accept layer3 LISP encapsulation using destination UDP port 4341 [RFC6830]. l: The RLOCs listed in the AFI encoded addresses in the next longword can accept layer2 LISP encapsulation using destination UDP port 8472 [I-D.smith-lisp-layer2]. V: The RLOCs listed in the AFI encoded addresses in the next longword can accept VXLAN encapsulation using destination UDP port 4789 [RFC7348]. v: The RLOCs listed in the AFI encoded addresses in the next longword can accept VXLAN-GPE encapsulation using destination UDP port 4790 [I-D.quinn-vxlan-gpe]. N: The RLOCs listed in the AFI encoded addresses in the next longword can accept NV-GRE encapsulation using IPv4/ IPv6 protocol number 47 [RFC7637]. G: The RLOCs listed in the AFI encoded addresses in the next longword can accept GENEVE encapsulation using destination UDP port 6081 [I-D.gross-geneve]. Farinacci, et al. Expires March 29, 2017 [Page 34] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 U: The RLOCs listed in the AFI encoded addresses in the next longword can accept GUE encapsulation using destination UDP port TBD [I-D.herbert-gue]. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. Farinacci, et al. Expires March 29, 2017 [Page 35] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 6. Security Considerations There are no security considerations for this specification. The security considerations are documented for the protocols that use LISP Canonical Addressing. The use of the Geo-Coordinates LCAF Type may raise physical privacy issues. Care should be taken when configuring the mapping system to use specific policy parameters so geo-location information is not returned gratuitously. 7. IANA Considerations This document defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Such address format is based on a fixed AFI (16387) and a LISP LCAF Type field. The LISP LCAF Type field is an 8-bit field specific to the LISP Canonical Address formatted encodings, for which IANA is to create and maintain a new registry (as outlined in [RFC5226]) entitled "LISP LCAF Type". Initial values for the LISP LCAF Type registry are given below. Future assignments are to be made through expert review with a specification required publication. Assignments consist of a LISP LCAF Type name and its associated value: +-------+------------------------------+------------+ | Value | LISP LCAF Type Name | Definition | +-------+------------------------------+------------+ | 0 | Null Body Type | Section 3 | | 1 | AFI List Type | Section 3 | | 2 | Instance ID Type | Section 3 | | 3 | AS Number Type | Section 3 | | 5 | Geo Coordinates Type | Section 3 | | 7 | NAT-Traversal Type | Section 3 | | 9 | Multicast Info Type | Section 3 | | 10 | Explicit Locator Path Type | Section 3 | | 11 | Security Key Type | Section 3 | | 12 | Source/Dest Key Type | Section 3 | | 13 | Replication List Entry Type | Section 3 | +-------+------------------------------+------------+ Table 1: LISP LCAF Type Initial Values Farinacci, et al. Expires March 29, 2017 [Page 36] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 8. References 8.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, . Farinacci, et al. Expires March 29, 2017 [Page 37] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 8.2. Informative References [AFI] IANA, , "Address Family Identifier (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/numbers.html, Febuary 2007. [I-D.coras-lisp-re] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", draft-coras-lisp-re-08 (work in progress), November 2015. [I-D.ermagan-lisp-nat-traversal] Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, F., and C. White, "NAT traversal for LISP", draft-ermagan- lisp-nat-traversal-11 (work in progress), August 2016. [I-D.farinacci-lisp-te] Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Engineering Use-Cases", draft-farinacci-lisp-te-11 (work in progress), September 2016. [I-D.gross-geneve] Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I., Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve: Generic Network Virtualization Encapsulation", draft- gross-geneve-02 (work in progress), October 2014. [I-D.herbert-gue] Herbert, T., Yong, L., and O. Zia, "Generic UDP Encapsulation", draft-herbert-gue-03 (work in progress), March 2015. [I-D.ietf-lisp-ddt] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- ddt-08 (work in progress), September 2016. [I-D.portoles-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", draft-portoles-lisp-eid- mobility-00 (work in progress), April 2016. Farinacci, et al. Expires March 29, 2017 [Page 38] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 [I-D.quinn-vxlan-gpe] Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, P., and D. Melman, "Generic Protocol Extension for VXLAN", draft-quinn-vxlan-gpe-04 (work in progress), February 2015. [I-D.smith-lisp-layer2] Smith, M., Dutt, D., Farinacci, D., and F. Maino, "Layer 2 (L2) LISP Encapsulation Format", draft-smith-lisp- layer2-03 (work in progress), September 2013. [JSON-BINARY] "Universal Binary JSON Specification", URL http://ubjson.org. [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic System 1984", NIMA TR8350.2, January 2000, . Appendix A. Acknowledgments The authors would like to thank Vince Fuller, Gregg Schudel, Jesper Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for their technical and editorial commentary. The authors would like to thank Victor Moreno for discussions that lead to the definition of the Multicast Info LCAF type. The authors would like to thank Parantap Lahiri and Michael Kowal for discussions that lead to the definition of the Explicit Locator Path (ELP) LCAF type. The authors would like to thank Fabio Maino and Vina Ermagan for discussions that lead to the definition of the Security Key LCAF type. The authors would like to thank Albert Cabellos-Aparicio and Florin Coras for discussions that lead to the definition of the Replication List Entry LCAF type. Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for suggesting new LCAF types. Thanks also goes to Terry Manderson for assistance obtaining a LISP AFI value from IANA. Farinacci, et al. Expires March 29, 2017 [Page 39] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] B.1. Changes to draft-ietf-lisp-lcaf-16.txt o Submitted September 2016. o Addressed comments from Security Directorate reviewer David Mandelberg. B.2. Changes to draft-ietf-lisp-lcaf-15.txt o Submitted September 2016. o Addressed comments from Routing Directorate reviewer Stig Venass. B.3. Changes to draft-ietf-lisp-lcaf-14.txt o Submitted July 2016. o Fix IDnits errors and comments from Luigi Iannone, document shepherd. B.4. Changes to draft-ietf-lisp-lcaf-13.txt o Submitted May 2016. o Explain the Instance-ID LCAF Type is 32-bits in length and the Instance-ID field in the LISP encapsulation header is 24-bits. B.5. Changes to draft-ietf-lisp-lcaf-12.txt o Submitted March 2016. o Updated references and document timer. o Removed the R, J, and L bits from the Multicast Info Type LCAF since working group decided to not go forward with draft- farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp- signal-free-00.txt. B.6. Changes to draft-ietf-lisp-lcaf-11.txt o Submitted September 2015. o Reflecting comments from Prague LISP working group. Farinacci, et al. Expires March 29, 2017 [Page 40] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 o Readying document for a LISP LCAF registry, RFC publication, and for new use-cases that will be defined in the new charter. B.7. Changes to draft-ietf-lisp-lcaf-10.txt o Submitted June 2015. o Fix coauthor Job's contact information. B.8. Changes to draft-ietf-lisp-lcaf-09.txt o Submitted June 2015. o Fix IANA Considerations section to request a registry to allocate and track LCAF Type values. B.9. Changes to draft-ietf-lisp-lcaf-08.txt o Submitted April 2015. o Comment from Florin. The Application Data Type length field has a typo. The field should be labeled "12 + n" and not "8 + n". o Fix length fields in the sections titled "Using Recursive LISP Canonical Address Encodings", "Generic Database Mapping Lookups", and "Data Model Encoding". B.10. Changes to draft-ietf-lisp-lcaf-07.txt o Submitted December 2014. o Add a new LCAF Type called "Encapsulation Format" so decapsulating xTRs can inform encapsulating xTRs what data-plane encapsulations they support. B.11. Changes to draft-ietf-lisp-lcaf-06.txt o Submitted October 2014. o Make it clear how sorted RLOC records are done when LCAFs are used as the RLOC record. B.12. Changes to draft-ietf-lisp-lcaf-05.txt o Submitted May 2014. o Add a length field of the JSON payload that can be used for either binary or text encoding of JSON data. Farinacci, et al. Expires March 29, 2017 [Page 41] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.13. Changes to draft-ietf-lisp-lcaf-04.txt o Submitted January 2014. o Agreement among ELP implementors to have the AFI 16-bit field adjacent to the address. This will make the encoding consistent with all other LCAF type address encodings. B.14. Changes to draft-ietf-lisp-lcaf-03.txt o Submitted September 2013. o Updated references and author's affilations. o Added Instance-ID to the Multicast Info Type so there is relative ease in parsing (S,G) entries within a VPN. o Add port range encodings to the Application Data LCAF Type. o Add a new JSON LCAF Type. o Add Address Key/Value LCAF Type to allow attributes to be attached to an address. B.15. Changes to draft-ietf-lisp-lcaf-02.txt o Submitted March 2013. o Added new LCAF Type "Replication List Entry" to support LISP replication engineering use-cases. o Changed references to new LISP RFCs. B.16. Changes to draft-ietf-lisp-lcaf-01.txt o Submitted January 2013. o Change longitude range from 0-90 to 0-180 in section 4.4. o Added reference to WGS-84 in section 4.4. B.17. Changes to draft-ietf-lisp-lcaf-00.txt o Posted first working group draft August 2012. o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt. Farinacci, et al. Expires March 29, 2017 [Page 42] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Authors' Addresses Dino Farinacci lispers.net San Jose, CA USA Email: farinacci@gmail.com Dave Meyer Brocade San Jose, CA USA Email: dmm@1-4-5.net Job Snijders NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZ NL Email: job@ntt.net Farinacci, et al. Expires March 29, 2017 [Page 43] --Apple-Mail=_C7271863-ADC2-4658-B35F-55679EB2C47D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_C7271863-ADC2-4658-B35F-55679EB2C47D Content-Disposition: attachment; filename=rfcdiff-lcaf.html Content-Type: text/html; name="rfcdiff-lcaf.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-lcaf-15.txt - = draft-ietf-lisp-lcaf-16.txt=20 =20 =20 =20 =20 =20 =20= = =
< draft-ietf-lisp-lcaf-15.txt  =  draft-ietf-lisp-lcaf-16.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = lispers.net Internet-Draft = lispers.net
Intended status: = Experimental D. Meyer = Intended status: Experimental = D. Meyer
Expires: March = 23, 2017 = Brocade Expires: March 29, 2017 = Brocade
= J. Snijders = J. Snijders
= NTT Communications = NTT Communications
= September 19, 2016 = September 25, 2016
=
= LISP Canonical Address Format (LCAF) = LISP Canonical Address Format (LCAF)
= draft-ietf-lisp-lcaf-15 = = draft-ietf-lisp-lcaf-16
=
Abstract = Abstract
=
This draft = defines a canonical address format encoding used in LISP = This draft defines a canonical address = format encoding used in LISP
control = messages and in the encoding of lookup keys for the LISP = control messages and in the encoding of = lookup keys for the LISP
Mapping = Database System. Mapping Database = System.
=
Requirements = Language Requirements Language
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
=
skipping to = change at = page 1, line 41 =C2=B6 = skipping to change at page 1, line 41 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = http://datatracker.ietf.org/drafts/current/. Drafts is at = http://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on March 23, = 2017. This Internet-Draft will = expire on March 29, 2017.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://trustee.ietf.org/license-info) in = effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 47 =C2=B6 = skipping to change at page 2, line 47 =C2=B6
5.4. Data = Model Encoding . . . . . . . . . . . . . . . . . . . 31 = 5.4. Data Model Encoding . . . . . . . . = . . . . . . . . . . . 31
5.5. = Encoding Key/Value Address Pairs . . . . . . . . . . . . 32 = 5.5. Encoding Key/Value Address Pairs . = . . . . . . . . . . . 32
5.6. = Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33 = 5.6. Multiple Data-Planes . . . . . . . = . . . . . . . . . . . 33
6. Security = Considerations . . . . . . . . . . . . . . . . . . . 36 = 6. Security Considerations . . . . . . . . = . . . . . . . . . . . 36
7. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 36 = 7. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 36
8. References = . . . . . . . . . . . . . . . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . = . . . . . . 37
8.1. = Normative References . . . . . . . . . . . . . . . . . . 37 = 8.1. Normative References . . . . . . . = . . . . . . . . . . . 37
8.2. = Informative References . . . . . . . . . . . . . . . . . 38 = 8.2. Informative References . . . . . . = . . . . . . . . . . . 38
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 39 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 39
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 40 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 40
B.1. = Changes to draft-ietf-lisp-lcaf-15.txt . = . . . . . . . . 40 B.1. = Changes to draft-ietf-lisp-lcaf-16.txt . = . . . . . . . . 40
B.2. = Changes to draft-ietf-lisp-lcaf-14.txt . = . . . . . . . . 40 B.2. = Changes to draft-ietf-lisp-lcaf-15.txt . = . . . . . . . . 40
B.3. = Changes to draft-ietf-lisp-lcaf-13.txt . = . . . . . . . . 40 B.3. = Changes to draft-ietf-lisp-lcaf-14.txt . = . . . . . . . . 40
B.4. = Changes to draft-ietf-lisp-lcaf-12.txt . = . . . . . . . . 40 B.4. = Changes to draft-ietf-lisp-lcaf-13.txt . = . . . . . . . . 40
B.5. = Changes to draft-ietf-lisp-lcaf-11.txt . = . . . . . . . . 40 B.5. = Changes to draft-ietf-lisp-lcaf-12.txt . = . . . . . . . . 40
B.6. = Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 41 = B.6. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . = 40
B.7. Changes to draft-ietf-lisp-lcaf-09.txt . = . . . . . . . . 41 B.7. Changes to = draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 41
B.8. Changes to draft-ietf-lisp-lcaf-08.txt . = . . . . . . . . 41 B.8. Changes to draft-ietf-lisp-lcaf-09.txt . = . . . . . . . . 41
B.9. Changes to draft-ietf-lisp-lcaf-07.txt . = . . . . . . . . 41 B.9. Changes to draft-ietf-lisp-lcaf-08.txt . = . . . . . . . . 41
B.10. Changes to draft-ietf-lisp-lcaf-06.txt . = . . . . . . . . 41 B.10. Changes to draft-ietf-lisp-lcaf-07.txt . = . . . . . . . . 41
B.11. Changes to draft-ietf-lisp-lcaf-05.txt . = . . . . . . . . 41 B.11. Changes to draft-ietf-lisp-lcaf-06.txt . = . . . . . . . . 41
B.12. Changes to draft-ietf-lisp-lcaf-04.txt . = . . . . . . . . 42 B.12. Changes to draft-ietf-lisp-lcaf-05.txt . = . . . . . . . . 41
B.13. Changes to draft-ietf-lisp-lcaf-03.txt . = . . . . . . . . 42 B.13. Changes to draft-ietf-lisp-lcaf-04.txt . = . . . . . . . . 42
B.14. Changes to draft-ietf-lisp-lcaf-02.txt . = . . . . . . . . 42 B.14. Changes to draft-ietf-lisp-lcaf-03.txt . = . . . . . . . . 42
B.15. Changes to draft-ietf-lisp-lcaf-01.txt . = . . . . . . . . 42 B.15. Changes to draft-ietf-lisp-lcaf-02.txt . = . . . . . . . . 42
B.16. Changes to draft-ietf-lisp-lcaf-00.txt . = . . . . . . . . 42 B.16. Changes to draft-ietf-lisp-lcaf-01.txt . = . . . . . . . . 42
= B.17. = Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 42
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 43
=
1. = Introduction 1. Introduction
=
The LISP = architecture and protocols [RFC6830] introduces two new = The LISP architecture and protocols = [RFC6830] introduces two new
numbering = spaces, Endpoint Identifiers (EIDs) and Routing Locators = numbering spaces, Endpoint Identifiers = (EIDs) and Routing Locators
(RLOCs). To = provide flexibility for current and future applications, = (RLOCs). To provide flexibility for current = and future applications,
these values = can be encoded in LISP control messages using a general = these values can be encoded in LISP control = messages using a general
syntax that = includes Address Family Identifier (AFI), length, and syntax that includes Address Family Identifier (AFI), = length, and
value = fields. value fields.
=
skipping to = change at = page 11, line 5 =C2=B6 = skipping to change at page 11, line 5 =C2=B6
=
E: When set to = 1 means East, otherwise West. E: = When set to 1 means East, otherwise West.
=
Longitude = Degrees: Value values are from 0 to 180 degrees right or = Longitude Degrees: Value values are from 0 = to 180 degrees right or
left of the = Prime Meridian. left of the = Prime Meridian.
=
Longitude = Minutes: Valid values range from 0 to 59. Longitude Minutes: Valid values range from 0 to = 59.
=
Longitude = Seconds: Valid values range from 0 to 59. Longitude Seconds: Valid values range from 0 to = 59.
=
Altitude: = Height relative to sea level in meters. This is a signed = Altitude: Height relative to sea level in = meters. This is a two's
integer = meaning that the altitude could be below sea level. A complement signed = integer meaning that the altitude could be below
value of = 0x7fffffff indicates no Altitude value is encoded. sea level. A value of 0x7fffffff indicates no = Altitude value is
= encoded.
=
AFI =3D x: x = can be any AFI value from [AFI]. = AFI =3D x: x can be any AFI value from [AFI].
=
The Geo = Coordinates Canonical Address Type can be used to encode = The Geo Coordinates Canonical Address Type = can be used to encode
either EID or = RLOC addresses. When used for EID encodings, you can either EID or RLOC addresses. When used for EID = encodings, you can
determine the = physical location of an EID along with the topological determine the physical location of an EID along with = the topological
location by = observing the locator-set. location = by observing the locator-set.
=
Usage: This = encoding can be used in EID or RLOC records in Map- Usage: This encoding can be used in EID or RLOC = records in Map-
Requests, = Map-Replies, Map-Registers, and Map-Notify messages. When = Requests, Map-Replies, Map-Registers, and = Map-Notify messages. When
=
skipping to = change at = page 18, line 27 =C2=B6 = skipping to change at page 18, line = 27 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = ... Key Material | | ... Key Material = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Locator Address ... | | AFI =3D x | Locator = Address ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that start with the Key Length value n: length in bytes of fields that start = with the Key
Material = field. Material field.
=
Key Count: = the Key Count field declares the number of Key sections = Key Count: the Key Count field declares the = number of Key sections
included = in this LCAF. included in this = LCAF. A key section is made up the "Key = Length"
= and "Key = Material" fields.
=
Rsvd3: this = field is reserved for future use and MUST be transmitted = Rsvd3: this field is reserved for future = use and MUST be transmitted
as 0 and = ignored on receipt. as 0 and = ignored on receipt.
=
Key Algorithm: = the Algorithm field identifies the key's Key Algorithm: the Algorithm field identifies the = key's
= cryptographic algorithm and specifies the format of the Public = Key cryptographic algorithm and = specifies the format of the Public Key
= field. field.
=
Rsvd4: this = field is reserved for future use and MUST be transmitted = Rsvd4: this field is reserved for future = use and MUST be transmitted
as 0 and = ignored on receipt. as 0 and = ignored on receipt.
=
skipping to = change at = page 36, line 14 =C2=B6 = skipping to change at page 36, line = 14 =C2=B6
=
6. Security = Considerations 6. Security = Considerations
=
There are no = security considerations for this specification. The There are no security considerations for this = specification. The
security = considerations are documented for the protocols that use = security considerations are documented for = the protocols that use
LISP Canonical = Addressing. LISP Canonical = Addressing.
=
The use of the = Geo-Coordinates LCAF Type may raise physical privacy The use of the Geo-Coordinates LCAF Type may raise = physical privacy
issues. Care = should be taken when configuring the mapping system to issues. Care should be taken when configuring the = mapping system to
use specific = policy parameters so geo-location information is not use specific policy parameters so geo-location = information is not
returned = gratutiosly. returned gratuitously.
=
7. IANA = Considerations 7. IANA = Considerations
=
This document = defines a canonical address format encoding used in This document defines a canonical address format = encoding used in
LISP control = messages and in the encoding of lookup keys for the LISP = LISP control messages and in the encoding of = lookup keys for the LISP
Mapping = Database System. Such address format is based on a fixed AFI = Mapping Database System. Such address = format is based on a fixed AFI
(16387) and a = LISP LCAF Type field. (16387) and a = LISP LCAF Type field.
=
The LISP LCAF = Type field is an 8-bit field specific to the LISP The LISP LCAF Type field is an 8-bit field specific = to the LISP
Canonical = Address formatted encodings, for which IANA is to create = Canonical Address formatted encodings, for = which IANA is to create
=
skipping to = change at = page 40, line 9 =C2=B6 = skipping to change at page 40, line 9 =C2=B6
Thanks goes to = Michiel Blokzijl and Alberto Rodriguez-Natal for Thanks goes to Michiel Blokzijl and Alberto = Rodriguez-Natal for
suggesting new = LCAF types. suggesting new LCAF = types.
=
Thanks also = goes to Terry Manderson for assistance obtaining a LISP = Thanks also goes to Terry Manderson for = assistance obtaining a LISP
AFI value from = IANA. AFI value from IANA.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-lcaf-15.txt B.1. = Changes to draft-ietf-lisp-lcaf-16.txt
=
= o Submitted = September 2016.
=
= o Addressed = comments from Security Directorate reviewer David
= = Mandelberg.
=
= B.2. Changes to = draft-ietf-lisp-lcaf-15.txt
=
o Submitted = September 2016. o Submitted = September 2016.
=
o Addressed = comments from Routing Directorate reviewer Stig Venass. = o Addressed comments from Routing = Directorate reviewer Stig Venass.
=
B.2. Changes to = draft-ietf-lisp-lcaf-14.txt B.3. Changes to = draft-ietf-lisp-lcaf-14.txt
=
o Submitted = July 2016. o Submitted July = 2016.
=
o Fix IDnits = errors and comments from Luigi Iannone, document o Fix IDnits errors and comments from Luigi Iannone, = document
= shepherd. shepherd.
=
B.3. Changes to = draft-ietf-lisp-lcaf-13.txt B.4. Changes to = draft-ietf-lisp-lcaf-13.txt
=
o Submitted = May 2016. o Submitted May = 2016.
=
o Explain the = Instance-ID LCAF Type is 32-bits in length and the o Explain the Instance-ID LCAF Type is 32-bits in = length and the
Instance-ID = field in the LISP encapsulation header is 24-bits. Instance-ID field in the LISP encapsulation header = is 24-bits.
=
B.4. Changes to = draft-ietf-lisp-lcaf-12.txt B.5. Changes to = draft-ietf-lisp-lcaf-12.txt
=
o Submitted = March 2016. o Submitted March = 2016.
=
o Updated = references and document timer. o = Updated references and document timer.
=
o Removed the = R, J, and L bits from the Multicast Info Type LCAF o Removed the R, J, and L bits from the Multicast = Info Type LCAF
since = working group decided to not go forward with draft- since working group decided to not go forward with = draft-
= farinacci-lisp-mr-signaling-03.txt in favor of draft- = ietf-lisp- = farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp-
= signal-free-00.txt. = signal-free-00.txt.
=
B.5. Changes to = draft-ietf-lisp-lcaf-11.txt B.6. Changes to = draft-ietf-lisp-lcaf-11.txt
=
o Submitted = September 2015. o Submitted = September 2015.
=
o Reflecting = comments from Prague LISP working group. o Reflecting comments from Prague LISP working = group.
=
o Readying = document for a LISP LCAF registry, RFC publication, and = o Readying document for a LISP LCAF = registry, RFC publication, and
for new = use-cases that will be defined in the new charter. for new use-cases that will be defined in the new = charter.
=
B.6. Changes to = draft-ietf-lisp-lcaf-10.txt B.7. Changes to = draft-ietf-lisp-lcaf-10.txt
=
o Submitted = June 2015. o Submitted June = 2015.
=
o Fix = coauthor Job's contact information. = o Fix coauthor Job's contact information.
=
B.7. Changes to = draft-ietf-lisp-lcaf-09.txt B.8. Changes to = draft-ietf-lisp-lcaf-09.txt
=
o Submitted = June 2015. o Submitted June = 2015.
=
o Fix IANA = Considerations section to request a registry to allocate = o Fix IANA Considerations section to = request a registry to allocate
and track = LCAF Type values. and track LCAF = Type values.
=
B.8. Changes to = draft-ietf-lisp-lcaf-08.txt B.9. Changes to = draft-ietf-lisp-lcaf-08.txt
=
o Submitted = April 2015. o Submitted April = 2015.
=
o Comment = from Florin. The Application Data Type length field has a = o Comment from Florin. The Application = Data Type length field has a
typo. The = field should be labeled "12 + n" and not "8 + n". typo. The field should be labeled "12 + n" and = not "8 + n".
=
o Fix length = fields in the sections titled "Using Recursive LISP o Fix length fields in the sections titled "Using = Recursive LISP
Canonical = Address Encodings", "Generic Database Mapping Lookups", = Canonical Address Encodings", "Generic = Database Mapping Lookups",
and "Data = Model Encoding". and "Data Model = Encoding".
=
B.9. Changes to = draft-ietf-lisp-lcaf-07.txt B.10. Changes to = draft-ietf-lisp-lcaf-07.txt
=
o Submitted = December 2014. o Submitted = December 2014.
=
o Add a new = LCAF Type called "Encapsulation Format" so decapsulating = o Add a new LCAF Type called "Encapsulation = Format" so decapsulating
xTRs can = inform encapsulating xTRs what data-plane encapsulations = xTRs can inform encapsulating xTRs what = data-plane encapsulations
they = support. they support.
=
B.10. Changes to = draft-ietf-lisp-lcaf-06.txt B.11. Changes to = draft-ietf-lisp-lcaf-06.txt
=
o Submitted = October 2014. o Submitted October = 2014.
=
o Make it = clear how sorted RLOC records are done when LCAFs are used = o Make it clear how sorted RLOC records are = done when LCAFs are used
as the RLOC = record. as the RLOC = record.
=
B.11. Changes to = draft-ietf-lisp-lcaf-05.txt B.12. Changes to = draft-ietf-lisp-lcaf-05.txt
=
o Submitted = May 2014. o Submitted May = 2014.
=
o Add a = length field of the JSON payload that can be used for either = o Add a length field of the JSON payload = that can be used for either
binary or = text encoding of JSON data. = binary or text encoding of JSON data.
=
B.12. Changes to = draft-ietf-lisp-lcaf-04.txt B.13. Changes to = draft-ietf-lisp-lcaf-04.txt
=
o Submitted = January 2014. o Submitted January = 2014.
=
o Agreement = among ELP implementors to have the AFI 16-bit field o Agreement among ELP implementors to have the AFI = 16-bit field
adjacent to = the address. This will make the encoding consistent adjacent to the address. This will make the = encoding consistent
with all = other LCAF type address encodings. = with all other LCAF type address encodings.
=
B.13. Changes to = draft-ietf-lisp-lcaf-03.txt B.14. Changes to = draft-ietf-lisp-lcaf-03.txt
=
o Submitted = September 2013. o Submitted = September 2013.
=
o Updated = references and author's affilations. = o Updated references and author's affilations.
=
o Added = Instance-ID to the Multicast Info Type so there is relative = o Added Instance-ID to the Multicast Info = Type so there is relative
ease in = parsing (S,G) entries within a VPN. = ease in parsing (S,G) entries within a VPN.
=
o Add port = range encodings to the Application Data LCAF Type. o Add port range encodings to the Application Data = LCAF Type.
=
o Add a new = JSON LCAF Type. o Add a new JSON = LCAF Type.
=
o Add Address = Key/Value LCAF Type to allow attributes to be attached o Add Address Key/Value LCAF Type to allow = attributes to be attached
to an = address. to an address.
=
B.14. Changes to = draft-ietf-lisp-lcaf-02.txt B.15. Changes to = draft-ietf-lisp-lcaf-02.txt
=
o Submitted = March 2013. o Submitted March = 2013.
=
o Added new = LCAF Type "Replication List Entry" to support LISP o Added new LCAF Type "Replication List Entry" to = support LISP
replication = engineering use-cases. = replication engineering use-cases.
=
o Changed = references to new LISP RFCs. o = Changed references to new LISP RFCs.
=
B.15. Changes to = draft-ietf-lisp-lcaf-01.txt B.16. Changes to = draft-ietf-lisp-lcaf-01.txt
=
o Submitted = January 2013. o Submitted January = 2013.
=
o Change = longitude range from 0-90 to 0-180 in section 4.4. o Change longitude range from 0-90 to 0-180 in = section 4.4.
=
o Added = reference to WGS-84 in section 4.4. = o Added reference to WGS-84 in section 4.4.
=
B.16. Changes to = draft-ietf-lisp-lcaf-00.txt B.17. Changes to = draft-ietf-lisp-lcaf-00.txt
=
o Posted = first working group draft August 2012. = o Posted first working group draft August 2012.
=
o This draft = was renamed from draft-farinacci-lisp-lcaf-10.txt. o This draft was renamed from = draft-farinacci-lisp-lcaf-10.txt.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
= lispers.net lispers.net
San Jose, = CA San Jose, CA
 End of changes. 24 change blocks. 
41 lines changed or = deleted 51 lines changed or = added

This = html diff was produced by rfcdiff 1.45. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_C7271863-ADC2-4658-B35F-55679EB2C47D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_C7271863-ADC2-4658-B35F-55679EB2C47D-- From nobody Sun Sep 25 17:49:10 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AFA12B053 for ; Sun, 25 Sep 2016 17:49:04 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LpPs6uQfeJV for ; Sun, 25 Sep 2016 17:49:03 -0700 (PDT) Received: from nm12-vm7.access.bullet.mail.bf1.yahoo.com (nm12-vm7.access.bullet.mail.bf1.yahoo.com [216.109.114.246]) (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 DECBA12B056 for ; Sun, 25 Sep 2016 17:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1474850940; bh=O1yhBOVefen4+xrnevMGGBgY2aKc1SeAjiu0ITuCmmw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=F2MU4U80NWX2T7hNZ6qIz/kb1vphO1wUVq6R1HL2ou6YNjRhZxAU3B8IczsEr0NDJwJcfqvGB5xPmcA6wcARrAKg53iQTdDMFxxuSoFnP1Y1Q1jYdrt8hBOHLmwRnqoJBi55oGajJc8eFXUCXy7av/vFp0vR3NS2dgHuzdJZlhHJT4pC3TLb+rx9vtvimKVMmwZoe7/JMaeWBClN8sY98hvKg5teDZOY1XJUZuUUXShzR7hiSwwQnAoaTKN7YBFv913QM3mC1hhQ12auWD8OzXjzNIcNhujA41j/cy0zHkKbhki1hd57HnmY6VMfJxPluiAS+xg+vD3sdoLV2wTaxg== Received: from [66.196.81.162] by nm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Sep 2016 00:49:00 -0000 Received: from [98.138.226.243] by tm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Sep 2016 00:49:00 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 26 Sep 2016 00:49:00 -0000 X-Yahoo-Newman-Id: 213112.98160.bm@smtp114.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: U2Z162AVM1kRoWkesWE9dGOH3Evx_8IfHBMBCNcRNXvLbdI ZFK0_uKu2PYSOTI6x01xJq0QYyEni1wpjQ4Q3SRf8kc0bp5wYkDjeZke6HzN ndwQg8kJ3XnjGPDjE0yInpVfDx6ItqABt2WIVk9kPoEZN1IWU9JJkcqoh2C. uFKaTKlACYhtWYQ5rM48FmV29q74tbDB7WW_ox1qIXJepNBDSOHDaDE510jD G5SqXQq8UPjHofItjFXdNquv4V9k3GQS7gwY.4GEGqJJiJ70EgAKQaN2hhvV kFrXX.wzokz83F76K7F54mWFjxIJWfAZSeL7IjO2KLSZkVJg91WDGnz.epcL iETTucaw9IXUwPha7IkOE8uDMOJTh.JezVnixdyZjk5yYnibQHOhvjL7hcJp MKYmkdzj.AC_93inS5.ponXsRwoImIn7bURwlTgL60dIX3uc4oN0Zyrs7i3w NlVTizWTRiEW4AugKzMZdCQgadZjKuvTty.6e6wUiJ2ZtAKScued8DEsdt3e 7_6anwC2CRaW_tCdZrbgAGiJIIJfN4Q20BJOvt3UZGefRzEthKkn3zLSlH52 zFArCmbmBZJE- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.153] (209-6-88-55.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.88.55]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 759AB1C6033; Sun, 25 Sep 2016 20:48:58 -0400 (EDT) To: Dino Farinacci References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> From: David Mandelberg Message-ID: Date: Sun, 25 Sep 2016 20:48:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2P0UCBpmuk3ITo188tCGwrlkK07SSfPuN" Archived-At: Cc: The IESG , draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 00:49:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2P0UCBpmuk3ITo188tCGwrlkK07SSfPuN Content-Type: multipart/mixed; boundary="PPQ8q2NiWOGRiwconsBtQALRDoQVWf3g1" From: David Mandelberg To: Dino Farinacci Cc: The IESG , secdir@ietf.org, draft-ietf-lisp-lcaf.all@ietf.org Message-ID: Subject: Re: secdir review of draft-ietf-lisp-lcaf-15 References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> In-Reply-To: <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> --PPQ8q2NiWOGRiwconsBtQALRDoQVWf3g1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09/25/2016 06:15 PM, Dino Farinacci wrote: >> I found one issue in various parts of the document (described below), >> but I'm not sure it's relevant to security. If it is, then I think thi= s >> document is Almost Ready. If not, then I think this document is Ready >> With Nits. >> >> There are multiple places in the document where it's possible to encod= e >> semantically equivalent information in multiple ways, despite the word= >> "canonical" being in the title of the document. Is there anything that= >> relies on these addresses being canonical for security purposes? >=20 > No not for security purposes. There are multiple ways because we allow = some nesting of information as well as allow for compatibility for older = implementations that can=92t parse some AFIs and LCAFs but is required to= parse the AFI-List LCAF type. Ok, then I think it needs to be made clear in the security considerations that this format cannot be relied on to have no more than one representation for the same information. IESG: This means that I think this document is Ready With Nits. >> Multiple places in the document (sections 4.1, 4.5, and 4.8) specify >> mask lengths, but do not specify that the masked out bits MUST be set = to >> zero. >=20 > Hmm, by definition, a mask-length of say 24 if a mask of 0xffffff00. An= d in 4.1: >=20 > IID mask-len: if the AFI is set to 0, then this format is not > encoding an extended EID-prefix but rather an instance-ID range > where the 'IID mask-len' indicates the number of high-order bits > used in the Instance ID field for the range. >=20 > It is clear that the high-order bits are used that cover the mask-lengt= h and the low-order bits are ignored. Is this not clear to you? That part is clear to me. I just meant that the document as written appears to allow 1.2.3.4/24 to be equivalent to 1.2.3.7/24. If the format were going to be canonical, then all masked bits (the last octet in this example) would need to be set to a well-known value (so, 1.2.3.0/24) instead of allowed to be anything. > Would you want me to say the high-order bits are added with a mask and = the bits not covered by the mask are set to 0? If the format can't be relied on to be canonical, then my point is irrelevant. >> Section 5.4: There are many different ways to encode equivalent JSON >> data here. >=20 > Maybe, but can you be more clear. "{}" and "{ }" (note the space) are equivalent in JSON, but not identical when compared byte-by-byte. > I don=92t think it is a bug. Do you? As long as nobody relies on these to be canonical, it's not a bug. >> Section 6 (Security Considerations): There is no discussion of these >> addresses being canonical, and what other systems might or might not >> rely on these addresses being canonical. >=20 > In this respect =93canonical=94 is relative to how LISP defines to enco= de both simple AFI encoded addresses or more complex/flexible addresses t= hat accompany information. Ok. I interpreted canonical to be a security property of the addresses, i.e., that if two addresses are not bytewise equal, then they must not have the same meaning. If that's not what you meant by canonical, then I think the security considerations should say that, so that nobody tries to rely on that property in the future. >> Section 4.7: The Key Count description talks about "Key sections," but= >> doesn't say which fields are part of the key section (and can thus be >> repeated). I have a guess which fields are part of the key section, bu= t >> it's not entirely clear. >=20 > I added some text to clarify this. Thank you. The fields included in a key section were not the ones I guessed, so the clarification was helpful. (Before your clarification, I expected it to be everything from Rsvd3 through Key Material.) >> Section 4.7: The Key Algorithm description doesn't point to a registry= >> of valid values or otherwise say how to interpret values in that field= =2E >=20 > We have put that in a use-case document. This Security Key LCAF is used= by 2 use-cases. It is used for LISP-DDT and for lisp-crypto. In the lisp= -crypto document we have a registry for cipher suites used. Should this document reference one or both of those documents? --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --PPQ8q2NiWOGRiwconsBtQALRDoQVWf3g1-- --2P0UCBpmuk3ITo188tCGwrlkK07SSfPuN 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 iEYEARECAAYFAlfocHYACgkQRKlmUHCg4sCEUQCfRvfYWty7Ug8aE+vKiOAllcf6 wScAoIag77kOl8jTP/ZobVoWz0c4uFxp =XvLt -----END PGP SIGNATURE----- --2P0UCBpmuk3ITo188tCGwrlkK07SSfPuN-- From nobody Sun Sep 25 18:27:41 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A0A12B056; Sun, 25 Sep 2016 18:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pVPzaIQ-3Kv; Sun, 25 Sep 2016 18:27:32 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 4BCA312B05B; Sun, 25 Sep 2016 18:27:32 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id l25so11543472pfb.1; Sun, 25 Sep 2016 18:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Vy8rgSjS2ezXrBIsT+Pny5wXXOKdsmN+E+sY/S9pI4k=; b=visI3TDy8iVHmoXRllNV9xZZV0aVmebei95YYu9pSGArS4Lj6U9G+9o3qFCn1rj+tJ XP88n/uHD/EmEFrfkh/yH7QzHhG39wcFpvH54z0fb35G74gAwk90SAZFt/E/BFGZrJxa jxcHNP8zEEgL+RU33sbOeHgwadztPZ+NcddICOeDojAfZAyFx9jrwrKyx8lDyrBL5nMk pldnTXe8kfMAASjkPAxD8TL71aXdeEGYrvGVwH5nwX3wKcOiNbXS+MnehQ6U3A6odRJ5 VNuzI0zo3dGOtJ2CPenBSDNYUQsAke1axvBHZtjvfW9ad47178s3YpzKxNGRLfWn0fab qlSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Vy8rgSjS2ezXrBIsT+Pny5wXXOKdsmN+E+sY/S9pI4k=; b=VIRsl4n/lFcIe7I7fsa1dCHYUus6YDH10a5IuoNFytLww7IRPomUmFnYhbk7Z0kNZI Ttx8RDOLiAgbaDfFZK/PUMmAOraCqTVSe8Gbmz3BZqaqYOHREhRL4aBrJu4YM3OUgYRV lJURNLjlVYyhiLMCLOHgW6hy8k1DMNL2Nworl352wCeQ5DZbWqE3dPmsFry7paSJ8B5L A4haKLZA7j/tdKl+js1BnxTpHOeIiXrO62tb08MxL8ox1Tm2n0PudsiIsj2J1Pgg6o/W CBw9Wj9lPb6veOrojxxEnAggStAHee843bNvmlBl3WMdknKn0Qe+Jww5dQgQ1U9NoY11 Vmkw== X-Gm-Message-State: AE9vXwOGjqjbjzTifKctOoWfduHDdPQIl6y6YO0gS6KKnkGB/WLWXG4POroGMeKRr3GCBA== X-Received: by 10.98.0.69 with SMTP id 66mr33490663pfa.140.1474853251794; Sun, 25 Sep 2016 18:27:31 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:d15c:ae35:aaa4:7fa4]) by smtp.googlemail.com with ESMTPSA id xv9sm26100160pab.36.2016.09.25.18.27.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Sep 2016 18:27:31 -0700 (PDT) To: Dino Farinacci References: <57E68FB7.10408@gmail.com> <57E690AD.2030207@gmail.com> <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com> From: Chris Lonvick Message-ID: <57E87980.2050209@gmail.com> Date: Sun, 25 Sep 2016 20:27:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-lisp-crypto.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 01:27:34 -0000 Hi Dino, On 9/25/16 4:37 PM, Dino Farinacci wrote: >>> I don't follow LISP so I'm not sure if there is an actual mechanism for a device receiving a map request packet to decline an offered cipher suite. If there is, I didn't see it explained in the > Yes, there is. If the Map-Reply this is returned contains no Security LCAF that means to the ITR that it either needs to go unencrypted encapsulating packets to the ETR or try another cipher text. > >>> >>draft. You should address this in a future draft. This will be needed for when new cipher suites are > Understand the need. We intentionally wanted to support this. > >>> >>added and a receiving device does not have the capability to handle the new cipher suite, or the case where an old cipher suite has been administratively disabled; like if it's been compromised and shouldn't be used. There are several ways to do this. > We have this in section x of the draft. Is it not sufficient? > > If an ITR, PITR, or RTR sends a Map-Request with the Security Type > LCAF included and the ETR or RTR does not want to have encapsulated > traffic encrypted, they will return a Map-Reply with no RLOC records > encoded with the Security Type LCAF. This signals to the ITR, PITR > or RTR not to encrypt traffic (it cannot encrypt traffic anyways > since no ETR public-key was returned). > That text just says that if the cipher suite is declined then there will be no encryption. I was interpreting that to mean that the receiver just isn't going to accept any attempt at encryption. If it's just meant to be for that particular cipher suit then you'll need to add a line to that paragraph to say that the ITR, PITR, or RTR can attempt a different cipher suite if it is administratively configured to do so. However, that could get to be very inefficient if the ITR has to make 6 attempts before understanding that the ETR just isn't going to accept any encryption request - if it's so configured, or if it just doesn't support the feature whatsoever. So even if you allow the sender to make offer after offer, it would still be a good idea to have a way for the receiver to entirely decline encrypting packets from the sender. But, with all that being said, I'm figuring that we're getting outside the intent of your experimental specification. When you do get around to getting this onto a standards track, then you should make some decisions around how to convey capabilities between the sender and receiver so they can quickly and efficiently figure out what's going to work, or if it's just not, rather than making one offer after another. TLS and SSH have ways for a sender to offer a list from which the receiver can choose, if you're looking for examples. Another way is for the sender to proffer a version number which is associated with a select group of capabilities. From that, the receiver can make a choice, or efficiently decline all. Best regards, Chris From nobody Sun Sep 25 20:12:09 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AE912B064; Sun, 25 Sep 2016 20:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.838 X-Spam-Level: X-Spam-Status: No, score=-16.838 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hilbgC7U0OgR; Sun, 25 Sep 2016 20:11:58 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7C31288B8; Sun, 25 Sep 2016 20:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3829; q=dns/txt; s=iport; t=1474859518; x=1476069118; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4LDDTJNm3MqY9ki7QBtdVjMa65uRHjrlcEJxka7Zf6k=; b=NeHnnt2dzl3p9MBV1cO9DYczeN/tZnNz2DBDA2bFGSfDeMym8t5gZzu5 Y7Nnxj75yJfi9nQ1JPz1lypJfCLNxd5tWtaGgxYYC5YPKob7PopPtnMdy 8jmZEtJvoJ3jA3gACx+0lMLMDOt2klJBIJKeIUH5LHpHDKu3CWAKls+po A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAQDdkOhX/4MNJK1aAxoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYM7AQEBAQEegVMHjSyfBYo4gg+CBIYeAoFCOBQBAgEBAQEBAQFeJ4R?= =?us-ascii?q?hAQEBAwF5BQsCAQgYLiERJQIEDgWIMQMPCLotDYNCAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAR6IM4JYgkeBTxEBHCEmgmiCLwWZQTUBjG+CeI9riFyED4N7AR42gxkcgVB?= =?us-ascii?q?yhVyBIH8BAQE?= X-IronPort-AV: E=Sophos;i="5.30,397,1470700800"; d="scan'208";a="328096644" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Sep 2016 03:11:57 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u8Q3BvYj002237 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Sep 2016 03:11:57 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 25 Sep 2016 23:11:56 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Sun, 25 Sep 2016 23:11:56 -0400 From: "Brian Weis (bew)" To: Chris Lonvick Thread-Topic: SECDIR review of draft-ietf-lisp-crypto-07 Thread-Index: AQHSFnHPRAAUzKZlKEOoLcVzAMnuDqCLAEWAgABALgCAAB0ygA== Date: Mon, 26 Sep 2016 03:11:56 +0000 Message-ID: <7345DDFF-0D4F-4F47-87D1-56459ED94D2A@cisco.com> References: <57E68FB7.10408@gmail.com> <57E690AD.2030207@gmail.com> <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com> <57E87980.2050209@gmail.com> In-Reply-To: <57E87980.2050209@gmail.com> 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.19.191.163] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-lisp-crypto.all@ietf.org" , "iesg@ietf.org" , Dino Farinacci , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 03:12:00 -0000 Hi Chris,=20 Thanks for the review. I=92ve added one comment below. > On Sep 25, 2016, at 6:27 PM, Chris Lonvick wrote= : >=20 > Hi Dino, >=20 > On 9/25/16 4:37 PM, Dino Farinacci wrote: >>>> I don't follow LISP so I'm not sure if there is an actual mechanism fo= r a device receiving a map request packet to decline an offered cipher suit= e. If there is, I didn't see it explained in the >> Yes, there is. If the Map-Reply this is returned contains no Security LC= AF that means to the ITR that it either needs to go unencrypted encapsulati= ng packets to the ETR or try another cipher text. >>=20 >>>> >>draft. You should address this in a future draft. This will be neede= d for when new cipher suites are >> Understand the need. We intentionally wanted to support this. >>=20 >>>> >>added and a receiving device does not have the capability to handle = the new cipher suite, or the case where an old cipher suite has been admini= stratively disabled; like if it's been compromised and shouldn't be used. T= here are several ways to do this. >> We have this in section x of the draft. Is it not sufficient? >>=20 >> If an ITR, PITR, or RTR sends a Map-Request with the Security Type >> LCAF included and the ETR or RTR does not want to have encapsulated >> traffic encrypted, they will return a Map-Reply with no RLOC records >> encoded with the Security Type LCAF. This signals to the ITR, PITR >> or RTR not to encrypt traffic (it cannot encrypt traffic anyways >> since no ETR public-key was returned). >>=20 > That text just says that if the cipher suite is declined then there will = be no encryption. I was interpreting that to mean that the receiver just is= n't going to accept any attempt at encryption. If it's just meant to be for= that particular cipher suit then you'll need to add a line to that paragra= ph to say that the ITR, PITR, or RTR can attempt a different cipher suite i= f it is administratively configured to do so. However, that could get to be= very inefficient if the ITR has to make 6 attempts before understanding th= at the ETR just isn't going to accept any encryption request - if it's so c= onfigured, or if it just doesn't support the feature whatsoever. So even if= you allow the sender to make offer after offer, it would still be a good i= dea to have a way for the receiver to entirely decline encrypting packets f= rom the sender. >=20 > But, with all that being said, I'm figuring that we're getting outside th= e intent of your experimental specification. When you do get around to gett= ing this onto a standards track, then you should make some decisions around= how to convey capabilities between the sender and receiver so they can qui= ckly and efficiently figure out what's going to work, or if it's just not, = rather than making one offer after another. TLS and SSH have ways for a sen= der to offer a list from which the receiver can choose, if you're looking f= or examples. Another way is for the sender to proffer a version number whic= h is associated with a select group of capabilities. From that, the receive= r can make a choice, or efficiently decline all. Thanks for the suggestions. In this effort we were intentionally avoiding t= he complexities and added security analysis requirements of a multiple roun= d-trip method capabilities negotiation such as TLS. But maybe a capabilitie= s declaration more along the lines of the version number you suggest might = be appropriate. I agree that at such time as the protocol was prepared for= standards-track that this would be important to add. Thanks, Brian >=20 > Best regards, > Chris --=20 Brian Weis Security, CSG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From nobody Sun Sep 25 22:15:03 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726D512B059; Sun, 25 Sep 2016 22:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pb_nNQN097E; Sun, 25 Sep 2016 22:14:56 -0700 (PDT) Received: from COL004-OMC4S6.hotmail.com (col004-omc4s6.hotmail.com [65.55.34.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21968128B38; Sun, 25 Sep 2016 22:14:56 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.55.34.199]) by COL004-OMC4S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 25 Sep 2016 22:14:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mnCOhBAH+1k25JRSg1ZESq9URlIagrJGo4+wbMXlMLE=; b=nqo/N3SnsQoIfuvslE8Mss94p7YFBBXqJGxnzs6V0xEkwCxV/MD4ZnFUStipM9Oas+rCIYajz57fxAgSk604hqrzfOXXi65nNC3ROdT+QX6VPbdlhCKqej1h/+sic9aQ0GENgdvqeCbXYwtHbUD6KCqsprgR8+LEmPxn8AFi8qoPmbmB+myXKS7Xsl0OcdrDhmx24qsxYPFN6EmTlk0gnEXTZx6fScnAhNfmZvXwpFuS9weENp/KVlMycKyC/d5f6aCKqz2cRoipkLgxh5v6a80rrZ1i4Lq04bOcC3fssIcrFmBjVulKbmmKEqgRWNE36g5jN2EoZnsKU4xs5fznVQ== Received: from CY1NAM02FT064.eop-nam02.prod.protection.outlook.com (10.152.74.57) by CY1NAM02HT022.eop-nam02.prod.protection.outlook.com (10.152.74.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5; Mon, 26 Sep 2016 05:14:48 +0000 Received: from CY4PR17MB0997.namprd17.prod.outlook.com (10.152.74.56) by CY1NAM02FT064.mail.protection.outlook.com (10.152.74.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5 via Frontend Transport; Mon, 26 Sep 2016 05:14:48 +0000 Received: from CY4PR17MB0997.namprd17.prod.outlook.com ([10.173.181.7]) by CY4PR17MB0997.namprd17.prod.outlook.com ([10.173.181.7]) with mapi id 15.01.0639.011; Mon, 26 Sep 2016 05:14:48 +0000 From: Charlie Kaufman To: 'The IESG' , "secdir@ietf.org" , "draft-ietf-6lo-paging-dispatch.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-6lo-paging-dispatch-04 Thread-Index: AQHSF7R4dsv6Z6ms7Eu/YZTvBwfhxQ== Date: Mon, 26 Sep 2016 05:14:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.74.56) smtp.mailfrom=outlook.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=outlook.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 10.152.74.56 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [JRGzAgFZ6Wkd3LoOqrpBzvRKlx98X1sT] x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; CY1NAM02HT022; 6:q3/csBV5i1d6anqWY9l7X0iDNWuvHkq3bZJeFLSRXyEJxkTSZZnIXy4zyO/U+WmsFz19gp8MXfC1FdSCqO5Xiox/Q48mB+Sjl2TpBJ4IXYRJz+y5LCg5jem2c290V6Y46+yWXTPCnEQvHCy2VecXPElsrycCztG6u+JHEb/NuzLORlu/FjAf5k2JCiI5+n0gWp6w3/sO/g4pXsdfIghfF4bL8J7AAF0H/EmymasxtVJHiMsDFcJWnJ19ZiQ9m0qliTfuwJerRdLsqkYfEKuJ+QJNtgF1C9ytltcKoLmQzMo=; 5:8QtbypzCZQY/OEZCch7uuc/iqlzHdAvALSIJDZDKOcxJM5MDWC9p3A55s2TgJ9lt81D1/hR1dZk/iJ16rH/v7CPVFftuHa7YCV6ejZW4hxD+DPv1Fn5GFwvHi8847c7q+p7TfGHS8lmZY6JYmYJR+g==; 24:SB9tfMXQBISTUN8NtOdmQhe9pbGr4vcC2PqaKyOx5PrK4nLUmn6cIWyNXXNouUyt+93TX7tRAbhPNfLN71fTpbmEKdgs67sbpYtKGsIdjUQ=; 7:XXpdmXkYYRyomnrpEUP9kW38v+cVjSHHCWX/7otnYW4cZTvUgHixBfnQsuPdDGXoNy321rqOM5H/gjzZsOVRMtV37eJZglu/1xv2g+y7XlirGHWEtrSPQmAfwuriWscDQxgBZxvWgAlUcEzFjBDiIbbYrXSHv/2/g15dQjIVql8xIglpAPbACa25yB0VTBINB1Ktw0ws3ztMeM/aAtUmal8REt4bJ8c5kuR3EhRahnnFbuGqGaIbzIiFhlcNCg7qRAiAdn/BTjOe8ZDffS0VpPGAz7wjVe9K471TwxvnG15YbdG9N96CwD9ulN2sPOl2 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1NAM02HT022; H:CY4PR17MB0997.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 45b2878a-2893-480f-b7bc-08d3e5cc0984 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1601125047); SRVR:CY1NAM02HT022; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:CY1NAM02HT022; BCL:0; PCL:0; RULEID:; SRVR:CY1NAM02HT022; x-forefront-prvs: 00770C4423 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR17MB0997FAD792FC518176EB15A1DFCD0CY4PR17MB0997namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2016 05:14:48.4773 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT022 X-OriginalArrivalTime: 26 Sep 2016 05:14:55.0879 (UTC) FILETIME=[EB715170:01D217B4] Archived-At: Subject: [secdir] Secdir review of draft-ietf-6lo-paging-dispatch-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 05:14:58 -0000 --_000_CY4PR17MB0997FAD792FC518176EB15A1DFCD0CY4PR17MB0997namp_ 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 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 document is: Ready This document assigns some code points in an IANA maintained table for the = purpose of more efficiently compressing messages sent over Low Power and Lo= ssy Networks. It does not define any new compression formats; it just alloc= ates code points for future use when those compression formats are defined.= As such, there really are no security considerations. The document contain= s a security considerations section that refers users to two related RFCs. Sent from Outlook --_000_CY4PR17MB0997FAD792FC518176EB15A1DFCD0CY4PR17MB0997namp_ 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 ongo= ing 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.

This document is: Ready


This document assigns some code points in an IANA maintained table for t= he purpose of more efficiently compressing messages sent over Low Power and= Lossy Networks. It does not define any new compression formats; it just al= locates code points for future use when those compression formats are defined. As such, there really are no s= ecurity considerations. The document contains a security considerations sec= tion that refers users to two related RFCs.



Sent from Outlook=

--_000_CY4PR17MB0997FAD792FC518176EB15A1DFCD0CY4PR17MB0997namp_-- From nobody Mon Sep 26 09:43:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F6812B248; Mon, 26 Sep 2016 09:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HmdinZSOcBQ; Mon, 26 Sep 2016 09:42:52 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 6CF7312B31D; Mon, 26 Sep 2016 09:42:52 -0700 (PDT) Received: by mail-pa0-x236.google.com with SMTP id gp7so7500899pac.1; Mon, 26 Sep 2016 09:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gdDT+7lGCXfdRm1s62rAxrhhm46xWOxl3b0ZMaGKlP4=; b=wbEsE4nawoNIFTJrHqBj5YQblB8SuJj6fgcMR9L7LwuPV+VmneULlGjKojRVRm7NHm mNt/zec/I5odfjsa+iBYMs/PtTs8kSOuKALs6FrCqSrMSFPWU80w+XcIFyS4NQjunSAy VWG0vDLOlgGcP6AIP+pjPcCQqI8soVZ5xvsC2aBPVE6zJoxf643t8ZThiO8whXxsZeCQ M5ID31JtlUD4S3EktGUCjI/3StVDPEGLOoP7MNDbPQ+llkbLvYUMXOUkWcdGDXWNeIfe J0r+bp2umFM8cQXdqsClf7ZdwnhUQ4+fTYDxL9FXRKejOq7id4Bdmj1kz1t1x09MSTIO sUGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gdDT+7lGCXfdRm1s62rAxrhhm46xWOxl3b0ZMaGKlP4=; b=cybFrE6PD+bvrazqLimPTKvw1+J0uTfYYmXS93gHs4pGRkcLra7SPLVw9xk+VFIKFE In3EfDlaWWclCZh7aUrNZPZRXBc+jFnGDUi/h4749lvnZPJVkEH9BdWA/b3KdaviXdG6 gkjOx6n47xlObHDz+GNdqOA+ZSOrj2befkp4aEEP/Lz4yqh6Msp2ve+p/wv+FSlekn21 xsh4sAJqhAt99uL06UeCg1BTHpwLejNYWoWFitva6ZHRoIr/9jPTOU1Ef/V5Kyyj3p9t bv3zzyFK/GgRIDhCS/WVgw4GFItIhvarmv0J+nO/MSY0qe9++choRLNfvPY71kOtrwRu RIBw== X-Gm-Message-State: AA6/9Rmm5Di7TupHa8bH6i1sEMHxv/VyN05W7UlugCD8cMr3D6ziovLj/CeW9WnJYJczmw== X-Received: by 10.66.199.38 with SMTP id jh6mr3149451pac.160.1474908171709; Mon, 26 Sep 2016 09:42:51 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id i8sm32437915paw.25.2016.09.26.09.42.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Sep 2016 09:42:51 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Mon, 26 Sep 2016 09:43:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> To: David Mandelberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: The IESG , draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 16:42:58 -0000 > On 09/25/2016 06:15 PM, Dino Farinacci wrote: >>> I found one issue in various parts of the document (described = below), >>> but I'm not sure it's relevant to security. If it is, then I think = this >>> document is Almost Ready. If not, then I think this document is = Ready >>> With Nits. >>>=20 >>> There are multiple places in the document where it's possible to = encode >>> semantically equivalent information in multiple ways, despite the = word >>> "canonical" being in the title of the document. Is there anything = that >>> relies on these addresses being canonical for security purposes? >>=20 >> No not for security purposes. There are multiple ways because we = allow some nesting of information as well as allow for compatibility for = older implementations that can=92t parse some AFIs and LCAFs but is = required to parse the AFI-List LCAF type. >=20 > Ok, then I think it needs to be made clear in the security > considerations that this format cannot be relied on to have no more = than > one representation for the same information. Sorry, I am not following your point. The nesting procuedure of LCAFs = allow the same type of address to be expressed multiple ways. I can=92t = tell from your commentary if this is a good thing for security or a bad = thing. So please provide some suggested text on what you would like to = see in the Security Considerations section. > IESG: This means that I think this document is Ready With Nits. >=20 >=20 >>> Multiple places in the document (sections 4.1, 4.5, and 4.8) specify >>> mask lengths, but do not specify that the masked out bits MUST be = set to >>> zero. >>=20 >> Hmm, by definition, a mask-length of say 24 if a mask of 0xffffff00. = And in 4.1: >>=20 >> IID mask-len: if the AFI is set to 0, then this format is not >> encoding an extended EID-prefix but rather an instance-ID range >> where the 'IID mask-len' indicates the number of high-order bits >> used in the Instance ID field for the range. >>=20 >> It is clear that the high-order bits are used that cover the = mask-length and the low-order bits are ignored. Is this not clear to = you? >=20 > That part is clear to me. I just meant that the document as written > appears to allow 1.2.3.4/24 to be equivalent to 1.2.3.7/24. If the I will make this more clear. I added some text. >> Section 6 (Security Considerations): There is no discussion of these >>> addresses being canonical, and what other systems might or might not >>> rely on these addresses being canonical. >>=20 >> In this respect =93canonical=94 is relative to how LISP defines to = encode both simple AFI encoded addresses or more complex/flexible = addresses that accompany information. >=20 > Ok. I interpreted canonical to be a security property of the = addresses, > i.e., that if two addresses are not bytewise equal, then they must not > have the same meaning. If that's not what you meant by canonical, then = I > think the security considerations should say that, so that nobody = tries > to rely on that property in the future. Canonical in this spec means semantically canonical. That is the = following two IP addresses are equal: AFI=3D1, 1.1.1.1 AFI=3DLCAF, lcaf-type=3DAFI-list, AFI=3D1, 1.1.1.1 >> Section 4.7: The Key Algorithm description doesn't point to a = registry >>> of valid values or otherwise say how to interpret values in that = field. >>=20 >> We have put that in a use-case document. This Security Key LCAF is = used by 2 use-cases. It is used for LISP-DDT and for lisp-crypto. In the = lisp-crypto document we have a registry for cipher suites used. >=20 > Should this document reference one or both of those documents? I added text to reference the two documents that use this Security Key = LCAF Type. I=92ll post a new draft when you get me some text for the Security = Considerations section. Thanks! Dino >=20 >=20 > --=20 > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ >=20 From nobody Mon Sep 26 09:47:28 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFABC12B251; Mon, 26 Sep 2016 09:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ8LAqB-4nPR; Mon, 26 Sep 2016 09:47:21 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 2FB1312B24C; Mon, 26 Sep 2016 09:47:21 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id oz2so64713788pac.2; Mon, 26 Sep 2016 09:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1Mn8y/78xbf+oJtg+UAgfllVH9jF9AZUYVfAywy+hxI=; b=yBuMxl+RA4Zs6fp43ZDb5U4ysVxJuVHGvN0+w96TssF0xkGISv86VmYWsNoLksCnE+ xD8wJU6Vraxj6Lcu3iRU1EixGAWaOfA+5PbXlDVG4+7Omqyqe7XykjGM/Guk1XbBB4VF 0K7BrReRh7O/Y4ihIeceVga3LBi9TFjQM8yoTG0gJqylIKIucsMBsu1vQ5F+pMCa7CnL jcoAeXkSVOpsfl605+r82oCipIDhkLo1msLeNEP+X4XukRdMbgA0XEcHZ33XYZz89WhP hEnF6bgoACXhoUfp4vZnMOBMsK6z0seWkACutJ7YsD4FcNUeQHDHCCs2IJMkAQxE1eY8 pnYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1Mn8y/78xbf+oJtg+UAgfllVH9jF9AZUYVfAywy+hxI=; b=H/YXaixiHGLYOfNoFMTIAvJEGOdI+TQdY0+ufm9H0h0vQqvZjbB//bile375qokdRT kYZ8k06jcCQ99/IWgqeVW2aCffXjb0NgkNhKsW5cwdZWLEqVRIc4+hnpQWPOVAHwUUAj QII4wmTHlH+unfeLxS8NW0e47/nb+1F4UBS+ZDKLm0SYosrvW47VAgBecO1x1stpkeVH 9tYwtNN21ZgLXyDGptHTcLQqM0BMiHFcBhPxPCMSez8NeTWUrUDaZaY+PqAKcw47jYik BY9Sxw0WYEUXVUubt1qu5+jLUMlHBeryWBiC3UDLWUjIF3NVdS4gMS0pz4TD6kHHqcLG LTJQ== X-Gm-Message-State: AE9vXwP0APFr30f/K159b31mksjeinX4Y+TlgkQJdqfr0mEs+i2SZZL1vxI8kyZwYFIhhA== X-Received: by 10.66.254.170 with SMTP id aj10mr40794298pad.124.1474908440804; Mon, 26 Sep 2016 09:47:20 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id i8sm32457074paw.25.2016.09.26.09.47.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Sep 2016 09:47:20 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <7345DDFF-0D4F-4F47-87D1-56459ED94D2A@cisco.com> Date: Mon, 26 Sep 2016 09:47:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <067010BC-5EE7-46AF-B06F-B227BEE9A565@gmail.com> References: <57E68FB7.10408@gmail.com> <57E690AD.2030207@gmail.com> <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com> <57E87980.2050209@gmail.com> <7345DDFF-0D4F-4F47-87D1-56459ED94D2A@cisco.com> To: Brian Weis X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-lisp-crypto.all@ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 16:47:23 -0000 Chris, if you are fine with Brian=92s response, I can post the -08. = Please ack. Thanks. Dino > On Sep 25, 2016, at 8:11 PM, Brian Weis (bew) wrote: >=20 > Hi Chris,=20 >=20 > Thanks for the review. I=92ve added one comment below. >=20 >> On Sep 25, 2016, at 6:27 PM, Chris Lonvick = wrote: >>=20 >> Hi Dino, >>=20 >> On 9/25/16 4:37 PM, Dino Farinacci wrote: >>>>> I don't follow LISP so I'm not sure if there is an actual = mechanism for a device receiving a map request packet to decline an = offered cipher suite. If there is, I didn't see it explained in the >>> Yes, there is. If the Map-Reply this is returned contains no = Security LCAF that means to the ITR that it either needs to go = unencrypted encapsulating packets to the ETR or try another cipher text. >>>=20 >>>>>>> draft. You should address this in a future draft. This will be = needed for when new cipher suites are >>> Understand the need. We intentionally wanted to support this. >>>=20 >>>>>>> added and a receiving device does not have the capability to = handle the new cipher suite, or the case where an old cipher suite has = been administratively disabled; like if it's been compromised and = shouldn't be used. There are several ways to do this. >>> We have this in section x of the draft. Is it not sufficient? >>>=20 >>> If an ITR, PITR, or RTR sends a Map-Request with the Security Type >>> LCAF included and the ETR or RTR does not want to have = encapsulated >>> traffic encrypted, they will return a Map-Reply with no RLOC = records >>> encoded with the Security Type LCAF. This signals to the ITR, = PITR >>> or RTR not to encrypt traffic (it cannot encrypt traffic anyways >>> since no ETR public-key was returned). >>>=20 >> That text just says that if the cipher suite is declined then there = will be no encryption. I was interpreting that to mean that the receiver = just isn't going to accept any attempt at encryption. If it's just meant = to be for that particular cipher suit then you'll need to add a line to = that paragraph to say that the ITR, PITR, or RTR can attempt a different = cipher suite if it is administratively configured to do so. However, = that could get to be very inefficient if the ITR has to make 6 attempts = before understanding that the ETR just isn't going to accept any = encryption request - if it's so configured, or if it just doesn't = support the feature whatsoever. So even if you allow the sender to make = offer after offer, it would still be a good idea to have a way for the = receiver to entirely decline encrypting packets from the sender. >>=20 >> But, with all that being said, I'm figuring that we're getting = outside the intent of your experimental specification. When you do get = around to getting this onto a standards track, then you should make some = decisions around how to convey capabilities between the sender and = receiver so they can quickly and efficiently figure out what's going to = work, or if it's just not, rather than making one offer after another. = TLS and SSH have ways for a sender to offer a list from which the = receiver can choose, if you're looking for examples. Another way is for = the sender to proffer a version number which is associated with a select = group of capabilities. =46rom that, the receiver can make a choice, or = efficiently decline all. >=20 > Thanks for the suggestions. In this effort we were intentionally = avoiding the complexities and added security analysis requirements of a = multiple round-trip method capabilities negotiation such as TLS. But = maybe a capabilities declaration more along the lines of the version = number you suggest might be appropriate. I agree that at such time as = the protocol was prepared for standards-track that this would be = important to add. >=20 > Thanks, > Brian >=20 >>=20 >> Best regards, >> Chris >=20 > --=20 > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com >=20 From nobody Mon Sep 26 10:40:36 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B1C12B31B; Mon, 26 Sep 2016 10:40:29 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhkrgGKW5g7w; Mon, 26 Sep 2016 10:40:28 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D026512B118; Mon, 26 Sep 2016 10:40:27 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id r126so215551715oib.0; Mon, 26 Sep 2016 10:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=1HmfuACH9wwa2apw3UBYd/PskyWOlcZnvgBlBhgqsPY=; b=QAtIhbU416p/CsGVVQ48jPEL2uibFy2R1zDGqvHP/3xWVbWASSkIVbWfaMvT2pg4sO iZS2ze0nvDzz1hJ6IOJYWRul6NlYJMD7bmqdha5XO1XN40M+vCZnGVnlo8QSlVpxGwFD 6/caojZaKXZF5mkpnXvROZy3R4hE01tMHqFqWJUxyYABQ5ERzmgxe5Pf4n9CX0B/GEVD OkwNBrUMzu7UBKbWgEvcGdlR+ZxRpuXwWCFZUzPjBfFfqOWTiymH9/MWcXVuHqxI6uRU p7fHm4eNrXz+NvctKgSN0n3QBSfC7vlQ44ss2rZp/mgF7MxQ27LVbOjXdqul7+VOxOVU a+cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1HmfuACH9wwa2apw3UBYd/PskyWOlcZnvgBlBhgqsPY=; b=aor0XGs3a3PRtAZp+1GlCFIPh9dL6QNa+n+/SNpzMuWeF3l3f3R8x1dq7/b5m30uuC 6FOBphPDpxx68/oN5KXcVNaW7uWsuGiBaqscx/EA+gdYMIzZfij7D8bOb536IPbHXLi/ sMAx8wCQR9JPj8Zdf7Be2IHfaWSackHv29lP4a09msoH6bIJaG1TMC98kKpGccbmb1JU U/NNOeIF5bhj2DoyDpk14JKoAfTNLryZMLJlSORqa5BpFcPiy8Z0tgosU/Rw0+gvVms7 abQtuOfBwfUWGWoaz4tk8SYXy04wUhTbHz+i2P9RmVLhr7k6TdQeY3YeUkAQQ+su3AVz 3Sew== X-Gm-Message-State: AE9vXwPaLBORwmUQ1oDrKG8aa3c7vNs1X/YPTvYpr7uMLvL/66C5kISaaWvqaORkyUef1w== X-Received: by 10.202.90.196 with SMTP id o187mr26121592oib.176.1474911625653; Mon, 26 Sep 2016 10:40:25 -0700 (PDT) Received: from chriss-air.smd.local ([216.201.230.154]) by smtp.googlemail.com with ESMTPSA id z196sm7659339oig.13.2016.09.26.10.40.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Sep 2016 10:40:24 -0700 (PDT) To: Dino Farinacci , Brian Weis References: <57E68FB7.10408@gmail.com> <57E690AD.2030207@gmail.com> <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com> <57E87980.2050209@gmail.com> <7345DDFF-0D4F-4F47-87D1-56459ED94D2A@cisco.com> <067010BC-5EE7-46AF-B06F-B227BEE9A565@gmail.com> From: Chris Lonvick Message-ID: <57E95D87.4090104@gmail.com> Date: Mon, 26 Sep 2016 12:40:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <067010BC-5EE7-46AF-B06F-B227BEE9A565@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-lisp-crypto.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 17:40:30 -0000 Hi Dino and Brian, Yup - all looks good. I didn't mean to push too much on the point because I figured that it wasn't needed or wanted for being an experimental document. Good luck with it. Best regards, Chris On 9/26/16 11:47 AM, Dino Farinacci wrote: > Chris, if you are fine with Brian’s response, I can post the -08. Please ack. Thanks. > > Dino > >> On Sep 25, 2016, at 8:11 PM, Brian Weis (bew) wrote: >> >> Hi Chris, >> >> Thanks for the review. I’ve added one comment below. >> >>> On Sep 25, 2016, at 6:27 PM, Chris Lonvick wrote: >>> >>> Hi Dino, >>> >>> On 9/25/16 4:37 PM, Dino Farinacci wrote: >>>>>> I don't follow LISP so I'm not sure if there is an actual mechanism for a device receiving a map request packet to decline an offered cipher suite. If there is, I didn't see it explained in the >>>> Yes, there is. If the Map-Reply this is returned contains no Security LCAF that means to the ITR that it either needs to go unencrypted encapsulating packets to the ETR or try another cipher text. >>>> >>>>>>>> draft. You should address this in a future draft. This will be needed for when new cipher suites are >>>> Understand the need. We intentionally wanted to support this. >>>> >>>>>>>> added and a receiving device does not have the capability to handle the new cipher suite, or the case where an old cipher suite has been administratively disabled; like if it's been compromised and shouldn't be used. There are several ways to do this. >>>> We have this in section x of the draft. Is it not sufficient? >>>> >>>> If an ITR, PITR, or RTR sends a Map-Request with the Security Type >>>> LCAF included and the ETR or RTR does not want to have encapsulated >>>> traffic encrypted, they will return a Map-Reply with no RLOC records >>>> encoded with the Security Type LCAF. This signals to the ITR, PITR >>>> or RTR not to encrypt traffic (it cannot encrypt traffic anyways >>>> since no ETR public-key was returned). >>>> >>> That text just says that if the cipher suite is declined then there will be no encryption. I was interpreting that to mean that the receiver just isn't going to accept any attempt at encryption. If it's just meant to be for that particular cipher suit then you'll need to add a line to that paragraph to say that the ITR, PITR, or RTR can attempt a different cipher suite if it is administratively configured to do so. However, that could get to be very inefficient if the ITR has to make 6 attempts before understanding that the ETR just isn't going to accept any encryption request - if it's so configured, or if it just doesn't support the feature whatsoever. So even if you allow the sender to make offer after offer, it would still be a good idea to have a way for the receiver to entirely decline encrypting packets from the sender. >>> >>> But, with all that being said, I'm figuring that we're getting outside the intent of your experimental specification. When you do get around to getting this onto a standards track, then you should make some decisions around how to convey capabilities between the sender and receiver so they can quickly and efficiently figure out what's going to work, or if it's just not, rather than making one offer after another. TLS and SSH have ways for a sender to offer a list from which the receiver can choose, if you're looking for examples. Another way is for the sender to proffer a version number which is associated with a select group of capabilities. From that, the receiver can make a choice, or efficiently decline all. >> Thanks for the suggestions. In this effort we were intentionally avoiding the complexities and added security analysis requirements of a multiple round-trip method capabilities negotiation such as TLS. But maybe a capabilities declaration more along the lines of the version number you suggest might be appropriate. I agree that at such time as the protocol was prepared for standards-track that this would be important to add. >> >> Thanks, >> Brian >> >>> Best regards, >>> Chris >> -- >> Brian Weis >> Security, CSG, Cisco Systems >> Telephone: +1 408 526 4796 >> Email: bew@cisco.com >> From nobody Mon Sep 26 17:43:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A33912B357 for ; Mon, 26 Sep 2016 17:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTlC9UcUfxbk for ; Mon, 26 Sep 2016 17:43:18 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA51E12B047 for ; Mon, 26 Sep 2016 17:43:17 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 26 Sep 2016 17:56:30 -0700 From: Jim Schaad To: 'Stephen Kent' , 'secdir' , 'Justin Richer' , 'Kepeng Li' , 'Kathleen Moriarty' References: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> <080101d21461$de39f850$9aade8f0$@augustcellars.com> <2228fec7-f5ef-c5e2-91bd-7499e7cb9f19@bbn.com> In-Reply-To: <2228fec7-f5ef-c5e2-91bd-7499e7cb9f19@bbn.com> Date: Mon, 26 Sep 2016 17:43:02 -0700 Message-ID: <021301d21858$1c6a1a70$553e4f50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQLn+ErX890UkhHKZArMVoO8r82N0wG87GI8Ae7kyV6ePlBEoA== X-Originating-IP: [192.168.1.152] Archived-At: Subject: Re: [secdir] secdir review of cose-msg-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 00:43:20 -0000 > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Friday, September 23, 2016 10:55 AM > To: Jim Schaad ; 'secdir' ; = 'Justin > Richer' ; 'Kepeng Li' ; = 'Kathleen > Moriarty' > Subject: Re: secdir review of cose-msg-18 >=20 > Jim, >=20 > How's harvest going? We now have 75% of the fruit picked, and Tom says that this is the hump = day for harvest this year. From here on how we are no longer totally at = the mercy of the weather and timing of doing things is more negotiable. = A lot of people are seeing high Brix numbers so am expecting to see some = high alcohol wine unless the Jesus effect is put into place. Flavors = are a bit thin on the wines that have been pressed out from others in = the building. I haven't pressed anything yet. >=20 >=20 > > [JLS] This was the approach that I had originally intended to take, = breaking the > document in two pieces towards the end when things were settled. My = memory > is that this was discussed in the working group, and it was determined = that one > document was preferable to having two different documents. I believe = that this > practice started with CMS and it was done there to deal with the = question of > how to advance to standards track for the format document and still = allow the > algorithm document to be updated. This has not seemed to be how = things have > worked in practice, or has been necessary as protocol documents such = as > S/MIME is where the implementation requirements on algorithms are = specified > rather than in the format draft (CMS). I therefore have less problems = with the > fact that this is one draft from that standpoint. It would have been = nicer just > from a length prospective, but people thought that being able to = reference back > and forth in a single HTML page to be better than flipping between = different > pages. > I hear from you and others that this is what the WG wanted. So, please = add text > at the beginning of the algs discussion noting that when it becomes = necessary to > add or remove algs the plan is to ... My first response was this was a reasonable request and should not = present any problems. Then I tried to actually do it. In the end the = text I wrote looked a great deal like saying that one needs to follow = standard IETF procedures to update a document. Write a draft, update a = registry, get it approved. The fact that the algorithms are in this = document as opposed to a separate document does not change any of the = procedures about doing updates. The only thing that it would affect is = the documents status as a standard. If the document is modified it = would be reset to a lower point. This is a reasonable discussion if and = when that process step is made but should not affect things now. I therefore would decline to make the requested change. > > [JLS] There was a long discussion about what to do with the CDDL = grammar > portions of the document. Like me, it would appear that you are a = strong > advocate of doing formal languages and making them normative rather = than > making descriptive text normative. Given the state of CDDL making it = a > normative reference would be difficult since it is still being = transformed. I have > argued with the authors to try and get what is there published but = have not been > successful. > I reread Section 1.3 and I see that you did say that the text = describing COSE > structures, not the CDDL, is normative. Since CDDL might change, do = you feel > that 1.3 provides enough background so that a reader need not refer = the CDDL I- > D? What's the plan if the RFC version of CDDL differs from the current = version in > a way that causes the descriptions in this document to no longer be = accurate > descriptions of COSE structures? Two things, one we are referencing a specific version of the draft and = drafts never go away so people will always be able to see what it was = written to. Additionally, I am involved in the effort to get CDDL = standardized and would object to anything that is too incompatible with = what is used here. They are mostly trying to do bells and whistles = which could just as easily go into a version 2 of the document. Perfect = being the enemy of the adequate. I would also expect that if the CDDL changes too much, I would want to = do a revision of the document to deal with that. > > [JLS] I thought about making this change in the past but had an = issue with the > fact that this might make people think that the Signed Data object = version could > only be used if there were two or more signers. It allows for one or = more > signers so it is a bit of a misnomer to say that it is a multiple = signer version. The > structures are build in such a way that one cannot switch between the = versions > so you cannot just go from the Single Signer to the Multiple Signer = when a > second signature is added. > > > > I can understand the issue you are raising, but the solution has = similar issues. > The term "One or More Signer Data Object" seems to be a bit unwieldy. = Other > suggestions would be welcome. > Multi-signer Data Object seems concise to me ;-) Again - I have a problem with trying to get people not to jump to the = wrong conclusion for Single vs Multi. While you do not have a problem, = that does not mean that others will not see this and misconstrue the = titles. > > Section 5 describes the COSE encryption objects. I disagree with one = choice of > terminology adopted here: =E2=80=9Crecipient algorithm = classes=E2=80=9D which is described in > 5.1.1. This is really a discussion of classes of key = distribution/management > algorithms, focusing on how each recipient of an encrypted message = acquires > the CEK used to decrypt the message. I=E2=80=99d prefer a less obscure = name for this sub- > section. Otherwise this section is well written and provide lots of = useful details > about how to encrypt and decrypt messages for two classes of = encryption > algorithms. > > > > [JLS] I agree that the term is not optimal. There was a long = discussion about > this in the WG on the mailing list. The original term used was "key = management > classes" (if memory serves) and there were issues raised because this = is not key > management in the world of how does a client get a symmetric or public = key. > The fact that the term was ambiguous as to the problem being solved = was > thought to be an issue. After a long discussion the term "recipient = algorithm > classes" was adopted. > I think "content key distribution methods" is the right title for = this, having re- > read section 13. That's what you're describing. That is a good title, I will run that past the WG, but expect no issues = with it. Jim >=20 > Steve From nobody Tue Sep 27 09:28:54 2016 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 6E6F512B2A9; Tue, 27 Sep 2016 09:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1474993046; bh=Kog6DdR2j1BAiFhmzSx6vEvJabrgpNnXT4odwW7t3ng=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Za+u8RTHx8RupaAODeL8DdX+JspcBtCf4LHDN6sz7IxdanV7wRuakpg360fhY6IDP a+REbrMbSB4QxZjrnKqGqr0m/pYJbY0cnUNxwVnjsC91a9pK6GRGLBTgfnIgW70HHe Of186c6qq0a9Qo2kLct0YhoemXM3n45wpI22tr9I= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFD912B293 for ; Tue, 27 Sep 2016 09:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7TvNFX7UQdF for ; Tue, 27 Sep 2016 09:17:22 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568B912B2A2 for ; Tue, 27 Sep 2016 09:17:22 -0700 (PDT) Received: from amontsouris-652-1-80-124.w92-163.abo.wanadoo.fr ([92.163.103.124] helo=pc13.home) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bov4L-0008Tl-32; Tue, 27 Sep 2016 16:17:21 +0000 From: Coralie Mercier Date: Tue, 27 Sep 2016 18:17:18 +0200 To: new-work@ietf.org Message-Id: <36B8D851-8683-4313-9E5B-301518480396@w3.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 27 Sep 2016 09:28:52 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Second Screen Working Group (until 2016-10-25) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 16:17:26 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBTZWNvbmQg U2NyZWVuIFdvcmtpbmcgR3JvdXA6CiAgaHR0cHM6Ly93d3cudzMub3JnLzIwMTQvc2Vjb25kc2Ny ZWVuL2NoYXJ0ZXItMjAxNi5odG1sCgpBcyBwYXJ0IG9mIGVuc3VyaW5nIHRoYXQgdGhlIGNvbW11 bml0eSBpcyBhd2FyZSBvZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhpcyBkcmFmdCBjaGFydGVy IGlzIHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSByZXZpZXcgcGVyaW9kLgoK VzNDIGludml0ZXMgcHVibGljIGNvbW1lbnRzIHRocm91Z2ggMjAxNi0xMC0yNSBvbiB0aGUKcHJv cG9zZWQgY2hhcnRlci4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8KcHVibGljLW5ldy13b3JrQHcz Lm9yZywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiAgaHR0cDovL2xpc3RzLnczLm9yZy9B cmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBjb21tZW50cyBzZW50 IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRlZSBSZXByZXNlbnRh dGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29tbWVudHMuIElmIHlv dSB3b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0ZQp5b3VyIGNvbW1l bnRzIHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUuIEZvcgpleGFt cGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlhIHRoaXMgbGlzdCBh bmQKaGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZSByZWZlciB0byBp dCBmcm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KCklmIHlvdSBzaG91bGQg aGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNlCmNv bnRhY3QgRnJhbsOnb2lzIERhb3VzdCwgU3RhZmYgQ29udGFjdCA8ZmRAdzMub3JnPi4KClRoYW5r IHlvdSwKCkNvcmFsaWUgTWVyY2llciwgSGVhZCBvZiBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNh dGlvbnMKClsxXSBodHRwOi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0CgrigJQK Q29yYWxpZSBNZXJjaWVyICAtICBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNhdGlvbnMgLSAgaHR0 cDovL3d3dy53My5vcmcKbWFpbHRvOmNvcmFsaWVAdzMub3JnICszMzYgNDMyMiAwMDAxIGh0dHA6 Ly93d3cudzMub3JnL1Blb3BsZS9DTWVyY2llci8KCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Tue Sep 27 09:49:33 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F7912B2C0; Tue, 27 Sep 2016 09:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-nOz4c_ats7; Tue, 27 Sep 2016 09:49:25 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 25A6912B0CE; Tue, 27 Sep 2016 09:49:25 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id 21so7619035pfy.0; Tue, 27 Sep 2016 09:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pgen7EjXhmgIQWGKlSlzyKGgTJGiDYK8/Hvv0iP/1Fg=; b=ys+2qszSQ6BFt2iGQujyGjVzH8we0F+l7If7m2ebE5zHlJq4RGMO9nDPqGNzF+4xCX jwUB7qsV9Zg8bMtLvBKXvtOxhMUx4+uaZBygy/4EYidTOgDd+qxX3tN6qquE/QMjEiTv SUdneXh+MEK4uiPF+awCHKceRGY0eYAEpPq+MsWRTo9Hdexd0kLj/xAFJ/Z5v04IPeJS 6y4zvAppt2VSaZPw4A8AB7EFSyhpl/JY+TR9WF67pjC8tRlULtF/YElVenXnIlhGXexy LGh9lKkC2Cr++aYMiI7uhi2GeD+VJKbGbQalLh9rAaLI4f4eDCW+S1gHL7+X6+Afqiyo wzcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pgen7EjXhmgIQWGKlSlzyKGgTJGiDYK8/Hvv0iP/1Fg=; b=EKLfqFeQGZ0qZfnCCZITYiNn/TpWiXNho5Tu/KIZqWh26PPO4CRXlLbzjN9NCMyQn2 2NRULNKu+G5kx101jCoJhPx2dbPP4WN7KG2fWbNMtNYty+TA0K5y1DfpUej3eydwUATu RNSLW6Q5mrS9iTelqOyNdf9icv496IbhLjrOc7UjYEhSrkUBmwBRGTv8qRPtxlDZky93 KdXv4ppZZTfDax92GFShlcSwOBSa4HNqSWSM0cjyweuVasPizyBBOZZAEcWKtCYy92n5 1shalZn8npLqKW7gvY55RLWS3x2VGMATwLnoKeIg7WNuJ/zFuEGBG8mn7wlETLUsHE/1 kvRw== X-Gm-Message-State: AE9vXwNGgIMRe9PdyaiC+jEh2nnjRSV3x7tadLqaY6Iqiob5TXVzvyeoJT+j8eovOFC+Xg== X-Received: by 10.98.213.68 with SMTP id d65mr48943537pfg.112.1474994964746; Tue, 27 Sep 2016 09:49:24 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id ah5sm6197408pad.30.2016.09.27.09.49.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 Sep 2016 09:49:24 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <067010BC-5EE7-46AF-B06F-B227BEE9A565@gmail.com> Date: Tue, 27 Sep 2016 09:49:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <11EFFE46-C4D6-4D8D-97AA-E56A631A2273@gmail.com> References: <57E68FB7.10408@gmail.com> <57E690AD.2030207@gmail.com> <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com> <57E87980.2050209@gmail.com> <7345DDFF-0D4F-4F47-87D1-56459ED94D2A@cisco.com> <067010BC-5EE7-46AF-B06F-B227BEE9A565@gmail.com> To: Brian Weis X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-lisp-crypto.all@ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 16:49:27 -0000 Chris, is it okay to post draft-ietf-lisp-crypto-08? Dino > On Sep 26, 2016, at 9:47 AM, Dino Farinacci = wrote: >=20 > Chris, if you are fine with Brian=92s response, I can post the -08. = Please ack. Thanks. >=20 > Dino >=20 >> On Sep 25, 2016, at 8:11 PM, Brian Weis (bew) wrote: >>=20 >> Hi Chris,=20 >>=20 >> Thanks for the review. I=92ve added one comment below. >>=20 >>> On Sep 25, 2016, at 6:27 PM, Chris Lonvick = wrote: >>>=20 >>> Hi Dino, >>>=20 >>> On 9/25/16 4:37 PM, Dino Farinacci wrote: >>>>>> I don't follow LISP so I'm not sure if there is an actual = mechanism for a device receiving a map request packet to decline an = offered cipher suite. If there is, I didn't see it explained in the >>>> Yes, there is. If the Map-Reply this is returned contains no = Security LCAF that means to the ITR that it either needs to go = unencrypted encapsulating packets to the ETR or try another cipher text. >>>>=20 >>>>>>>> draft. You should address this in a future draft. This will be = needed for when new cipher suites are >>>> Understand the need. We intentionally wanted to support this. >>>>=20 >>>>>>>> added and a receiving device does not have the capability to = handle the new cipher suite, or the case where an old cipher suite has = been administratively disabled; like if it's been compromised and = shouldn't be used. There are several ways to do this. >>>> We have this in section x of the draft. Is it not sufficient? >>>>=20 >>>> If an ITR, PITR, or RTR sends a Map-Request with the Security Type >>>> LCAF included and the ETR or RTR does not want to have = encapsulated >>>> traffic encrypted, they will return a Map-Reply with no RLOC = records >>>> encoded with the Security Type LCAF. This signals to the ITR, = PITR >>>> or RTR not to encrypt traffic (it cannot encrypt traffic anyways >>>> since no ETR public-key was returned). >>>>=20 >>> That text just says that if the cipher suite is declined then there = will be no encryption. I was interpreting that to mean that the receiver = just isn't going to accept any attempt at encryption. If it's just meant = to be for that particular cipher suit then you'll need to add a line to = that paragraph to say that the ITR, PITR, or RTR can attempt a different = cipher suite if it is administratively configured to do so. However, = that could get to be very inefficient if the ITR has to make 6 attempts = before understanding that the ETR just isn't going to accept any = encryption request - if it's so configured, or if it just doesn't = support the feature whatsoever. So even if you allow the sender to make = offer after offer, it would still be a good idea to have a way for the = receiver to entirely decline encrypting packets from the sender. >>>=20 >>> But, with all that being said, I'm figuring that we're getting = outside the intent of your experimental specification. When you do get = around to getting this onto a standards track, then you should make some = decisions around how to convey capabilities between the sender and = receiver so they can quickly and efficiently figure out what's going to = work, or if it's just not, rather than making one offer after another. = TLS and SSH have ways for a sender to offer a list from which the = receiver can choose, if you're looking for examples. Another way is for = the sender to proffer a version number which is associated with a select = group of capabilities. =46rom that, the receiver can make a choice, or = efficiently decline all. >>=20 >> Thanks for the suggestions. In this effort we were intentionally = avoiding the complexities and added security analysis requirements of a = multiple round-trip method capabilities negotiation such as TLS. But = maybe a capabilities declaration more along the lines of the version = number you suggest might be appropriate. I agree that at such time as = the protocol was prepared for standards-track that this would be = important to add. >>=20 >> Thanks, >> Brian >>=20 >>>=20 >>> Best regards, >>> Chris >>=20 >> --=20 >> Brian Weis >> Security, CSG, Cisco Systems >> Telephone: +1 408 526 4796 >> Email: bew@cisco.com >>=20 >=20 From nobody Tue Sep 27 09:50:24 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A7A12B2A9; Tue, 27 Sep 2016 09:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxaNouL9TxZJ; Tue, 27 Sep 2016 09:50:16 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 6B4A012B2C5; Tue, 27 Sep 2016 09:50:16 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id q2so7582616pfj.3; Tue, 27 Sep 2016 09:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zTGFkHhPF74XIDSCJHKy9Z80Dk8F86Ry3bQlqFK9XBQ=; b=T5z/7rTiCKuN8L/Z5Scd3MEZft2NASC5ymRnn9xYe0eVjkdxDxjJxN1EDc77hakovr to2eyR3/vNCLastW/PvgZyjWP6nQvMA5kFmlhiaKgulFXTkrKNFvujTlbURTeaRwV3Kw dhk2awtKyZ540G1KAtScGOHwfQYTXLpVW1DGuZuAYHUHGlhzJ1r2F/Q3cSkEalNODV84 +S4v1MrF1VmXB4jyzy5zU7qYfww1EUdgCxITEAbmV2X985HxT5zVUxrKmvCxfHTuf4Yi iWmWKL4ZvKraFtYI4Kthjo1hdFOnRYbU+qTCunnoMKvnquKwSSjkLRuxIHatH3L/DnCV VxgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zTGFkHhPF74XIDSCJHKy9Z80Dk8F86Ry3bQlqFK9XBQ=; b=B+V6l6fKt805RtAIbiEDvTyb9kXqVy51XFUdF/FEEmf5ZYknukQqFwMNez9d2UcR99 awgU0gPoa0wvYHWyL9w0nhKmcXAr8z6lWIU8lVs1wsd1JO03kGTY2lGY1pJpK2CKkfc7 3H32z+wgaGmgGjkxT27dk1LvsuZMhfpJrOyfqYeA3Scz65fCg0pJiTcfA+0jvYzT5QvS xPTaJDAHpf26cxXEhFZhJ1CJdKnVE3TyMbwlv3tOz0vRcBH4VWgTjjGZakD/xVmg7RSZ c9HhKDoDMEyuLEYZZiNBPTyniBNaS6W+CuBDXG6uFUnQwN3DrfOztq+3fSqH9zg92Tpb 5NPg== X-Gm-Message-State: AE9vXwMeJjLBEuYe++jaHN0TRMM1rqrOyg6ZZIZ3OZQBaTntjK73k/Dq/GPbenGcllT2OQ== X-Received: by 10.98.98.193 with SMTP id w184mr49179749pfb.120.1474995015988; Tue, 27 Sep 2016 09:50:15 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id ah5sm6197408pad.30.2016.09.27.09.50.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 Sep 2016 09:50:15 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Tue, 27 Sep 2016 09:50:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2979E792-737A-4027-8B79-7080AB533B9B@gmail.com> References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> To: David Mandelberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: The IESG , draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 16:50:18 -0000 David, any response. Thanks. Dino > On Sep 26, 2016, at 9:43 AM, Dino Farinacci = wrote: >=20 >> On 09/25/2016 06:15 PM, Dino Farinacci wrote: >>>> I found one issue in various parts of the document (described = below), >>>> but I'm not sure it's relevant to security. If it is, then I think = this >>>> document is Almost Ready. If not, then I think this document is = Ready >>>> With Nits. >>>>=20 >>>> There are multiple places in the document where it's possible to = encode >>>> semantically equivalent information in multiple ways, despite the = word >>>> "canonical" being in the title of the document. Is there anything = that >>>> relies on these addresses being canonical for security purposes? >>>=20 >>> No not for security purposes. There are multiple ways because we = allow some nesting of information as well as allow for compatibility for = older implementations that can=92t parse some AFIs and LCAFs but is = required to parse the AFI-List LCAF type. >>=20 >> Ok, then I think it needs to be made clear in the security >> considerations that this format cannot be relied on to have no more = than >> one representation for the same information. >=20 > Sorry, I am not following your point. The nesting procuedure of LCAFs = allow the same type of address to be expressed multiple ways. I can=92t = tell from your commentary if this is a good thing for security or a bad = thing. So please provide some suggested text on what you would like to = see in the Security Considerations section. >=20 >> IESG: This means that I think this document is Ready With Nits. >>=20 >>=20 >>>> Multiple places in the document (sections 4.1, 4.5, and 4.8) = specify >>>> mask lengths, but do not specify that the masked out bits MUST be = set to >>>> zero. >>>=20 >>> Hmm, by definition, a mask-length of say 24 if a mask of 0xffffff00. = And in 4.1: >>>=20 >>> IID mask-len: if the AFI is set to 0, then this format is not >>> encoding an extended EID-prefix but rather an instance-ID range >>> where the 'IID mask-len' indicates the number of high-order bits >>> used in the Instance ID field for the range. >>>=20 >>> It is clear that the high-order bits are used that cover the = mask-length and the low-order bits are ignored. Is this not clear to = you? >>=20 >> That part is clear to me. I just meant that the document as written >> appears to allow 1.2.3.4/24 to be equivalent to 1.2.3.7/24. If the >=20 > I will make this more clear. I added some text. >=20 >>> Section 6 (Security Considerations): There is no discussion of these >>>> addresses being canonical, and what other systems might or might = not >>>> rely on these addresses being canonical. >>>=20 >>> In this respect =93canonical=94 is relative to how LISP defines to = encode both simple AFI encoded addresses or more complex/flexible = addresses that accompany information. >>=20 >> Ok. I interpreted canonical to be a security property of the = addresses, >> i.e., that if two addresses are not bytewise equal, then they must = not >> have the same meaning. If that's not what you meant by canonical, = then I >> think the security considerations should say that, so that nobody = tries >> to rely on that property in the future. >=20 > Canonical in this spec means semantically canonical. That is the = following two IP addresses are equal: >=20 > AFI=3D1, 1.1.1.1 > AFI=3DLCAF, lcaf-type=3DAFI-list, AFI=3D1, 1.1.1.1 >=20 >>> Section 4.7: The Key Algorithm description doesn't point to a = registry >>>> of valid values or otherwise say how to interpret values in that = field. >>>=20 >>> We have put that in a use-case document. This Security Key LCAF is = used by 2 use-cases. It is used for LISP-DDT and for lisp-crypto. In the = lisp-crypto document we have a registry for cipher suites used. >>=20 >> Should this document reference one or both of those documents? >=20 > I added text to reference the two documents that use this Security Key = LCAF Type. >=20 > I=92ll post a new draft when you get me some text for the Security = Considerations section. Thanks! >=20 > Dino >=20 >>=20 >>=20 >> --=20 >> David Eric Mandelberg / dseomn >> http://david.mandelberg.org/ >>=20 >=20 From nobody Tue Sep 27 18:26:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B018512B3A7; Tue, 27 Sep 2016 18:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg9vudPiALbj; Tue, 27 Sep 2016 18:26:14 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 C5C9312B3A1; Tue, 27 Sep 2016 18:26:14 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id l25so11415177pfb.1; Tue, 27 Sep 2016 18:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XhUSxczEkA4LX0l2Ab7C0OrE5p2+2CTAayTyytXi+FE=; b=glORpHnltExOXfB5+O1JaOXQ6zczT6r3FInNbTGfZDHXx1tYZAmzhkliCoZSSsizSi cTkZJ/y+x8Ck9IIHBikNhHbH5LJp5In09tGNQCba56DpcbFu45nKgAy7dYgl5EqdDPks C8x0SRffP1cHZxIVjVJ8NSI4kE9Nktdgiv35JmWPUiGRE3qDM8ZGXT3hIpUsz4ay94A7 ZCAJ63oYL8wPc4dfPP1awhn/+3OTxHfUYjOoYqCGHp9Obz9XMcC1jYzl6ZVhkCzrSanR LlwPlcF7A5Yi6jey0At0pp+H7FQ+w8yjdb1eXKcnnThCI29Negj1QL2rFwa3QgvRHiY5 v5nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=XhUSxczEkA4LX0l2Ab7C0OrE5p2+2CTAayTyytXi+FE=; b=VYHfy4BH/aVoKYvPZRBn122yZLC/ufm/p4gtWT6JSA61dp5cL2+2ReSLWNLNYr3uOW Z0A5tkVYfKToBO+Pr4/vH3VWl4Adto8GuDntfra1h5KUVol1Cz8fOS5rfVlZ6duTXJOW uBi+f6Qi7bvvXN5tWH9/ufYlqIMCNPXb7uNkB6HruX0LxOO/NUVspmhUGfKHmVBSQAx7 ST1EIZyAOvskkb+klL4Df4U/BhxiMU8HFmCiFQFy0rqTCTLEdsEDz11fc6nAFQrVlYFB AyYCItoqK79s318JAoNOXWvPGNJ4vdATbGw6AdmqsxdxkEghn58xjikn9GzPurKHKKDc 2tlg== X-Gm-Message-State: AE9vXwONgKLdHUrGrhMFwlkhcuaHkwDMG28he6ItxNZVD5tfFir0hkaaglHGha6UxuuTHQ== X-Received: by 10.98.152.138 with SMTP id d10mr52116094pfk.8.1475025974363; Tue, 27 Sep 2016 18:26:14 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:b47b:b432:d33f:ea09]) by smtp.googlemail.com with ESMTPSA id s82sm7577954pfg.42.2016.09.27.18.26.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Sep 2016 18:26:12 -0700 (PDT) To: Dino Farinacci , Brian Weis References: <57E68FB7.10408@gmail.com> <57E690AD.2030207@gmail.com> <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com> <57E87980.2050209@gmail.com> <7345DDFF-0D4F-4F47-87D1-56459ED94D2A@cisco.com> <067010BC-5EE7-46AF-B06F-B227BEE9A565@gmail.com> <57E95D87.4090104@gmail.com> From: Chris Lonvick Message-ID: <57EB1C33.60000@gmail.com> Date: Tue, 27 Sep 2016 20:26:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57E95D87.4090104@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-lisp-crypto.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 01:26:17 -0000 Resending - Looks like Dino didn't get this. Best regards, Chris On 9/26/16 12:40 PM, Chris Lonvick wrote: > Hi Dino and Brian, > > Yup - all looks good. I didn't mean to push too much on the point > because I figured that it wasn't needed or wanted for being an > experimental document. Good luck with it. > > Best regards, > Chris > > On 9/26/16 11:47 AM, Dino Farinacci wrote: >> Chris, if you are fine with Brian’s response, I can post the -08. >> Please ack. Thanks. >> >> Dino >> >>> On Sep 25, 2016, at 8:11 PM, Brian Weis (bew) wrote: >>> >>> Hi Chris, >>> >>> Thanks for the review. I’ve added one comment below. >>> >>>> On Sep 25, 2016, at 6:27 PM, Chris Lonvick >>>> wrote: >>>> >>>> Hi Dino, >>>> >>>> On 9/25/16 4:37 PM, Dino Farinacci wrote: >>>>>>> I don't follow LISP so I'm not sure if there is an actual >>>>>>> mechanism for a device receiving a map request packet to decline >>>>>>> an offered cipher suite. If there is, I didn't see it explained >>>>>>> in the >>>>> Yes, there is. If the Map-Reply this is returned contains no >>>>> Security LCAF that means to the ITR that it either needs to go >>>>> unencrypted encapsulating packets to the ETR or try another cipher >>>>> text. >>>>> >>>>>>>>> draft. You should address this in a future draft. This will be >>>>>>>>> needed for when new cipher suites are >>>>> Understand the need. We intentionally wanted to support this. >>>>> >>>>>>>>> added and a receiving device does not have the capability to >>>>>>>>> handle the new cipher suite, or the case where an old cipher >>>>>>>>> suite has been administratively disabled; like if it's been >>>>>>>>> compromised and shouldn't be used. There are several ways to >>>>>>>>> do this. >>>>> We have this in section x of the draft. Is it not sufficient? >>>>> >>>>> If an ITR, PITR, or RTR sends a Map-Request with the Security Type >>>>> LCAF included and the ETR or RTR does not want to have >>>>> encapsulated >>>>> traffic encrypted, they will return a Map-Reply with no RLOC >>>>> records >>>>> encoded with the Security Type LCAF. This signals to the ITR, >>>>> PITR >>>>> or RTR not to encrypt traffic (it cannot encrypt traffic anyways >>>>> since no ETR public-key was returned). >>>>> >>>> That text just says that if the cipher suite is declined then there >>>> will be no encryption. I was interpreting that to mean that the >>>> receiver just isn't going to accept any attempt at encryption. If >>>> it's just meant to be for that particular cipher suit then you'll >>>> need to add a line to that paragraph to say that the ITR, PITR, or >>>> RTR can attempt a different cipher suite if it is administratively >>>> configured to do so. However, that could get to be very inefficient >>>> if the ITR has to make 6 attempts before understanding that the ETR >>>> just isn't going to accept any encryption request - if it's so >>>> configured, or if it just doesn't support the feature whatsoever. >>>> So even if you allow the sender to make offer after offer, it would >>>> still be a good idea to have a way for the receiver to entirely >>>> decline encrypting packets from the sender. >>>> >>>> But, with all that being said, I'm figuring that we're getting >>>> outside the intent of your experimental specification. When you do >>>> get around to getting this onto a standards track, then you should >>>> make some decisions around how to convey capabilities between the >>>> sender and receiver so they can quickly and efficiently figure out >>>> what's going to work, or if it's just not, rather than making one >>>> offer after another. TLS and SSH have ways for a sender to offer a >>>> list from which the receiver can choose, if you're looking for >>>> examples. Another way is for the sender to proffer a version number >>>> which is associated with a select group of capabilities. From that, >>>> the receiver can make a choice, or efficiently decline all. >>> Thanks for the suggestions. In this effort we were intentionally >>> avoiding the complexities and added security analysis requirements >>> of a multiple round-trip method capabilities negotiation such as >>> TLS. But maybe a capabilities declaration more along the lines of >>> the version number you suggest might be appropriate. I agree that >>> at such time as the protocol was prepared for standards-track that >>> this would be important to add. >>> >>> Thanks, >>> Brian >>> >>>> Best regards, >>>> Chris >>> -- >>> Brian Weis >>> Security, CSG, Cisco Systems >>> Telephone: +1 408 526 4796 >>> Email: bew@cisco.com >>> > From nobody Tue Sep 27 18:29:02 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BEA12B04E; Tue, 27 Sep 2016 18:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVbTQz34jL4y; Tue, 27 Sep 2016 18:28:58 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 DF66612B3A9; Tue, 27 Sep 2016 18:28:58 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id oz2so10943216pac.2; Tue, 27 Sep 2016 18:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8GZEn0+3+5vypED0i4+frqEI8hSy/D7bLzQAS43PRzI=; b=eB7UEnlVTh91ywOiI47LQyWT3ITY67WM61Cwh3OBnaISWWeJ15XFyK7Epta4IpINaQ 8b8KuXhIx70DwkLD4DWA3FLsu2srWkbHQTPhW8MSl7TMGlAEQMeWDdqwwzXz7yulzI/3 CRVmJNsv9kV7HzZo5Ey3f/RDLKIpgP7F/DRbWh/JJAIj/mWDApjn+SilcZSRy759I76G hvipKxbATg2kDK5x66e2pCm6BFvaOmWUujSv5JwSG0NeGks+vIOj3orJqsUrNymUyfi7 t4idlBB79q/ugg/oFQ6ue8+fAk7MjXeQzrhtmwgbueyLfp8hoAYlcEquI5zyup6tBnxW kyMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8GZEn0+3+5vypED0i4+frqEI8hSy/D7bLzQAS43PRzI=; b=VfK1FZXufN5IJjuklbDbNqJpU2WRLFWTf3pxSRpu0rkSN5jnIgBjWiFYqpyWseQjVU 5BkKhFV/ty/EEn1QJBbGnja4JRpp1ZPIi1zoWHJfTvCITsai6dcugEOY4ARB6J8rHe+D iQ7EdpEi55/4q9vEEPhgb+gRdxbg2zCCiPvdz5yGfu7A9qY60JsJXgyOpdVQkBQlchTp mUBPnICgs12joMqp0Gd0qcOC/hb37vWIkQ3qjUko0uf0u2gfDs/QUlWN5kW6uwdeXCUA DKk+EROa8fqKadKFuupikTNacfMzpRtA41mtg040PpRRo35TzQEmBDE4ezETcyQA2aoj MDrQ== X-Gm-Message-State: AE9vXwMnJ8Mb8KkMl+qwEMcyWpl0ILraknjb5gDl/S9W+ZJgghqWK607An9NBlhFlHFOVg== X-Received: by 10.66.131.74 with SMTP id ok10mr52353748pab.126.1475026138368; Tue, 27 Sep 2016 18:28:58 -0700 (PDT) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by smtp.gmail.com with ESMTPSA id i4sm7589054pav.27.2016.09.27.18.28.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 Sep 2016 18:28:57 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <57EB1C33.60000@gmail.com> Date: Tue, 27 Sep 2016 18:28:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57E68FB7.10408@gmail.com> <57E690AD.2030207@gmail.com> <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com> <57E87980.2050209@gmail.com> <7345DDFF-0D4F-4F47-87D1-56459ED94D2A@cisco.com> <067010BC-5EE7-46AF-B06F-B227BEE9A565@gmail.com> <57E95D87.4090104@gmail.com> <57EB1C33.60000@gmail.com> To: Chris Lonvick X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-lisp-crypto.all@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 01:29:01 -0000 Thanks. I will post -08. Thanks. Dino > On Sep 27, 2016, at 6:26 PM, Chris Lonvick = wrote: >=20 > Resending - Looks like Dino didn't get this. >=20 > Best regards, > Chris >=20 > On 9/26/16 12:40 PM, Chris Lonvick wrote: >> Hi Dino and Brian, >>=20 >> Yup - all looks good. I didn't mean to push too much on the point = because I figured that it wasn't needed or wanted for being an = experimental document. Good luck with it. >>=20 >> Best regards, >> Chris >>=20 >> On 9/26/16 11:47 AM, Dino Farinacci wrote: >>> Chris, if you are fine with Brian=92s response, I can post the -08. = Please ack. Thanks. >>>=20 >>> Dino >>>=20 >>>> On Sep 25, 2016, at 8:11 PM, Brian Weis (bew) = wrote: >>>>=20 >>>> Hi Chris, >>>>=20 >>>> Thanks for the review. I=92ve added one comment below. >>>>=20 >>>>> On Sep 25, 2016, at 6:27 PM, Chris Lonvick = wrote: >>>>>=20 >>>>> Hi Dino, >>>>>=20 >>>>> On 9/25/16 4:37 PM, Dino Farinacci wrote: >>>>>>>> I don't follow LISP so I'm not sure if there is an actual = mechanism for a device receiving a map request packet to decline an = offered cipher suite. If there is, I didn't see it explained in the >>>>>> Yes, there is. If the Map-Reply this is returned contains no = Security LCAF that means to the ITR that it either needs to go = unencrypted encapsulating packets to the ETR or try another cipher text. >>>>>>=20 >>>>>>>>>> draft. You should address this in a future draft. This will = be needed for when new cipher suites are >>>>>> Understand the need. We intentionally wanted to support this. >>>>>>=20 >>>>>>>>>> added and a receiving device does not have the capability to = handle the new cipher suite, or the case where an old cipher suite has = been administratively disabled; like if it's been compromised and = shouldn't be used. There are several ways to do this. >>>>>> We have this in section x of the draft. Is it not sufficient? >>>>>>=20 >>>>>> If an ITR, PITR, or RTR sends a Map-Request with the Security = Type >>>>>> LCAF included and the ETR or RTR does not want to have = encapsulated >>>>>> traffic encrypted, they will return a Map-Reply with no RLOC = records >>>>>> encoded with the Security Type LCAF. This signals to the ITR, = PITR >>>>>> or RTR not to encrypt traffic (it cannot encrypt traffic = anyways >>>>>> since no ETR public-key was returned). >>>>>>=20 >>>>> That text just says that if the cipher suite is declined then = there will be no encryption. I was interpreting that to mean that the = receiver just isn't going to accept any attempt at encryption. If it's = just meant to be for that particular cipher suit then you'll need to add = a line to that paragraph to say that the ITR, PITR, or RTR can attempt a = different cipher suite if it is administratively configured to do so. = However, that could get to be very inefficient if the ITR has to make 6 = attempts before understanding that the ETR just isn't going to accept = any encryption request - if it's so configured, or if it just doesn't = support the feature whatsoever. So even if you allow the sender to make = offer after offer, it would still be a good idea to have a way for the = receiver to entirely decline encrypting packets from the sender. >>>>>=20 >>>>> But, with all that being said, I'm figuring that we're getting = outside the intent of your experimental specification. When you do get = around to getting this onto a standards track, then you should make some = decisions around how to convey capabilities between the sender and = receiver so they can quickly and efficiently figure out what's going to = work, or if it's just not, rather than making one offer after another. = TLS and SSH have ways for a sender to offer a list from which the = receiver can choose, if you're looking for examples. Another way is for = the sender to proffer a version number which is associated with a select = group of capabilities. =46rom that, the receiver can make a choice, or = efficiently decline all. >>>> Thanks for the suggestions. In this effort we were intentionally = avoiding the complexities and added security analysis requirements of a = multiple round-trip method capabilities negotiation such as TLS. But = maybe a capabilities declaration more along the lines of the version = number you suggest might be appropriate. I agree that at such time as = the protocol was prepared for standards-track that this would be = important to add. >>>>=20 >>>> Thanks, >>>> Brian >>>>=20 >>>>> Best regards, >>>>> Chris >>>> --=20 >>>> Brian Weis >>>> Security, CSG, Cisco Systems >>>> Telephone: +1 408 526 4796 >>>> Email: bew@cisco.com >>>>=20 >>=20 >=20 From nobody Tue Sep 27 19:01:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B9512B3B0 for ; Tue, 27 Sep 2016 19:01:40 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXjz3zjIs48S for ; Tue, 27 Sep 2016 19:01:38 -0700 (PDT) Received: from nm18.access.bullet.mail.bf1.yahoo.com (nm18.access.bullet.mail.bf1.yahoo.com [216.109.114.41]) (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 134D612B502 for ; Tue, 27 Sep 2016 19:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1475028095; bh=6n6HTVMRyVCHX4zw9Deg15lIuzTFbiAOQVfRYIVnVdI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From:Subject; b=LEK6sOm3I2/nPPxf5e+ujE/RUHJui+wnA4EA9sxBACiUutYeJYhSrWogf3LNEp/L+CiwoluHxI0/ZsZ12sjfoizq34E1Ab5CyJGi9viwtfOJ1Tw6/FJXMxbRSjwplf5huzfLq9/RVxmRIUghxAQ6D5kibTgy73aL1eCAZnYZScA6q1Mh8hj31ZFTlF8IN4EVgP4HC9362XRMjaY48Dipr+xqHw220sjHaDg8LglDyglOOw8BWW2efFEhgkFpIhw25ENNSv2C7u6oNCvx6vc5Ho/1xDX6Pn1/B07lcWIZz1qecoPmQD+JFNKYmmOob/LWR/hF7J3w+NXVXp6+oqx+Jg== Received: from [66.196.81.156] by nm18.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Sep 2016 02:01:35 -0000 Received: from [98.138.104.97] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Sep 2016 02:01:35 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 28 Sep 2016 02:01:35 -0000 X-Yahoo-Newman-Id: 18211.45320.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: gI37KBQVM1mE5ng.HyiIgIw1llVl0ch_979uVBU2zyhxhyp rWS27QzR9nDnTXFhrxgfAnwHzR_0n3HBFaxHrdQpALuR9uGBVvn4gmssSD7n WsIRJpDkINVzxQ.on1X5hgxAB_ptzTZKRCqCXXOwlAOJekGuwsT2YY5FEP6P iCZIOGpk41CN_Bid_t0OHURxZzg2Y5MAhO0uOEqYc4zxL2qxmgAB1jmk.zsu NKdJxtsJJdxhPps2Af_3yeWawL.0Od5raxTpHBfSlzZ9.iop46GJhc2Sk3_V bwnBVYns8wn_4PgdGCJszcpqOvpWLwFWx.ulaQ2O000JatP20E7XdjP4omVg aW9YrS9QUuxueuOTmBRhL4mDQ3DY.pMnZApU6URJ6qR2k.DU1wJYcieZVXKl NVhiU_L3fGSYCWUp56g.p3BX.xWYRGi9DuPfqz1uk8NVS2RzE7Q.aGGXC9Iq 4oExumy6TregDVEpeIFeNyq0cSQOnOAOgNEKliK7KudkCmk_gFetQY34Wgtn rUTnizQJUzdayYzYlMr8RtsBQLKXrwdURFI_sEarR.l.uj3chV1KrZoIIgwd MpACF.QcEiho- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (209-6-88-55.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.88.55]) by uriel.mandelberg.org (Postfix) with ESMTPSA id E095A1C6033; Tue, 27 Sep 2016 22:01:32 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Tue, 27 Sep 2016 21:01:32 -0500 From: David Mandelberg To: Dino Farinacci In-Reply-To: <2979E792-737A-4027-8B79-7080AB533B9B@gmail.com> References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> <2979E792-737A-4027-8B79-7080AB533B9B@gmail.com> Message-ID: <7d3bf4f189851bcc12b4f659af5b983a@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/1.1.5 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: The IESG , draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 02:01:40 -0000 Sorry, I'm busy with my dayjob. I don't think I'll have time to get to=20 this until the weekend. On 2016-09-27 11:50, Dino Farinacci wrote: > David, any response. Thanks. >=20 > Dino >=20 >> On Sep 26, 2016, at 9:43 AM, Dino Farinacci =20 >> wrote: >>=20 >>> On 09/25/2016 06:15 PM, Dino Farinacci wrote: >>>>> I found one issue in various parts of the document (described=20 >>>>> below), >>>>> but I'm not sure it's relevant to security. If it is, then I think=20 >>>>> this >>>>> document is Almost Ready. If not, then I think this document is=20 >>>>> Ready >>>>> With Nits. >>>>>=20 >>>>> There are multiple places in the document where it's possible to=20 >>>>> encode >>>>> semantically equivalent information in multiple ways, despite the=20 >>>>> word >>>>> "canonical" being in the title of the document. Is there anything=20 >>>>> that >>>>> relies on these addresses being canonical for security purposes? >>>>=20 >>>> No not for security purposes. There are multiple ways because we=20 >>>> allow some nesting of information as well as allow for compatibility= =20 >>>> for older implementations that can=E2=80=99t parse some AFIs and LCA= Fs but=20 >>>> is required to parse the AFI-List LCAF type. >>>=20 >>> Ok, then I think it needs to be made clear in the security >>> considerations that this format cannot be relied on to have no more=20 >>> than >>> one representation for the same information. >>=20 >> Sorry, I am not following your point. The nesting procuedure of LCAFs=20 >> allow the same type of address to be expressed multiple ways. I can=E2= =80=99t=20 >> tell from your commentary if this is a good thing for security or a=20 >> bad thing. So please provide some suggested text on what you would=20 >> like to see in the Security Considerations section. >>=20 >>> IESG: This means that I think this document is Ready With Nits. >>>=20 >>>=20 >>>>> Multiple places in the document (sections 4.1, 4.5, and 4.8)=20 >>>>> specify >>>>> mask lengths, but do not specify that the masked out bits MUST be=20 >>>>> set to >>>>> zero. >>>>=20 >>>> Hmm, by definition, a mask-length of say 24 if a mask of 0xffffff00.= =20 >>>> And in 4.1: >>>>=20 >>>> IID mask-len: if the AFI is set to 0, then this format is not >>>> encoding an extended EID-prefix but rather an instance-ID range >>>> where the 'IID mask-len' indicates the number of high-order bits >>>> used in the Instance ID field for the range. >>>>=20 >>>> It is clear that the high-order bits are used that cover the=20 >>>> mask-length and the low-order bits are ignored. Is this not clear to= =20 >>>> you? >>>=20 >>> That part is clear to me. I just meant that the document as written >>> appears to allow 1.2.3.4/24 to be equivalent to 1.2.3.7/24. If the >>=20 >> I will make this more clear. I added some text. >>=20 >>>> Section 6 (Security Considerations): There is no discussion of these >>>>> addresses being canonical, and what other systems might or might=20 >>>>> not >>>>> rely on these addresses being canonical. >>>>=20 >>>> In this respect =E2=80=9Ccanonical=E2=80=9D is relative to how LISP = defines to=20 >>>> encode both simple AFI encoded addresses or more complex/flexible=20 >>>> addresses that accompany information. >>>=20 >>> Ok. I interpreted canonical to be a security property of the=20 >>> addresses, >>> i.e., that if two addresses are not bytewise equal, then they must=20 >>> not >>> have the same meaning. If that's not what you meant by canonical,=20 >>> then I >>> think the security considerations should say that, so that nobody=20 >>> tries >>> to rely on that property in the future. >>=20 >> Canonical in this spec means semantically canonical. That is the=20 >> following two IP addresses are equal: >>=20 >> AFI=3D1, 1.1.1.1 >> AFI=3DLCAF, lcaf-type=3DAFI-list, AFI=3D1, 1.1.1.1 >>=20 >>>> Section 4.7: The Key Algorithm description doesn't point to a=20 >>>> registry >>>>> of valid values or otherwise say how to interpret values in that=20 >>>>> field. >>>>=20 >>>> We have put that in a use-case document. This Security Key LCAF is=20 >>>> used by 2 use-cases. It is used for LISP-DDT and for lisp-crypto. In= =20 >>>> the lisp-crypto document we have a registry for cipher suites used. >>>=20 >>> Should this document reference one or both of those documents? >>=20 >> I added text to reference the two documents that use this Security Key= =20 >> LCAF Type. >>=20 >> I=E2=80=99ll post a new draft when you get me some text for the Securi= ty=20 >> Considerations section. Thanks! >>=20 >> Dino >>=20 >>>=20 >>>=20 >>> -- >>> David Eric Mandelberg / dseomn >>> http://david.mandelberg.org/ >>>=20 >>=20 --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Tue Sep 27 19:06:20 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E248012B3AC; Tue, 27 Sep 2016 19:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSKT9aFRehkv; Tue, 27 Sep 2016 19:06:16 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e: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 1400412B3A2; Tue, 27 Sep 2016 19:06:16 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id qn7so11251158pac.3; Tue, 27 Sep 2016 19:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PkfTOC8DTt/zI52PQ1D7fX1X6XTlgNlP4N7H9+i7md0=; b=oesHVNUp5XFuGE7C2ZPV4yBWHAZmXCiIEBgVs7lYtiIMZsYDho+19diq5Zo5ftD5Q0 PK0GSpFz9SXZr/uiDIrDhstOftBLgGrhfuTYRwQBK+c+1Vw1n9Fg7E/SkDvvHMjXOoIG 4t/3pnIHrMdevx/0DCPLVx9o4lU7yn2+dA5FRIISbGC4YQ1WYl4Feec8eoJcBqtQ+IjX UsQzPvUSHZHdYa4TRPXwpS3Q+opiNG0hSIf6sBxxOlunvQU7nyFSpf3jBwHFhuip6xrl 6E6frdHYveQrOhTHWtW/XqaOvXXfiDWVWHgmxcm+sJwTGtQSXmKoC07BubyeStXOz2JC 7Mkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PkfTOC8DTt/zI52PQ1D7fX1X6XTlgNlP4N7H9+i7md0=; b=hUvVVkn3l1R7lgV57bBkHM0njUzWI76FJLhOlBQ/irpz6fIhif1q/tpZZ7JJXu9qxn Q+VIApVx6Xf38DBNjTSnfblmKqW6f6JfXzORw1pLEd3A6M85pVS9RKJIIIgjVDvEpkJY x0pSd8DA+zjT+3sZ1M/x3T476arvl8fKBR2SJMdPSUevg+IGt1A7F8TPMT1CIuK0bl0w nfUxBDn9pcvqV25xIDTwAgv0JNzjbaXiOq9WI4Wpi0hSNr1hZJyw5pKYq5SM15JqbCM5 J/Rt/UzzMzkxSBZonno0xTQtXHx9XBpbL+Nbgg7p+witTMOu89Qbf3AmGDD/krSMoTca pVMA== X-Gm-Message-State: AE9vXwPYS98f4e1JEU9maKcYwqa44dXsZPbu8RiQxIhcjb7YCpPCnCX0Ypgw9Yu3DyHp6w== X-Received: by 10.67.23.201 with SMTP id ic9mr52728426pad.143.1475028375594; Tue, 27 Sep 2016 19:06:15 -0700 (PDT) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by smtp.gmail.com with ESMTPSA id sa1sm7683205pac.34.2016.09.27.19.06.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 Sep 2016 19:06:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <7d3bf4f189851bcc12b4f659af5b983a@mail.mandelberg.org> Date: Tue, 27 Sep 2016 19:06:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> <2979E792-737A-4027-8B79-7080AB533B9B@gmail.com> <7d3bf4f189851bcc12b4f659af5b983a@mail.mandelberg.org> To: David Mandelberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: The IESG , draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 02:06:18 -0000 No prob David. Thanks for letting me know a rough ETA. Dino > On Sep 27, 2016, at 7:01 PM, David Mandelberg = wrote: >=20 > Sorry, I'm busy with my dayjob. I don't think I'll have time to get to = this until the weekend. >=20 > On 2016-09-27 11:50, Dino Farinacci wrote: >> David, any response. Thanks. >> Dino >>> On Sep 26, 2016, at 9:43 AM, Dino Farinacci = wrote: >>>> On 09/25/2016 06:15 PM, Dino Farinacci wrote: >>>>>> I found one issue in various parts of the document (described = below), >>>>>> but I'm not sure it's relevant to security. If it is, then I = think this >>>>>> document is Almost Ready. If not, then I think this document is = Ready >>>>>> With Nits. >>>>>> There are multiple places in the document where it's possible to = encode >>>>>> semantically equivalent information in multiple ways, despite the = word >>>>>> "canonical" being in the title of the document. Is there anything = that >>>>>> relies on these addresses being canonical for security purposes? >>>>> No not for security purposes. There are multiple ways because we = allow some nesting of information as well as allow for compatibility for = older implementations that can=E2=80=99t parse some AFIs and LCAFs but = is required to parse the AFI-List LCAF type. >>>> Ok, then I think it needs to be made clear in the security >>>> considerations that this format cannot be relied on to have no more = than >>>> one representation for the same information. >>> Sorry, I am not following your point. The nesting procuedure of = LCAFs allow the same type of address to be expressed multiple ways. I = can=E2=80=99t tell from your commentary if this is a good thing for = security or a bad thing. So please provide some suggested text on what = you would like to see in the Security Considerations section. >>>> IESG: This means that I think this document is Ready With Nits. >>>>>> Multiple places in the document (sections 4.1, 4.5, and 4.8) = specify >>>>>> mask lengths, but do not specify that the masked out bits MUST be = set to >>>>>> zero. >>>>> Hmm, by definition, a mask-length of say 24 if a mask of = 0xffffff00. And in 4.1: >>>>> IID mask-len: if the AFI is set to 0, then this format is not >>>>> encoding an extended EID-prefix but rather an instance-ID range >>>>> where the 'IID mask-len' indicates the number of high-order = bits >>>>> used in the Instance ID field for the range. >>>>> It is clear that the high-order bits are used that cover the = mask-length and the low-order bits are ignored. Is this not clear to = you? >>>> That part is clear to me. I just meant that the document as written >>>> appears to allow 1.2.3.4/24 to be equivalent to 1.2.3.7/24. If the >>> I will make this more clear. I added some text. >>>>> Section 6 (Security Considerations): There is no discussion of = these >>>>>> addresses being canonical, and what other systems might or might = not >>>>>> rely on these addresses being canonical. >>>>> In this respect =E2=80=9Ccanonical=E2=80=9D is relative to how = LISP defines to encode both simple AFI encoded addresses or more = complex/flexible addresses that accompany information. >>>> Ok. I interpreted canonical to be a security property of the = addresses, >>>> i.e., that if two addresses are not bytewise equal, then they must = not >>>> have the same meaning. If that's not what you meant by canonical, = then I >>>> think the security considerations should say that, so that nobody = tries >>>> to rely on that property in the future. >>> Canonical in this spec means semantically canonical. That is the = following two IP addresses are equal: >>> AFI=3D1, 1.1.1.1 >>> AFI=3DLCAF, lcaf-type=3DAFI-list, AFI=3D1, 1.1.1.1 >>>>> Section 4.7: The Key Algorithm description doesn't point to a = registry >>>>>> of valid values or otherwise say how to interpret values in that = field. >>>>> We have put that in a use-case document. This Security Key LCAF is = used by 2 use-cases. It is used for LISP-DDT and for lisp-crypto. In the = lisp-crypto document we have a registry for cipher suites used. >>>> Should this document reference one or both of those documents? >>> I added text to reference the two documents that use this Security = Key LCAF Type. >>> I=E2=80=99ll post a new draft when you get me some text for the = Security Considerations section. Thanks! >>> Dino >>>> -- >>>> David Eric Mandelberg / dseomn >>>> http://david.mandelberg.org/ >=20 > --=20 > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ From nobody Wed Sep 28 08:44:42 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F8412B05F; Wed, 28 Sep 2016 08:44:34 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGOoZEz31Wxx; Wed, 28 Sep 2016 08:44:31 -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 E8F3412B1D0; Wed, 28 Sep 2016 08:44:29 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8SFiNJB026355 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Sep 2016 18:44:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8SFiLoL020661; Wed, 28 Sep 2016 18:44:21 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22507.58709.941032.954739@fireball.acr.fi> Date: Wed, 28 Sep 2016 18:44:21 +0300 From: Tero Kivinen To: In-Reply-To: <2079549486.943099.1474297035246@mail.yahoo.com> References: <22495.62038.771947.984586@fireball.acr.fi> <2079549486.943099.1474297035246@mail.yahoo.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 11 min Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 15:44:35 -0000 nalini.elkins@insidethestack.com writes: > Thank you for your comments. We will review and get back to you on them later > today. But, first, let me address one thing which may be a misunderstanding > of PDM. > > 1. PDM is OFF initially at the end hosts (client and server) OFF meaning, that must be explictly turned on in both ends, or off, meaning we do not send them, but we respond to them if other end sends them? > 2. It is turned ON for diagnostics then turned OFF afterwards. If someone > chooses to leave PDM ON always, then that is explicitly chosen for their > network. I do not see any warning about that in the draft. Draft says in section 3.6, that there must be default configuration parameter, but does not provide default value for it. > 3. PDM is an OPTIONAL feature. One may choose not to implement it at all. True, but even the optional features can be used to attack systems, and if we do not expect vendors to implement it, and because of that it will be safe, then why are we even specifying it. > To address some of your comments about leakage, etc. > > Let's discuss how this might happen: > > 1. Attacker obtains access to either or both end host client and server and > turns on PDM > > 2. Attacker watches passively. > > Actually the problem is 1. If you have done that, what do you need PDM for? > Many other things can be found - such as type of device, etc without resorting > to PDM. Or third option: attacker takes packet from A, and modifies the ESP packets and inserts PDM header and sends them to B. B thinks A has turned on PDM, and unless it is explictly forbidden by policy might think that it should respond to the packets with PDM headers, especially as section 3.5 says that PDM SHOULD be turned on by each stack on a host node. Now the host B starts sending PDM headers to host A, and if host A does same, i.e., sees that host A has turned PDM on, turns it also on, then attackers can identify that flow immediately. This is one packet active attack against traffic flow confidentiality of the ESP. The correct fix for this is to make sure that PDM option headers are only inserted after the ESP header, i.e., in the encrypted and authenticated part of the packet. > ------------------------------------------------------------------------------ > From: Tero Kivinen > To: iesg@ietf.org; secdir@ietf.org; > draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org > Sent: Monday, September 19, 2016 7:12 AM > Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-05 > > 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 document describes adding new IPv6 destination option header to > allow performance metrics calculations. > > I think this document has serious issues. > > It proposes that the new Destination option MUST be put before the ESP > so it is sent in clear. This will leak out the traffic information > from the ESP, allowing easy traffic analysis of encrypted packets, as > passive attacker can see which encrypted ESP packets belong to which > 5-tuple flow. The PDM option header includes the incrementing sequence > numbers, so checking those will allow see which packet belongs to > which flow. > > It claims that PDM MUST be placed before the ESP header in order to > work, which is untrue. This is destination option, thus it is meant to > be checked on the destination host, i.e., the packet capture after the > ESP decryption will allow seeing the PDM header values without issues. > > -- > > Also the Time Base definations seem to be inconsistent. The section > 3.2 says: > > That is, for a value of 00 in the Time Base field, a value of 1 in > the DELTA fields indicates 1 microsecond. > > Section 4.4 on other hand claims: > > That is, for a value of 00 in the Time Base field, a value of 1 in > the DELTA fields indicates 1 picosecond. > > On the other hand looking at the table in both 3.2 and 4.4 it seems > that time base value field value of 00 means milliseconds, not > microseconds or picoseconds. > > Again section 4.5 says that "TimeBase of picosecond (or 00)", and > again I think picoseconds was supposed to be Time Base of 11... > > The whole section 4 seems to be wierd. It is talking about different > encodings, and time units on different systems, and it also talks > about the limitations on TCP Timestamp Option, but this option uses > different encoding so I have no idea why this text is here. It would > be more useful to count what are the limits on the encoding method > used here (16 bit value, 7 bit signed scaling value), instead of what > some other option use. > > In section 5.3 in the example it converts 4 seconds to hex value of > 3A35 and scale of 25. On the other hand it is using milliseconds as > Time Base, so I think those values are wrong, i.e. 4 seconds in > milliseconds is 4000 milliseconds, thus FA0 with scale of 0 would be > correct represetnation. Same mistake in 5.4. > > -- > > I skipped most of the section 6 and 7, so cannot say if similar > mistakes are in those sections. > > -- > > The section 8 is wrong as it claims > > "PDM does not introduce any new security weakness." > > while this will leak lots of information about the traffic flows > inside the encrypted transport mode ESP packets. > > Also another thing the PDM leaks is exact host timings, i.e., it can > be used to launch timing attacks against crypto protocols. In general > those are hard as it is very hard to know how much of n ms rtt is > network delay and how much was the actual host processing the packet. > Now if we can see that that host used 123 nanoseconds to process the > signature verification packet, and next time it uses 1755 nanoseconds, > this might allow attacker to get information out from the key. The > actual round trip times might have been 123 ms in both cases, and the > 1 microsecond difference in the processing time would have been lost > by the network latencies. > > In addition to that the abstract is not very clear, it does not do > very good job of telling that this draft tries to do, and having the > Background section to duplicate most of that text does not still what > this document really tries to do. > -- > kivinen@iki.fi > -- kivinen@iki.fi From nobody Wed Sep 28 09:21:02 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF05712B1F5; Wed, 28 Sep 2016 09:21:00 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdChhqZsnB4n; Wed, 28 Sep 2016 09:20:59 -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 A829D12B0FA; Wed, 28 Sep 2016 09:20:58 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8SGKsUa014782 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Sep 2016 19:20:54 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8SGKrG6029638; Wed, 28 Sep 2016 19:20:53 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22507.60901.665544.878052@fireball.acr.fi> Date: Wed, 28 Sep 2016 19:20:53 +0300 From: Tero Kivinen To: In-Reply-To: <1264225155.363685.1474644268281@mail.yahoo.com> References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 35 min X-Total-Time: 35 min Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 16:21:00 -0000 nalini.elkins@insidethestack.com writes: > Thanks for your comments. We have posted a new draft with corrections at: > https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-06 > > Our responses inline. > > Nalini Elkins > > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > > ________________________________ > From: Tero Kivinen > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org > Sent: Monday, September 19, 2016 7:12 AM > Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-05 > > >I think this document has serious issues. > > >It proposes that the new Destination option MUST be put before the ESP > >so it is sent in clear. This will leak out the traffic information > >from the ESP, allowing easy traffic analysis of encrypted packets, as > >passive attacker can see which encrypted ESP packets belong to which > >5-tuple flow. The PDM option header includes the incrementing sequence > >numbers, so checking those will allow see which packet belongs to > >which flow. > > > It is not clear to me how knowing which ESP packets belong to which > traffic flow helps a passive attacker. The attacker still does not > know what is in the packet - the contents of the payload. Indeed, > ESP would normally mask TCP or UDP ports. With PDM you can tell > that there ARE multiple flows but you don't know if they are TCP, > UDP, ICMP or anything else. Most importantly, you don't know what > is in the payload. Sometimes that is only what is needed, and ESP tries to provide protection against traffic flow confidentiality, and this option breaks it. For example finding out that this flow of packets is the control traffic of the video stream, and this other flow of packets is the actual video stream, the attacker can for example block the control traffic, and make it so that user on the other end cannot stop the video feed. Or if there is 3 simultaneous video streams going out, it is much harder to identify which video stream is what TV-program. If you can separate them to 3 different video streams, it is much easier to identify the actual video being watched by checking the packet lengths. There are most likely also other kind of attacks, and as this is service as ESP provides, it is not for PDM to break it unless you explictly spell it out that this is meant to break property of the ESP. > If one follows the thinking of your objection, isn't any encrypted > flow over TCP or UDP a problem since a passive attacker knows the > 5-tuple for such flows? For example, all TLS flows can be analyzed > for traffic in your sense. So, a flow over TLS (without PDM) > actually leaks more information than an ESP flow WITH PDM. Because > with TLS, we even know that the flow is TCP and the port number. > Neither of which you know with PDM with ESP. Yes. And to fix that issue, people use IPsec which will hide the information about separate TCP and UDP flows. And now with PDM the IPsec will not provide that service anymore. > >It claims that PDM MUST be placed before the ESP header in order to > >work, which is untrue. This is destination option, thus it is meant to > >be checked on the destination host, i.e., the packet capture after the > >ESP decryption will allow seeing the PDM header values without issues. You did not respond to this part, i.e., why is the PDM header outside the ESP encrypted part, and why it is not inside the ESP? It is supposed to be destination option, which is only meaningful to the final destination of the packet, thus it can easily be inside the ESP protection, as the final destination do know the keys etc will see the decrypted option header. > >The whole section 4 seems to be wierd. It is talking about different > >encodings, and time units on different systems, and it also talks > >about the limitations on TCP Timestamp Option, but this option uses > >different encoding so I have no idea why this text is here. It would > >be more useful to count what are the limits on the encoding method > >used here (16 bit value, 7 bit signed scaling value), instead of what > > >some other option use. > > Thanks. Should now be fixed. What is the meaning of the section 4? It is good background information, and might be moved to the appendix, but I do not think it belongs here. It has text that mostly covers other formats, not the format used here. Also it does not really specify what does negative scaling values mean, and when are they used. If I understand correctly the actual timevalue conversion is so that delta_time = delta_time_from_packet * 2^Scale where delta_time_from_packet is between 0x0000 and 0xffff, and scale is between -127 and 128, and the units are either milliseconds, microseconds, nanoseconds or picoseconds. So the smallist time we can express with this is delta_time_from_packet = 0x0001 scale = -127 unit = 11 = picoseconds delta_time = 0.0000000000000000000000000000000000000058 picoseconds = .0000000000000000000000000058 joktoseconds == 5.8 * 10^-51 seconds and the maximum value is delta_time_from_packet = 0xffff scale = 128 unit = 00 = milliseconds delta_time = 22300404916163702203072254898040929737768960 milliseconds = 707141201045272139874183628172277 years... so the range is definately enough. The question is that if the scale is from -127 to 128, why do we even need the Time Base? > >The section 8 is wrong as it claims > > > "PDM does not introduce any new security weakness." > > >while this will leak lots of information about the traffic flows > >inside the encrypted transport mode ESP packets. > > Please see above. Leaking this information is new security weakness for the protocol, which was designed to protect against those attacks. > >Also another thing the PDM leaks is exact host timings, i.e., it can > >be used to launch timing attacks against crypto protocols. In general > >those are hard as it is very hard to know how much of n ms rtt is > >network delay and how much was the actual host processing the packet. > >Now if we can see that that host used 123 nanoseconds to process the > >signature verification packet, and next time it uses 1755 nanoseconds, > >this might allow attacker to get information out from the key. The > >actual round trip times might have been 123 ms in both cases, and the > >1 microsecond difference in the processing time would have been lost > >by the network latencies. > > > > 1. The intent of PDM is as a diagnostic feature. PDM is OFF > initially at the end hosts (client and server). It is turned ON for > diagnostics and then turned OFF afterwards. If someone chooses to > leave PDM ON always, then that is explicitly chosen. Also, PDM is > an OPTIONAL feature. Either client or server operating system may > choose not to implement it or use it. The draft disagrees with this. It says there is configuration option for it, but does not give default value for it, and says: 3.5 Implementation Considerations The PDM destination options extension header SHOULD be turned on by each stack on a host node. It MAY also be turned on only in case of diagnostics needed for problem resolution. so it seems it is on by default. > 2. In your example above, it assumes that the signature verification > packet (please let me know which exact packet and protocol you are > referring to) is passing in the clear so that the attacker knows > that it is the signature verification packet. Possibly this is also > a problem. Key management packets are usually in clear, as they are there before we have the actual keys we can use to protect the messages. Also it is not very difficult to guess that 3rd and 4th message in port 500, are the IKE AUTH packets, which will contain signatures. Same thing with TLS. Attackers will knows which packets contain signatures. Currently attackers usually send those signature packets themselves, and measure the time it takes for the device to calculate response. They can also send garbage packets, and detect how far in checking the packets got by checking how long it took for the other end to send error message back. All this kind of timing attacks are usually considered hard, as the network delays cause big jitter on the timings, and they need to try multiple times, and average the response times to get the information they need. This method will provide them easy way to bypass that issue. > 3. Protocols often use blinding techniques to remove correlations > between key and encryption time. Other cryptographic algorithms > can be implemented (or masked by a proxy) in a way that reduces or > eliminates data dependent timing information. So if timing > information is being leaked, this is a flaw in the algorithm or the > protocol. In this case, we may be "blaming the messenger". PDM is > only reporting what is done. The algorithm or protocol is the > problem. Yes. This option makes it easy for the attacker to use those broken algorithms, protocols and implementations. This is again new security weakness that this option opens. It was harder before, after this it is easier. > >In addition to that the abstract is not very clear, it does not do > >very good job of telling that this draft tries to do, and having the > >Background section to duplicate most of that text does not still what > > >this document really tries to do. > > If you can give me a hint as to what is not clear or what you think > this draft DOES propose, then we will be happy to rewrite the > abstract / background section. My current take is that this option proposes and attack vector against several different protocols, and as such it does quite good job... I have a feeling that this is not for which this draft was meant to do. -- kivinen@iki.fi From nobody Thu Sep 29 01:23:54 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABD412B08D; Thu, 29 Sep 2016 01:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.935 X-Spam-Level: X-Spam-Status: No, score=-4.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATl4uX1SItqz; Thu, 29 Sep 2016 01:23:50 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1AB12B0D5; Thu, 29 Sep 2016 01:23:50 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id B29C240CDB; Thu, 29 Sep 2016 10:23:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 7236C1C007A; Thu, 29 Sep 2016 10:23:48 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0301.000; Thu, 29 Sep 2016 10:23:48 +0200 From: To: Carl Wallace , "draft-ietf-radext-ip-port-radius-ext.all@ietf.org" Thread-Topic: secdir review of draft-ietf-radext-ip-port-radius-ext-10 Thread-Index: AQHR9y8WtZ0vGD0hKEW1b5wyWWx0naCQT4TA Date: Thu, 29 Sep 2016 08:23:47 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008E21F9D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-radext-ip-port-radius-ext-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 08:23:52 -0000 RGVhciBDYXJsLCANCg0KKEFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5IHRvIGFuc3dlciB0aGlzIG1l c3NhZ2UpLg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgcmV2aWV3Lg0KDQpQbGVhc2Ug c2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t LS0tDQo+IERlwqA6IENhcmwgV2FsbGFjZSBbbWFpbHRvOmNhcmxAcmVkaG91bmRzb2Z0d2FyZS5j b21dDQo+IEVudm95w6nCoDogbHVuZGkgMTUgYW/Du3QgMjAxNiAyMTo1Ng0KPiDDgMKgOiBkcmFm dC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQuYWxsQGlldGYub3JnDQo+IENjwqA6IGll c2dAaWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9yZw0KPiBPYmpldMKgOiBzZWNkaXIgcmV2aWV3IG9m IGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC0xMA0KPiANCj4gSSBoYXZlIHJl dmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUn cw0KPiBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZCBieSB0aGUgSUVTRy4NCj4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1h cmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWENCj4gZGlyZWN0b3JzLiBE b2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRz IGp1c3QNCj4gbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiANCj4gVGhpcyBk b2N1bWVudCBkZWZpbmVzIHRocmVlIG5ldyBSQURJVVMgYXR0cmlidXRlcy4gIEZvciBkZXZpY2Vz IHRoYXQNCj4gaW1wbGVtZW50IElQIHBvcnQgcmFuZ2VzLCB0aGVzZSBhdHRyaWJ1dGVzIGFyZSB1 c2VkIHRvIGNvbW11bmljYXRlIHdpdGggYQ0KPiBSQURJVVMgc2VydmVyIGluIG9yZGVyIHRvIGNv bmZpZ3VyZSBhbmQgcmVwb3J0IFRDUC9VRFAgcG9ydHMgYW5kIElDTVANCj4gaWRlbnRpZmllcnMs IGFzIHdlbGwgYXMgbWFwcGluZyBiZWhhdmlvciBmb3Igc3BlY2lmaWMgaG9zdHMuDQo+IA0KPiAN Cj4gSSd2ZSBhIGZldyBxdWVzdGlvbnMvY29tbWVudHM6DQo+IA0KPiAtIFRoZSBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBzZWN0aW9uIGN1cnJlbnRseSByZWZlcmVuY2VzIHRoZSBzZWN1cml0eQ0K PiBjb25zaWRlcmF0aW9ucyBmcm9tIDI4NjUgYW5kIDUxNzYuICBTaG91bGQgNjg4NyBiZSBpbmNs dWRlZCB0byBhZGRyZXNzDQo+IGNvbnNpZGVyYXRpb25zIHJlbGF0ZWQgdG8gdGhlIGZvcndhcmRp bmcgYXR0cmlidXRlPw0KDQpbTWVkXSBSZWZlcnJpbmcgdG8gdGhlIFBDUCBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBtYXkgbm90IGJlIGp1c3RpZmllZCBoZXJlIGdpdmVuIHRoYXQgdGhlIFJBRElV UyBjbGllbnQgYW5kIHNlcnZlciBhcmUgaW4gdGhlIHNhbWUgdHJ1c3QgZG9tYWluLiBXZSBoYXZl IHRoaXMgdGV4dCBpbiB0aGUgZHJhZnQgZm9yIHRoaXMgcG9pbnQ6DQoNCiAgIFRoaXMgZG9jdW1l bnQgdGFyZ2V0cyBkZXBsb3llZCB3aGVyZSBhIHRydXN0ZWQgcmVsYXRpb25zaGlwIGlzIGluDQog ICBwbGFjZSBiZXR3ZWVuIHRoZSBSQURJVVMgY2xpZW50IGFuZCBzZXJ2ZXIgd2l0aCBjb21tdW5p Y2F0aW9uDQogICBvcHRpb25hbGx5IHNlY3VyZWQgYnkgSVBzZWMgb3IgVHJhbnNwb3J0IExheWVy IFNlY3VyaXR5IChUTFMpDQogICBbUkZDNjYxNF0uDQoNCj4gLSBXaGVuIHRoZSBwb3J0IGxpbWl0 IGF0dHJpYnV0ZSBpcyB1c2VkLCBkb2VzIHByZXNlbnRhdGlvbiBvZiBhIG5ldw0KPiAiZ2xvYmFs IiBzZXR0aW5nIHVuZG8gcHJldmlvdXNseSBlc3RhYmxpc2hlZCBJUCBzcGVjaWZpYyBzZXR0aW5n cyAob3IgdmljZQ0KPiB2ZXJzYSk/DQoNCltNZWRdIEknbSBub3Qgc3VyZSB0byB1bmRlcnN0YW5k IHRoZSBxdWVzdGlvbiBoZXJlLiBCdXQsIA0KKiBpZiB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB0 aGUgbmV3IGxpbWl0IHJlcGxhY2VzIHRoZSBvbmUsIHRoZSBhbnN3ZXIgaXMgeWVzLiANCiogaWYg dGhlIHF1ZXN0aW9uIGlzIGhvdyB0aGUgbmV3IGxpbWl0IGlzIGFwcGxpZWQgaWYgYWxpdmUgc2Vz c2lvbnMgZm9yIGEgZ2l2ZW4gc3Vic2NyaWJlciBleGNlZWQgdGhlIG5ldyBsaW1pdCwgdGhlIGFu c3dlciBpcyB0aGlzIGlzIGltcGxlbWVudGF0aW9uLXNwZWNpZmljLiBBIENHTiBoYXMgdG8gZGVh bCB3aXRoIHRoYXQgYW55IHdheSAoc2VlIHRoaXMgUkVRIGZyb20gUkZDNjg4OCkuIFdlIGRlZmVy IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBiZWhhdmlvci4gDQoNCj09PQ0KDQogICBSRVEtNDogIEEg Q0dOIE1VU1Qgc3VwcG9ydCBsaW1pdGluZyB0aGUgbnVtYmVyIG9mIGV4dGVybmFsIHBvcnRzIChv ciwNCiAgICAgIGVxdWl2YWxlbnRseSwgImlkZW50aWZpZXJzIiBmb3IgSUNNUCkgdGhhdCBhcmUg YXNzaWduZWQgcGVyDQogICAgICBzdWJzY3JpYmVyLg0KDQogICAgICBhLiAgUGVyLXN1YnNjcmli ZXIgbGltaXRzIE1VU1QgYmUgY29uZmlndXJhYmxlIGJ5IHRoZSBDR04NCiAgICAgICAgICBhZG1p bmlzdHJhdG9yLg0KDQogICAgICBiLiAgUGVyLXN1YnNjcmliZXIgbGltaXRzIE1BWSBiZSBjb25m aWd1cmFibGUgaW5kZXBlbmRlbnRseSBwZXINCiAgICAgICAgICB0cmFuc3BvcnQgcHJvdG9jb2wu DQoNCiAgICAgIGMuICBBZGRpdGlvbmFsbHksIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIENH TiBpbmNsdWRlDQogICAgICAgICAgYWRtaW5pc3RyYXRvci1hZGp1c3RhYmxlIHRocmVzaG9sZHMg dG8gcHJldmVudCBhIHNpbmdsZQ0KICAgICAgICAgIHN1YnNjcmliZXIgZnJvbSBjb25zdW1pbmcg ZXhjZXNzaXZlIENQVSByZXNvdXJjZXMgZnJvbSB0aGUgQ0dODQogICAgICAgICAgKGUuZy4sIHJh dGUtbGltaXQgdGhlIHN1YnNjcmliZXIncyBjcmVhdGlvbiBvZiBuZXcgbWFwcGluZ3MpLg0KDQog ICBKdXN0aWZpY2F0aW9uOiAgQSBDR04gY2FuIGJlIGNvbnNpZGVyZWQgYSBuZXR3b3JrIHJlc291 cmNlIHRoYXQgaXMNCiAgICAgIHNoYXJlZCBieSBjb21wZXRpbmcgc3Vic2NyaWJlcnMuICBMaW1p dGluZyB0aGUgbnVtYmVyIG9mIGV4dGVybmFsDQogICAgICBwb3J0cyBhc3NpZ25lZCB0byBlYWNo IHN1YnNjcmliZXIgbWl0aWdhdGVzIHRoZSBkZW5pYWwtb2Ytc2VydmljZQ0KICAgICAgKERvUykg YXR0YWNrIHRoYXQgYSBzdWJzY3JpYmVyIGNvdWxkIGxhdW5jaCBhZ2FpbnN0IG90aGVyDQogICAg ICBzdWJzY3JpYmVycyB0aHJvdWdoIHRoZSBDR04gaW4gb3JkZXIgdG8gZ2V0IGEgbGFyZ2VyIHNo YXJlIG9mIHRoZQ0KICAgICAgcmVzb3VyY2UuICBJdCBlbnN1cmVzIGZhaXJuZXNzIGFtb25nIHN1 YnNjcmliZXJzLiAgTGltaXRpbmcgdGhlDQogICAgICByYXRlIG9mIGFsbG9jYXRpb24gbWl0aWdh dGVzIGEgc2ltaWxhciBhdHRhY2sgd2hlcmUgdGhlIENQVSBpcyB0aGUNCiAgICAgIHJlc291cmNl IGJlaW5nIHRhcmdldGVkIGluc3RlYWQgb2YgcG9ydCBudW1iZXJzLiAgSG93ZXZlciwgdGhpcw0K ICAgICAgcmVxdWlyZW1lbnQgaXMgbm90IGEgTVVTVCBiZWNhdXNlIGl0IGlzIHZlcnkgaGFyZCB0 byBleHBsaWNpdGx5DQogICAgICBjYWxsIG91dCBhbGwgQ1BVLWNvbnN1bWluZyBldmVudHMuDQo9 PQ0KDQo+IC0gU2hvdWxkIHRoZSBJUC1Qb3J0LVJhbmdlIGF0dHJpYnV0ZSByZXF1aXJlIGF0IGxl YXN0IG9uZSBvZg0KPiBJUC1Qb3J0LUV4dC1JUHY0LUFkZHIgb3IgSVAtUG9ydC1Mb2NhbC1JZCB0 byBiZSBwcmVzZW50Pw0KDQpbTWVkXSBOby4gVGhpcyBpcyBkZXBsb3ltZW50IHNwZWNpZmljLiBG b3IgZXhhbXBsZSwgYSBDUEUgdGhhdCByZXBvcnRzIHRoZSBhbGxvY2F0aW9uIG9mIGEgcG9ydCBy YW5nZSB0byBhIHZpc2l0aW5nIGhvc3QgaXMgbm90IHJlcXVpcmVkIHRvIGluY2x1ZGUgdGhlIGV4 dGVybmFsIElQIGFkZHJlc3MgZ2l2ZW4gdGhpcyBpbmZvcm1hdGlvbiBpcyBhbHJlYWR5IGtub3du IHRvIHRoZSBSQURJVVMgc2VydmVyIChlLmcuLCBGaWd1cmUgMjApLiBCdXQgYSBEUy1MaXRlIEFG VFIgdGhhdCBhbGxvY2F0ZXMgYSBwb3J0IHJhbmdlIG1heSBzZW5kIGEgbm90aWZpY2F0aW9uIG1l c3NhZ2UgdG8gaW5mb3JtIHRoZSBSQURJVVMgc2VydmVyIGFib3V0IGEgbmV3IGFsbG9jYXRlZCBw b3J0IHJhbmdlLCB0aGlzIG1lc3NhZ2Ugd2lsbCBpbmNsdWRlIHRoZSBleHRlcm5hbCBJUHY0IGFk ZHJlc3MgKElQLVBvcnQtRXh0LUlQdjQtQWRkcikgYW5kIHRoZSBzb2Z0d2lyZSBJUHY2IGFkZHJl c3MgKElQLVBvcnQtTG9jYWwtSWQpDQoNCiBIb3cgaXMgdGhlDQo+IGF0dHJpYnV0ZSB1c2VkIHdo ZW4gYm90aCBhcmUgYWJzZW50Pw0KDQpbTWVkXSBUaGUgdGV4dCBzYXlzIHRoZSBmb2xsb3dpbmc6 IA0KDQogICBJZiB0aGUgSVAtUG9ydC1FeHQtSVB2NC1BZGRyIFRMViBpcyBpbmNsdWRlZCBhcyBw YXJ0IG9mIHRoZSBJUC1Qb3J0LQ0KICAgUmFuZ2UgQXR0cmlidXRlLCB0aGUgcG9ydCByYW5nZSBh cyBzcGVjaWZpZWQgaXMgYXNzb2NpYXRlZCB3aXRoIElQdjQNCiAgIGFkZHJlc3MgYXMgaW5kaWNh dGVkLCBidXQgb3RoZXJ3aXNlIGlzIGZvciBhbGwgSVB2NCBhZGRyZXNzZXMgYnkgdGhlDQogICAg ICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXg0KICAgcG9ydCBkZXZpY2UgKGUuZy4sIGEgQ0dOIGRldmljZSkgZm9yIHRoZSBl bmQgdXNlci4NCiAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eDQoNCk5vIG5lZWQgdG8gaGF2ZSBleHBsaWNpdCB0ZXh0IGFib3V0IHRoZSBhYnNlbmNl IG9mIElQLVBvcnQtTG9jYWwtSWQgYXMgd2UgdGhvdWdodCB0aGlzIG9idmlvdXNseSBtZWFucyBu byBleHRyYSBpZGVudGlmaWVyIGlzIHJlcXVpcmVkLg0KDQo+IC0gVGhlIHN1bW1hcnkgc3RhdGVt ZW50IGFzc29jaWF0ZWQgd2l0aCB0aGUgYXR0cmlidXRlcyBpbiBzZWN0aW9uIDEgbWlnaHQNCj4g YmVuZWZpdCBmcm9tIGluZGljYXRpbmcgdGhlIHB1cnBvc2Ugb2YgdGhlIGF0dHJpYnV0ZSByZWxh dGl2ZSB0byBlYWNoDQo+IHBhY2tldCB0eXBlIGluIHdoaWNoIGl0IG1heSBhcHBlYXIgKGZvciBl eGFtcGxlLCB0aGUgcHVycG9zZSBvZiBhIHBvcnQNCj4gbGltaXQgaW5mbyBhdHRyaWJ1dGUgaXMg ZGlmZmVyZW50IHdoZW4gaW5jbHVkZWQgaW4gYW4gQWNjZXNzLVJlcXVlc3QgdGhhbg0KPiBpbiBh biBBY2Nlc3MtUmVzcG9uc2UpLg0KDQpbTWVkXSBJTUhPIHRoaXMgaXMgcmVkdW5kYW50IHdpdGgg dGhlIGNvbnRlbnQgb2YgU2VjdGlvbiA1LiANCg0KPiAtIEVhY2ggYXR0cmlidXRlIGxpc3RzIGFw cGxpY2FibGUgcGFja2V0IHR5cGVzIGFuZCBpbmRpY2F0ZXMgdGhlIGF0dHJpYnV0ZQ0KPiBtdXN0 IG5vdCBhcHBlYXIgaW4gYW55IG90aGVyIHBhY2tldCB0eXBlLiBJdCBtYXkgYmUgd29ydGggYWRk aW5nIGEgbm90ZSB0bw0KPiBjbGFyaWZ5IHdoYXQgc2hvdWxkIGhhcHBlbiBpZiB0aGUgYXR0cmli dXRlIGRvZXMgYXBwZWFyIChhc3N1bWluZyBpZ25vcmUpLg0KDQpbTWVkXSBUaGlzIGlzIGNvdmVy ZWQgaW4gU2VjdGlvbiA1LiANCg0KPiAtIFRoZSBVRSBhY3JvbnltIG9uIHBhZ2UgMzAgc2hvdWxk IGJlIGV4cGFuZGVkLg0KDQpbTWVkXSBXaWxsIGJlIGZpeGVkLg0KDQo+IC0gSW4gMy4xLjIsIGNo YW5nZSAiYXJlIHByZXZpb3VzbHkgYWxsb2NhdGVkIiB0byAid2VyZSBwcmV2aW91c2x5DQo+IGFs bG9jYXRlZCIuDQoNCltNZWRdIFdpbGwgYmUgZml4ZWQuIFRoYW5rIHlvdSBmb3IgY2F0Y2hpbmcg dGhpcy4NCg0KPiAtIEluIDQuMS4zLCBpcyAiUkFESVVTIGFzc29jaWF0ZSIgYSBjb21tb25seSB1 c2VkIHRlcm0/IFRoaXMgc2VlbXMgbGlrZSBhDQo+IHJlcXVpcmVtZW50IG9uIHVzZSB3aXRoIENv QS1SZXF1ZXN0cyB0aGF0IHNob3VsZCBiZSBtZW50aW9uZWQgZWFybGllci4NCj4gDQoNCltNZWRd IFdpbGwgYmUgY2hhbmdlZCB0byAiUkFESVVTIGFzc29jaWF0aW9uIi4NCg0K From nobody Thu Sep 29 03:18:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E03312B3FA for ; Thu, 29 Sep 2016 03:18:21 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bfye6abqhiR3 for ; Thu, 29 Sep 2016 03:18:19 -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 E557012B405 for ; Thu, 29 Sep 2016 03:18:18 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8TAIDM4024229 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 29 Sep 2016 13:18:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8TAIDut023994; Thu, 29 Sep 2016 13:18:13 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22508.60005.666164.557710@fireball.acr.fi> Date: Thu, 29 Sep 2016 13:18:13 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 10:18:21 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Eric Osterweil is next in the rotation. For telechat 2016-09-29 Reviewer LC end Draft Dan Harkins T 2016-09-21 draft-ietf-pals-rfc4447bis-05 Warren Kumari T 2016-09-28 draft-ietf-ipsecme-ddos-protection-09 Sandy Murphy T 2016-08-12 draft-ietf-tsvwg-gre-in-udp-encap-18 Radia Perlman TR2016-08-15 draft-ietf-i2rs-protocol-security-requirements-14 Carl Wallace TR2016-08-11 draft-ietf-radext-ip-port-radius-ext-12 For telechat 2016-10-13 Matt Lepinski T 2016-09-29 draft-ietf-ipsecme-safecurves-04 Sandy Murphy T 2016-10-10 draft-ietf-regext-epp-rdap-status-mapping-01 Magnus Nystrom T 2016-10-11 draft-ietf-webpush-protocol-10 Takeshi Takahashi TR2016-05-31 draft-ietf-tsvwg-rfc5405bis-17 Tina TSOU T 2016-08-15 draft-ietf-ospf-two-part-metric-09 Dacheng Zhang T 2016-08-22 draft-ietf-core-http-mapping-14 For telechat 2016-10-27 Yoav Nir TR2016-10-24 draft-weis-gdoi-iec62351-9-08 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Warren Kumari 2016-09-06 draft-sweet-rfc2911bis-11 Catherine Meadows 2016-09-30 draft-ietf-opsawg-capwap-alt-tunnel-08 Matthew Miller 2016-10-06 draft-ietf-stox-7248bis-12 Yoav Nir 2016-10-10 draft-ietf-straw-b2bua-rtcp-13 Hilarie Orman 2016-10-11 draft-ietf-l3sm-l3vpn-service-model-16 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-15 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-06 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-09 -- kivinen@iki.fi From nobody Fri Sep 30 11:36:36 2016 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 7011D12B1CE; Fri, 30 Sep 2016 11:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1475258644; bh=t7RbSFo0Yebs9a7MekeirUj/rF3Yi7GPC1OJoyBPIJ8=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=pkLGpAhco/6utfAi1ArzYtwB7a+zr44AOoVRuIZ3aPGZ6YlbQ+746jgrEtR6jWqml RpuyF6smTFV48ANUSG9SFlPUDPiHT681Px3Wto8SBqBjTy7b8vhLkS9NVxW7DVlVUC dJ3q70522oWysWkQsCgnAZz/AGyszzxVjpbZwXdI= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B06E12B1BB for ; Fri, 30 Sep 2016 11:03:58 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <147525863817.20417.13238595241972385037.idtracker@ietfa.amsl.com> Date: Fri, 30 Sep 2016 11:03:58 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 11:36:34 -0700 Subject: [secdir] [new-work] WG Review: SIDR Operations (sidrops) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 18:04:04 -0000 A new IETF WG 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@ietf.org) by 2016-10-10. SIDR Operations (sidrops) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Joel Jaeggli Operations and Management Area Directors: Benoit Claise Joel Jaeggli Mailing list: TBD Charter: https://datatracker.ietf.org/doc/charter-ietf-sidrops/ The global deployment of RPKI, Origin Validation of BGP announcements and BGPSEC, collectively called SIDR, is underway, creating an Internet Routing System consisting of SIDR-aware and non-SIDR-aware networks. This deployment must be properly handled to avoid the division of the Internet into separate networks. sidrops works to ensure as secure a routing system as possible, through encouraged deployment of the SIDR technologies. The SIDR Operations Working Group (sidrops) develops guidelines for the operation of SIDR-aware networks, and provides operational guidance on how to deploy and operate SIDR technologies in existing and new networks. In the space of sidr-ops, the term operators will encompass more than just network operators: CA Operators, Regional/National and Local Internet Registries, Relying Party software developers as well as the research/measurement community all have relevant operational experience or insight that this working group will consider in its work. The main focuses of the SIDR Operations Working Group are to: o Discuss deployment and operational issues related to SIDR technologies in networks which are part of the global routing system. o Gather and discuss deployment experiences with the SIDR technologies in networks which are part of the global routing system, as well as the repositories and CA systems that also form part of the SIDR architecture The goals of the sidrops working group are to: 1. Solicit input from all operators to identify operational issues with a SIDR-aware Internet, and determine solutions or workarounds to those issues. 2. Solicit input from all operators to identify issues with interaction with the non-SIDR-aware Internet, and to determine solutions or workarounds to those issues. 3. Operational olutions for identified issues should be developed in sidr-ops and documented in informational or BCP documents. These documents should document SIDR operational experience, including interactions with non-SIDR-aware networks, the interfaces between SIDR- aware and non-SIDR-aware networks, and the continued operational/ security impacts from non-SIDR-aware networks. SIDR operational and deployment issues with Interdomain Routing Protocols are the primary responsibility of the IDR working group. The sidr-ops Working Group may provide input to that group, as needed, and cooperate with that group in reviewing solutions to SIDR operational and deployment problems. Future work items within this scope will be adopted by the Working Group if there is a substantial expression of interest from the community and if the work (for example protocol maintenance clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the Working Group to work on a particular work item. If there is no longer sufficient interest in the Working Group in a work item, the item may be removed from the list of Working Group items. Milestones: Jul 2017 - draft-ietf-sidr-bgpsec-rollover Jul 2017 - draft-ietf-sidr-rtr-keying Jul 2017 - draft-ietf-sidr-route-server-rpki-light Jul 2017 - draft-ietf-sidr-rpki-tree-validation Sep 2017 - BGPSEC Ops document finalized. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Sep 30 11:36:40 2016 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 BDBBE12B409; Fri, 30 Sep 2016 11:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1475258857; bh=6rfqNobcdC+eohllxcv92Y/x6tpJn13ZC4Mm3MVwztM=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=YNni/ZFQ8byEd0ZC/haWwonhXSnnNQ5qTT+MvWzMYadJSUxHFmFAOLJp6pKLnb0+e dzi85CkW0/Jgg7sE15p6HrFIaEDpDv4qeFfvqEx+5lKd4EyNP7ROtl11BxJ0avYgvF P4JGGK1MX4+Nw0xiXxDJ/TceKl6nbWG5u70yjSFM= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BEA12B1D0 for ; Fri, 30 Sep 2016 11:07:31 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <147525885168.20369.7500200980077500569.idtracker@ietfa.amsl.com> Date: Fri, 30 Sep 2016 11:07:31 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 11:36:34 -0700 Subject: [secdir] [new-work] WG Review: IP Wireless Access in Vehicular Environments (ipwave) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 18:07:38 -0000 A new IETF WG has been proposed in the Internet Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-10-10. IP Wireless Access in Vehicular Environments (ipwave) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Suresh Krishnan Internet Area Directors: Terry Manderson Suresh Krishnan Mailing list: Address: its@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/its Archive: https://www.ietf.org/mail-archive/web/its/current/maillist.html Charter: https://datatracker.ietf.org/doc/charter-ietf-ipwave/ Automobiles and vehicles of all types are increasingly connected to the Internet. Comfort-enhancing entertainment applications, road safety applications using bidirectional data flows, and connected automated driving are but a few new features expected in automobiles to hit the roads from now to year 2020. Today, there are several deployed Vehicle-to-Internet technologies (V2Internet) that make use of embedded Internet modules, or an occupant's cellular smartphone: mirrorlink, carplay, android auto. Vehicle-to-Infrastructure (V2I, not to be mistaken with V2Internet) Communications are used for wireless exchange of critical safety and operational data between vehicles and roadway infrastructure, intended primarily to avoid motor vehicle crashes. Similarly, Vehicle-to-Vehicle Communications (V2V) are used for short-range communications between vehicles to exchange vehicle information such as vehicle speed, headng and braking status. However, V2V and V2I communications are still in the process of being developed. Some forms of vehicle and infrastructure communications will use IP and others will not. Thus, multiple applications need to share one data link, including non-IP-based protocols sharing the data link with IP-based protocols. This group will work on V2V and V2I use-cases where IP is well-suited as a networking technology and will develop an IPv6 based solution to establish direct and secure connectivity between a vehicle and other vehicles or stationary systems. V2V and V2I communications may involve various kinds of link layers: 802.11-OCB (Outside the Context of a Basic Service Set, also called 802.11p), 802.15.4 with 6lowpan, 802.11ad, VLC (Visible Light Communications), IrDA, LTE-D, LP-WAN. One of the most used link layers for vehicular networks is IEEE 802.11-OCB, as a basis for Dedicated short-range communications (DSRC). Several of these link-layers already provide support for IPv6. However, IPv6 on 802.11-OCB is yet to be defined. This group's primary deliverable (and the only Standards track item) will be a document that will specify the mechanisms for transmission of IPv6 datagrams over IEEE 802.11p OCB mode. The group will work on an informational document that will explain the state of the art in the field and describe the use cases that will use IPv6 in order to focus the work of the group. The group will also work on informational document that describes the problem statement and the associated security and privacy considerations. The working group will decide at a future point whether these informational documents need to be published separately as RFCs or if they maybe combined. The group will try to reuse relevant technologies for Internet of Things (IoT) and infrastructure mobility that have been developed in other IETF and IRTF groups. The WG will pay particular attention to the privacy characteristics of solution it develops in order to minimize unwanted tracking opportunities. The group will closely coordinate with IEEE 802.11. The work produced by this group may be of interest to other SDOs such as ISO/TC204, ETSI TC ITS, 3GPP, and NHTSA. No formal co-ordination is anticipated with these groups at this point but work done in these SDOs may end up becoming relevant to the WG deliverables in the future. Milestones: Oct 2016 - Draft for "IPv6 over 802.11-OCB" adopted by WG Dec 2016 - Draft for "ITS General Problem Area" adopted by WG Mar 2017 - Draft for "Problem Statement" adopted by WG May 2017 - Submit "IPv6 over 802.11-OCB" to IESG Oct 2017 - Submit "ITS General Problem Area" to IESG May 2018 - Submit "Problem Statement" to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Sep 30 11:36:42 2016 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 1855D12B1F1; Fri, 30 Sep 2016 11:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1475259261; bh=ABk/P96qjv+XLBu5FV6Cs7H45Rg+MpES/7gJrzWuyR0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=WA0AJFMQors0h2j8KUbdN2KCloRvBTr0QNrZMo65HVF94kGicfY1ivH8bta+V9mRi KEOq66k4JU9IPNWARKh7cTuPUpuy3dmXWvkEip6pRowA6ZnDF9R56s+d2klti1xg38 QQbWvpTF7dRbHP6Uvu8GliEJWu3X0kNl5fILVLOE= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF0812B1CF for ; Fri, 30 Sep 2016 11:14:13 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <147525925376.20385.706167486932160531.idtracker@ietfa.amsl.com> Date: Fri, 30 Sep 2016 11:14:13 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 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, 30 Sep 2016 11:36:34 -0700 Subject: [secdir] [new-work] WG Review: IPv6 over Low Power Wide-Area Networks (lpwan) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 18:14:21 -0000 A new IETF WG has been proposed in the Internet Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-10-10. IPv6 over Low Power Wide-Area Networks (lpwan) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Suresh Krishnan Internet Area Directors: Terry Manderson Suresh Krishnan Mailing list: Address: lp-wan@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/lp-wan Archive: http://www.ietf.org/mail-archive/web/lp-wan/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lpwan/ A new generation of wireless technologies has emerged under the generic name of Low-Power Wide-Area (LPWA), with a number of common characteristics, which make these technologies unique and disruptive for Internet of Things applications. Those common traits include an optimized radio modulation, a star topology, frame sizes in the order of tens of bytes transmitted a few times per day at ultra-low speeds and sometimes variable MTUs, and, though downstream may be supported, a mostly upstream transmission pattern that allows the devices to spend most of their time in low- energy deep-sleep mode. This enables a range of several kilometers and a long battery lifetime, possibly ten years operating on a single coin-cell. This also enables simple and scalable deployments with low-cost devices and thin infrastructures. Those benefits come at a price: the layer 2 frame formats are optimized and specific to each individual technology. There is no network layer and the application is often hard wired to the layer 2 frame format, leading to siloed deployments that must be managed, secured and operated individually. Migrating from one LPWA technology to another implies rebuilding the whole chain. To unleash the full power of LPWA technologies and their ecosystems, there is a need to couple them with other ecosystems that will guarantee the inter-working by introducing a network layer, and enable common components for management and security, as well as shared application profiles. The IETF can contribute by providing IPv6 connectivity, and propose technologies to secure the operations and manage the devices and their gateways. The Working Group will focus on enabling IPv6 connectivity over the following selection of Low-Power Wide-Area technologies: SIGFOX, LoRa, WI-SUN and NB-IOT. These technologies present similar characteristics of rare and widely unbalanced over-the-air transmissions, with little capability to alter the frame formats to accommodate this work, which makes it so that existing IETF work (6lo) cannot be trivially applied. The Working Group will leverage cross-participation with the associated set of stakeholders to ensure that the work taking place corresponds to real demands and that the proposed solutions are indeed applicable. The group will produce informational work describing LPWA technologies and their needs as well as new standard work to optimize IPv6-based communications to the end device The group will: 1. Produce an Informational document describing and relating some selected LPWA technologies. This work will document the common characteristics and highlight actual needs that the IETF could serve; but it is not intended to provide a competitive analysis. It is expected that the information contained therein originates from and is reviewed by people who work on the respective LPWA technologies. 2. Produce a Standards Track document to enable the compression and fragmentation of a CoAP/UDP/IPv6 packet over LPWA networks. This will be achieved through stateful mechanisms, specifically designed for star topology and severely constrained links. The work will include the definition of generic data models to describe the compression and fragmentation contexts. This work may also include to define technology- specific adaptations of the generic compression/fragmentation mechanism wherever necessary. Milestones: Nov 2016 - Adopt LPWAN specifications as WG item Dec 2016 - Adopt IP/UDP compression and fragmentation mechanism as a WG item Jan 2017 - Adopt CoAP compression mechanism as a WG item Apr 2017 - Submit LPWAN specification to the IESG for publication as an Informational Document May 2017 - Submit IP/UDP compression and fragmentation mechanism to the IESG for publication as a Proposed Standard Jul 2017 - Submit CoAP compression mechanism to the IESG for publication as a Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work