From nobody Mon Dec 1 10:39:31 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF991A8837 for ; Mon, 1 Dec 2014 10:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjcTzrDqOnS3 for ; Mon, 1 Dec 2014 10:39:25 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185A81A8829 for ; Mon, 1 Dec 2014 10:39:23 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id m20so7988652qcx.26 for ; Mon, 01 Dec 2014 10:39:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=BARFuKZIQmfXF416khs5poS51zFbwdYYgY3vs0ZZg9I=; b=ekpmrnc99vfYH8K8QzvJF1WdAPVk1vM+gP5O9jfAmpc4HKR1cSD9zGJiylweOUQ2tL CcA3jEAWthg8Szfpdh+V3G8a6qtVmCt+XASDIVBaJ6lQqm0+T+qGmWp8YtGKtFKpDXIW VYEijHHHM42DM5lmCJ5cmvT4bCPKVrj2B+ZwCaVKXtNq4FjmA7L+kHu4w/mEcmCYlBEK HHZB0EbvclLqUBT2c7luYuXd+B+lpvmjl5EJgwghyuTqQoSzTRc5/nVGziw+ZKAdU/gU KHLmyUTE/9F1432wh2LD1q9jvee/pS9b9VuCtakj+zcOXN6EdUyHI0DQpKhdokwIMFcu I61g== X-Gm-Message-State: ALoCoQmf4syAQEjUDRuAbXk2o58e5Yb8BKBolKEsoflOgLU5rvftAJ/oQ+GR4e6DG3y4YspW8l/n MIME-Version: 1.0 X-Received: by 10.140.104.12 with SMTP id z12mr3960397qge.75.1417459162341; Mon, 01 Dec 2014 10:39:22 -0800 (PST) Received: by 10.96.238.73 with HTTP; Mon, 1 Dec 2014 10:39:22 -0800 (PST) X-Originating-IP: [2601:8:b300:a5:dc6:d9e5:2339:fbb3] Date: Mon, 1 Dec 2014 10:39:22 -0800 Message-ID: From: Joseph Salowey To: secdir@ietf.org, draft-ietf-tsvwg-sctp-prpolicies.all@tools.ietf.org, iesg@ietf.org Content-Type: multipart/alternative; boundary=001a1134f7c8db027105092bedca Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/wi2Z83bGqRwkWdwKFw1y1g6T2q4 Subject: [secdir] secdir review of draft-ietf-tsvwg-sctp-prpolicies-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 18:39:27 -0000 --001a1134f7c8db027105092bedca 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 have reviewed this document and believe it is Ready with minor issues. This document describes new policies for the users of the SCTP Partial Reliability service (SCTP-PR). These policies cover discarding data after too many retransmissions and discarding lower priority data. The security considerations are a bit thin. They mostly refer to RFC 3758 which is also a bit thin and was published before SCTP-DTLS was available. There is some useful text in RFC 6083 (SCTP-DTLS) : "If PR-SCTP as defined in [RFC3758 ] is used, FORWARD-TSN chunks MUST also be sent in an authenticated way as described in [RFC4895 ]. This makes sure that it is not possible for an attacker to drop messages and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this dropping." I think it would be good to include similar text in this document since it is relevant. Are there any problems introduced if the INIT or the INIT-ACK messages are not protected? Cheers, Joe --001a1134f7c8db027105092bedca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dire= ctorate's ongoing effort to review all IETF documents being processed b= y the IESG. These comments were written primarily for the benefit of the se= curity area directors. Document editors and WG chairs should treat these co= mments just like any other last call comments.

I have re= viewed this document and believe it is Ready with minor issues. =C2=A0

This document describes new policies for the users of = the SCTP Partial Reliability service (SCTP-PR).=C2=A0 These policies cover = discarding data after too many retransmissions and discarding lower priorit= y data. =C2=A0

The security considerations are a b= it thin.=C2=A0 They mostly refer to RFC 3758 which is also a bit thin and w= as published before SCTP-DTLS was available.=C2=A0 There is some useful tex= t in RFC=C2=A06083 (SCTP-DTL= S) :

  "If PR-SCTP as defined in [RFC3758] is =
used, FORWARD-TSN chunks MUST
   also be sent in an authenticated way as described in [RFC4895].  This
   makes sure that it is not possible for an attacker to drop messages
   and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this
   dropping."

I think it would be good t= o include similar text in this document since it is relevant.=C2=A0 Are the= re any problems introduced if the INIT or the INIT-ACK messages are not pro= tected? =C2=A0

Cheers,

Jo= e
--001a1134f7c8db027105092bedca-- From nobody Mon Dec 1 11:28:29 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9901A89C4; Mon, 1 Dec 2014 11:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBlNWAOyexYQ; Mon, 1 Dec 2014 11:28:25 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E676C1A89C7; Mon, 1 Dec 2014 11:28:22 -0800 (PST) Received: from [192.168.1.102] (p508F31EC.dip0.t-ipconnect.de [80.143.49.236]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7E2401C1622C0; Mon, 1 Dec 2014 20:28:19 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Mon, 1 Dec 2014 20:28:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joseph Salowey X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8fbnljNutglPMrB8SAPMpdk3cD8 Cc: draft-ietf-tsvwg-sctp-prpolicies.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-sctp-prpolicies-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 19:28:27 -0000 On 01 Dec 2014, at 19:39, Joseph Salowey wrote: > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > I have reviewed this document and believe it is Ready with minor = issues. =20 Hi Joe, thank you very much for your review. See my comments below. Best regards Michael >=20 > This document describes new policies for the users of the SCTP Partial = Reliability service (SCTP-PR). These policies cover discarding data = after too many retransmissions and discarding lower priority data. =20 >=20 > The security considerations are a bit thin. They mostly refer to RFC = 3758 which is also a bit thin and was published before SCTP-DTLS was = available. There is some useful text in RFC 6083 (SCTP-DTLS) : >=20 > "If PR-SCTP as defined in [RFC3758 > ] is used, FORWARD-TSN chunks MUST > also be sent in an authenticated way as described in [ > RFC4895 > ]. This > makes sure that it is not possible for an attacker to drop messages > and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide = this > dropping." >=20 >=20 > I think it would be good to include similar text in this document = since it is relevant. Are there any problems=20 I see your point, but this usage of AUTH in combination with DTLS is not = related to the particular PR-SCTP policy. One could add a sentence stating that if DTLS = over SCTP as specified in RFC 6083, the corresponding security considerations also apply. Would = that address your issue? > introduced if the INIT or the INIT-ACK messages are not protected? =20 No. You can't protect them, see https://tools.ietf.org/html/rfc4895#section-3.2 >=20 > Cheers, >=20 > Joe From nobody Mon Dec 1 11:39:06 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8081A8A44; Mon, 1 Dec 2014 11:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiK5YkL3lnYt; Mon, 1 Dec 2014 11:38:57 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E4591A89F9; Mon, 1 Dec 2014 11:37:40 -0800 (PST) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id sB1JbcjZ021017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Dec 2014 14:37:38 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_3D80B6AA-ACDE-473E-87FD-5F783E6E955B" Date: Mon, 1 Dec 2014 14:37:38 -0500 Message-Id: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-opsawg-capwap-hybridmac.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/XijaeiL67PouNhVVYBu6dLtwnvM Subject: [secdir] Secdir review of draft-ietf-opsawg-capwap-hybridmac-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 19:39:00 -0000 --Apple-Mail=_3D80B6AA-ACDE-473E-87FD-5F783E6E955B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. I believe that this document is ready, with minor issues in the Security = Considerations Section.=20 This ID concerns the correction of an ambiguity in the CAPWAP protocol. = That protocol supports two Medium Access Control (MAC) modes with = respect to two entities: a Wireless Transmission Point (WTP) and an Access = Controller (AC). In one of the modes, split mode, encryption = functionality can be located at either the WTP or the AC, but no clear way is given of having the AC inform the = WTP of where the encryption functionality should be located. This ID = presents a means by which the WTP informs the AC of the various MAC profiles it supports, and then = the AC determines the appropriate profile and configures the WTP with = the profile while configuring the WLAN. The Security Considerations Section says that this document does not = introduce any new security risks compared to RFC5416, and that the = security considerations described in RFC5416 apply here as well. I believe that a document that = addresses the placement of encryption functionality should say something = more, in particular *why* it introduces no new security risks. In the case of negotiation, = the main security risk is that an attacker could interfere with the = negotiation so that a less secure alternative is chosen even when a more secure one is available. In the = security considerations section of RFC5416 it is noted that there is a = possibility of a replay attack if encryption resides at the WTP. The risk is slight, and = the only way of closing the security gap is expensive, so the authors of = RFC5416 decide to let the risk stand. However, this presents a conceivable attack in which an = attacker could cause an AC to believe that a WTP only supports = encryption functionality at the WTP, and the AC would choose the less secure mode. Although the risk this = introduces is also slight, I believe that this should be mentioned. = Also, would I be correct in assuming that a WTP that supports encryption at the WTP but not at the AC is = unlikely? If that is so, it might be possible to close the security gap = by having the ATP reject advertisements (request a retransmit?) that only support encryption at the WTP, and if so you = should mention that too. =20 Nits: The word =93clearly=94 is repeated in line 7 of the abstract. =20 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail=_3D80B6AA-ACDE-473E-87FD-5F783E6E955B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
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 believe that = this document is ready, with minor issues in the Security Considerations = Section. 

This ID concerns the correction of an = ambiguity in the CAPWAP protocol.  That protocol supports two = Medium Access Control (MAC) modes with respect to
two entities: a = Wireless Transmission Point (WTP) and an Access Controller (AC). =  In one of the modes, split mode, encryption functionality can be = located at either
the WTP or the AC, but no clear way is given = of having the AC inform the WTP of where the encryption functionality = should be located.  This ID presents a means by which
the = WTP informs the AC of the various MAC profiles it supports, and then the = AC determines the appropriate profile and configures the WTP with the = profile while configuring
the = WLAN.

The Security Considerations Section says = that this document does not introduce any new security risks compared to = RFC5416, and that the security considerations
described in = RFC5416 apply here as well.  I believe that a document that = addresses the placement of encryption functionality should say something = more, in particular
*why* it introduces no new security risks. =  In the case of negotiation, the main security risk is that an = attacker could interfere with the negotiation so that a less = secure
alternative is chosen even when a more secure one is = available.  In the security considerations section of RFC5416 it is = noted that there is a possibility of a
replay attack if = encryption resides at the WTP.  The risk is slight, and the only = way of closing the security gap is expensive, so the authors of RFC5416 = decide to let
the risk stand.  However, this presents a = conceivable attack in which an attacker could cause an AC to believe = that a WTP only supports   encryption functionality at the = WTP,
and the AC would choose the less secure mode. =  Although the risk this introduces is also slight, I believe that = this should be mentioned. Also, would I be correct in = assuming
that a WTP that supports encryption at the WTP but = not at the AC is unlikely? If that is so, it might be possible to close = the security gap by having the ATP reject advertisements = (request
a retransmit?) that only support encryption at the = WTP, and if so you should mention that too. =  


Nits:

<= div>The word =93clearly=94 is repeated in line 7 of the abstract. =  

Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

= --Apple-Mail=_3D80B6AA-ACDE-473E-87FD-5F783E6E955B-- From nobody Mon Dec 1 11:44:38 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533A1A8ABF for ; Mon, 1 Dec 2014 11:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJAhfHKEVQBO for ; Mon, 1 Dec 2014 11:44:34 -0800 (PST) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82B31A8ABE for ; Mon, 1 Dec 2014 11:44:33 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id r5so8353328qcx.30 for ; Mon, 01 Dec 2014 11:44:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bJk7omLYLC+YrFasmeomF+QRRRn1X8Nrwgvnzcs0AU4=; b=GtOIM2lzKob70O5Uh1BfOk/aKwHJ5y7h0rGqslI3XdpoOz4w0fh298oVploeethSHX /19MkmGYEp9tRDBCTI+kV+DLEqjpFRsiZn9F+dWlM6zC8Lfm3+yY7t3LwzPUy7+SvzFv WhYCM+58A1/WOayynglCutn7gEg6zlRQq7IF/USG910gwaMO6+zt0BjZ0c1EBU/Yq9Qw lNGuNAuq2JuqNy0CrEoKgGQ/VgCD5utH+Ks073+3yKA9jBs39uuCxNpsyPkpZh2F+djn 6Wi1g2tfXh5FKM3zGRCFqoujBGftzJRlSBUORCd2sGYN3QtgBucoyLvZ8dpyUS8Hw2+u n6nw== X-Gm-Message-State: ALoCoQmhGProJbBg1z7w3nZ6+rxwGLsY8SitRB1edz9hqtY60hPycafoWY1twDbQEe4BDQo5DMvl MIME-Version: 1.0 X-Received: by 10.224.167.209 with SMTP id r17mr60937263qay.18.1417463072998; Mon, 01 Dec 2014 11:44:32 -0800 (PST) Received: by 10.96.238.73 with HTTP; Mon, 1 Dec 2014 11:44:32 -0800 (PST) X-Originating-IP: [2601:8:b300:a5:dc6:d9e5:2339:fbb3] In-Reply-To: References: Date: Mon, 1 Dec 2014 11:44:32 -0800 Message-ID: From: Joseph Salowey To: Michael Tuexen Content-Type: multipart/alternative; boundary=089e0149cd74f2dc1805092cd616 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/GInB0PJI2bNSl_7csjPodH7BQb4 Cc: draft-ietf-tsvwg-sctp-prpolicies.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-sctp-prpolicies-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 19:44:36 -0000 --089e0149cd74f2dc1805092cd616 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 1, 2014 at 11:28 AM, Michael Tuexen wrote: > On 01 Dec 2014, at 19:39, Joseph Salowey 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. > > > > I have reviewed this document and believe it is Ready with minor issues. > Hi Joe, > > thank you very much for your review. See my comments below. > > Best regards > Michael > > > > This document describes new policies for the users of the SCTP Partial > Reliability service (SCTP-PR). These policies cover discarding data after > too many retransmissions and discarding lower priority data. > > > > The security considerations are a bit thin. They mostly refer to RFC > 3758 which is also a bit thin and was published before SCTP-DTLS was > available. There is some useful text in RFC 6083 (SCTP-DTLS) : > > > > "If PR-SCTP as defined in [RFC3758 > > ] is used, FORWARD-TSN chunks MUST > > also be sent in an authenticated way as described in [ > > RFC4895 > > ]. This > > makes sure that it is not possible for an attacker to drop messages > > and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this > > dropping." > > > > > > I think it would be good to include similar text in this document since > it is relevant. Are there any problems > I see your point, but this usage of AUTH in combination with DTLS is not > related to the > particular PR-SCTP policy. One could add a sentence stating that if DTLS > over SCTP as specified > in RFC 6083, the corresponding security considerations also apply. Would > that address your issue? > [Joe] Yea, I think that would be OK. > > introduced if the INIT or the INIT-ACK messages are not protected? > No. You can't protect them, see > https://tools.ietf.org/html/rfc4895#section-3.2 > [Joe] Ah, OK. So it seems the INIT negotiation is unprotected and may be modified by an attacker. Probably not something to address in this draft, but I wonder if there are some potential issues here. > > > > Cheers, > > > > Joe > > --089e0149cd74f2dc1805092cd616 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 1, 2014 at 11:28 AM, Michael Tuexen <<= a href=3D"mailto:tuexen@fh-muenster.de" target=3D"_blank">tuexen@fh-muenste= r.de> wrote:
On 01 Dec 2014, at 19:39, Joseph Salowey <joe@salowey.net> 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.
>
> I have reviewed this document and believe it is Ready with minor issue= s.
Hi Joe,

thank you very much for your review. See my comments below.

Best regards
Michael
>
> This document describes new policies for the users of the SCTP Partial= Reliability service (SCTP-PR).=C2=A0 These policies cover discarding data = after too many retransmissions and discarding lower priority data.
>
> The security considerations are a bit thin.=C2=A0 They mostly refer to= RFC 3758 which is also a bit thin and was published before SCTP-DTLS was a= vailable.=C2=A0 There is some useful text in RFC 6083 (SCTP-DTLS) :
>
>=C2=A0 =C2=A0"If PR-SCTP as defined in [RFC3758
> ] is used, FORWARD-TSN chunks MUST
>=C2=A0 =C2=A0 also be sent in an authenticated way as described in [ > RFC4895
> ].=C2=A0 This
>=C2=A0 =C2=A0 makes sure that it is not possible for an attacker to dro= p messages
>=C2=A0 =C2=A0 and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks = to hide this
>=C2=A0 =C2=A0 dropping."
>
>
> I think it would be good to include similar text in this document sinc= e it is relevant.=C2=A0 Are there any problems
I see your point, but this usage of AUTH in combination with DTLS is= not related to the
particular PR-SCTP policy. One could add a sentence stating that if DTLS ov= er SCTP as specified
in RFC 6083, the corresponding security considerations also apply. Would th= at address your issue?

[Joe] Yea, I thi= nk that would be OK. =C2=A0
=C2=A0
> introduced if the INIT or the INIT-ACK messages are n= ot protected?
No. You can't protect them, see
https://tools.ietf.org/html/rfc4895#section-3.2

[Joe] Ah, OK.=C2=A0 So it seems the INIT n= egotiation is unprotected and may be modified by an attacker.=C2=A0 Probabl= y not something to address in this draft, but I wonder if there are some po= tential issues here. =C2=A0
=C2=A0
>
> Cheers,
>
> Joe


--089e0149cd74f2dc1805092cd616-- From nobody Mon Dec 1 11:59:41 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4F21A8A82; Mon, 1 Dec 2014 11:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKpCGwtGRnLZ; Mon, 1 Dec 2014 11:59:34 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D971A8987; Mon, 1 Dec 2014 11:59:33 -0800 (PST) Received: from [192.168.1.102] (p508F31EC.dip0.t-ipconnect.de [80.143.49.236]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 064401C104615; Mon, 1 Dec 2014 20:59:30 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Mon, 1 Dec 2014 20:59:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joseph Salowey X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/AeBdjVnFRwwnTJ1Mdebbba6SB6g Cc: draft-ietf-tsvwg-sctp-prpolicies.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-sctp-prpolicies-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 19:59:35 -0000 On 01 Dec 2014, at 20:44, Joseph Salowey wrote: >=20 >=20 > On Mon, Dec 1, 2014 at 11:28 AM, Michael Tuexen = wrote: > On 01 Dec 2014, at 19:39, Joseph Salowey wrote: >=20 > > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. > > > > I have reviewed this document and believe it is Ready with minor = issues. > Hi Joe, >=20 > thank you very much for your review. See my comments below. >=20 > Best regards > Michael > > > > This document describes new policies for the users of the SCTP = Partial Reliability service (SCTP-PR). These policies cover discarding = data after too many retransmissions and discarding lower priority data. > > > > The security considerations are a bit thin. They mostly refer to = RFC 3758 which is also a bit thin and was published before SCTP-DTLS was = available. There is some useful text in RFC 6083 (SCTP-DTLS) : > > > > "If PR-SCTP as defined in [RFC3758 > > ] is used, FORWARD-TSN chunks MUST > > also be sent in an authenticated way as described in [ > > RFC4895 > > ]. This > > makes sure that it is not possible for an attacker to drop = messages > > and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide = this > > dropping." > > > > > > I think it would be good to include similar text in this document = since it is relevant. Are there any problems > I see your point, but this usage of AUTH in combination with DTLS is = not related to the > particular PR-SCTP policy. One could add a sentence stating that if = DTLS over SCTP as specified > in RFC 6083, the corresponding security considerations also apply. = Would that address your issue? >=20 > [Joe] Yea, I think that would be OK. =20 OK, I added: If DTLS over SCTP as specified in is used, = the security considerations of do apply. > =20 > > introduced if the INIT or the INIT-ACK messages are not protected? > No. You can't protect them, see > https://tools.ietf.org/html/rfc4895#section-3.2 >=20 > [Joe] Ah, OK. So it seems the INIT negotiation is unprotected and may = be modified by an attacker. Probably not something to address in this = draft, but I wonder if there are some potential issues here. =20 What can an attacker do? If an attacker removes the DATA chunk from the = chunks to be authenticated, the peer can detect this. The only consistent way is to remove the = PR-SCTP supported parameter and the FORWARD TSN parameter from the INIT/INIT-ACK. This means that one = side thinks that PR-SCTP is not supported by the peer and the other side thinks that it is = supported. The only thing an attacker can do is to remove FORWARD-TSN chunks und insert SACKs. This will = result in a deadlock situation of the peer which would have received the FORWARD TSN. But the attacker = can do this anyway by removing other messages. So I don't see an issue here. Best regards Michael > =20 > > > > Cheers, > > > > Joe >=20 >=20 From nobody Mon Dec 1 21:09:20 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6431A00DF; Mon, 1 Dec 2014 21:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.497 X-Spam-Level: ** X-Spam-Status: No, score=2.497 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vyKqpjLNoNC; Mon, 1 Dec 2014 21:09:12 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 610E91A008A; Mon, 1 Dec 2014 21:09:12 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id sB259AmX012526; Tue, 2 Dec 2014 14:09:10 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id sB259AxJ008217; Tue, 2 Dec 2014 14:09:10 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 77BDF16347; Tue, 2 Dec 2014 14:09:10 +0900 (JST) Received: from VAIO (unknown [133.243.119.37]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 68BB416202; Tue, 2 Dec 2014 14:09:10 +0900 (JST) From: "Takeshi Takahashi" To: Date: Tue, 2 Dec 2014 14:09:10 +0900 Message-ID: <007b01d00dee$1b5e5950$521b0bf0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAN7XykZH0mysjmR36Ib9w2fh0nsg== Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith1 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/3kAAgbagKoAVOh2oOwrsoD3KzNY Cc: grow-chairs@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: [secdir] Secdir review of draft-ietf-grow-irr-routing-policy-considerations-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 05:09:14 -0000 Hello, I have=A0reviewed=A0current version of this document as part of = the=A0security directorate's ongoing effort to=A0review=A0all IETF documents being = processed by the IESG.=A0 These comments were written primarily for the benefit of = the security=A0area directors.=A0 Document editors and WG chairs should = treat these comments just like any other last call comments. This draft covers the problems of the current IRR. It considers problems of IRR from the standpoints of data integrity and operations. I feel like that this draft covers sufficient types of the problems we = know until now. Reader can easily get a big picture of the issues. I think this document is ready, as it is. Thank you for writing a nice document. Kind regards, Take From nobody Tue Dec 2 06:19:15 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A4E1A1B98 for ; Tue, 2 Dec 2014 06:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA8Jx63kQQcN for ; Tue, 2 Dec 2014 06:19:09 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8891ACDC4 for ; Tue, 2 Dec 2014 06:19:02 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so21104124wiw.15 for ; Tue, 02 Dec 2014 06:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Si2GKM3nps4yZsBdDv46iju6nGgb3WwqR/pji81u/KE=; b=PVlW/3UELd/nk1PBDr2WhzBZJvZR9ePowN/s5QywrFYTUdc0qXgwBLhizfHQGj9ZP2 xUYz30Msl3RA72ANxckVoU/bkmFJ7e3zQPMucwHveJm4JjKgAucLTB2tHDyiti00387M pShqqgFtgc1X70yX7nlvIwHPANCvHkJc9aO2A+GeF6XrRQ0L9tg0l0b6aWOsSaYddMMY 99zflpaZQrxiy8uFAxR1LCEin6zmO4kPRk4DRcBNdxgMrcqyC7TvwyUEFi/bMypn4kXi lYYLmq66i+yXp0cZny/QRRIr86H+6V/THGPARhywPSRswHQWTI4S5Z3pXs+AjLt6c0Ts Tvrw== MIME-Version: 1.0 X-Received: by 10.180.90.147 with SMTP id bw19mr9726584wib.69.1417529941523; Tue, 02 Dec 2014 06:19:01 -0800 (PST) Received: by 10.180.81.69 with HTTP; Tue, 2 Dec 2014 06:19:01 -0800 (PST) Date: Tue, 2 Dec 2014 15:19:01 +0100 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: "secdir@ietf.org" , draft-josefsson-pkix-textual@tools.ietf.org Content-Type: multipart/alternative; boundary=f46d043892519f815b05093c68c4 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/bwBx-04t0NrEnwWur7QxoKQK8yA Subject: [secdir] Secdir review of draft-josefsson-pkix-textual X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 14:19:12 -0000 --f46d043892519f815b05093c68c4 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. This memo documents textual encodings of various well-established PKI-related data structures and formats. The document is intended to be published as a Standards-Track RFC. Comments and suggestions: Section 5.1: - For clarity and common keyword usage, suggest replacing "The encoded data MUST be a BER (DER strongly preferred) encoded ASN.1..." with: "The encoded data MUST be BER and SHOULD be a DER encoded ASN.1..." (In fact this comment goes for all places where you have text like "MUST be a BER (DER [strongly] preferred" - better to use established RFC 2119 language). - I wonder why you state "Parsers are NOT RECOMMENDED to treat "X509 CERTIFICATE" or "X.509 CERTIFICATE" as equivalent to "CERTIFICATE", but a valid exception may be for backwards compatibility (potentially together with a warning)" since to my knowledge, they all refer to the same structure and in the spirit of "strict in issuance, generous in receipt", it would seem to be better to state: ""Parsers MAY treat ... as equivalent to "CERTIFICATE" " ? - I also wonder about the warning above since if the structure indeed does parse as a certificate, what value would the warning bring (and to whom)? Section 5.3: I disagree with the deprecation of .cer in favor of .crt. The .cer convention is used broadly. I would suggest updating the text to recommend use of .crt OR .cer. Better yet, remove the section, since this document specifically is about textual encodings and not file extension naming and you do not discuss extension naming elsewhere. Section 6: Same comments as for Section 5.1 above, but for CRLs... Section 7: Same comment as my first for Section 5.1. I note that you have the same language with regards to parser flexibility here that I have suggested for Section 5.1 and Section 6. Security Considerations: No particular comments. -- Magnus --f46d043892519f815b05093c68c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document a= s part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the IE= SG. These comments were written primarily for the benefit of the security=20 area directors. Document editors and WG chairs should treat these=20 comments just like any other last call comments.
=

This memo documen= ts textual encodings of various well-established PKI-related data structure= s and formats. The document is intended to be published as a Standards-Trac= k RFC.
Comments and suggestions:

Section 5.1:
=C2=A0- For clarity and common keyword usage, suggest replacing "The= encoded data MUST be a BER (DER strongly preferred) encoded ASN.1..."= with: "The encoded data MUST be BER and SHOULD be a DER encoded ASN.1= ..." (In fact this comment goes for all places where you have text lik= e "MUST be a BER (DER [strongly] preferred" - better to use estab= lished RFC 2119 language).
- I wonder why you state "Par= sers are NOT RECOMMENDED to treat "X509 CERTIFICATE" or "X.509 CERTIFI= CATE" as equivalent to "CERTIFICATE", but a valid exception may be for backwards compatibility (potentially together with a warning)" sinc= e to my knowledge, they all refer to the same structure and in the spirit o= f "strict in issuance, generous in receipt", it would seem to be = better to state: ""Parsers MAY treat ... as equivalent to "C= ERTIFICATE" " ?
- I also wonder about the warning above since = if the structure indeed does parse as a certificate, what value would the w= arning bring (and to whom)?

Section 5.3:
I disagree with the d= eprecation of .cer in favor of .crt. The .cer convention is used broadly. I= would suggest updating the text to recommend use of .crt OR .cer. Better y= et, remove the section, since this document specifically is about textual e= ncodings and not file extension naming and you do not discuss extension nam= ing elsewhere.

=
Section 6:
Same comments as for Section 5.1 a= bove, but for CRLs...

Section 7:Same comment as my first for Section 5.1. I note that you have the same la= nguage with regards to parser flexibility here that I have suggested for Se= ction 5.1 and Section 6.

Security C= onsiderations:
No particular comments.<= br>=C2=A0
-- Magnus
--f46d043892519f815b05093c68c4-- From nobody Tue Dec 2 14:03:00 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0801A7002; Tue, 2 Dec 2014 14:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MXFy9JbZRDY; Tue, 2 Dec 2014 14:02:42 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E17E1A1BC4; Tue, 2 Dec 2014 14:02:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7183; q=dns/txt; s=iport; t=1417557762; x=1418767362; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=iHMc3G24EV9q30nQtrL/Gm5S9Ln+OOBKP8QeLUP6XAs=; b=OmNfTxLW2Opx/xfeHO+Mn2XrLoGTTnljjpfqaYGCFafulT0dOS2PkPaM lnapTsSz1ZoInKaJ2mM5mZEpDcMckJCLINrV/oRElsUsOYRuEKksYph6m W2iTCjDtCaVDTLiGSltl2umSRRrJ49MPsHOg8GG5yDCV1ugkv5/TyRym4 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAKQ2flStJV2b/2dsb2JhbABbgwdSWQSDAcQFCoVOUQKBHRYBAQEBAX2EAgEBAQMBAQEBIA8BOwoGCwsYAgIFDwcLAgIJAwIBAgEVMAYBDAYCAQEViB4JDb9xlk8BAQEBAQEBAQIBAQEBAQEBAQEZgSuJNYU3JToYgl2BUwWLAYNhhj2GZ4EsOoJ+gmKNW4IEHoF5T4EEAh4GHIEBAQEB X-IronPort-AV: E=Sophos;i="5.07,503,1413244800"; d="scan'208";a="377078549" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 02 Dec 2014 22:02:20 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB2M2KXq013140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 22:02:20 GMT Received: from [10.129.24.46] (10.129.24.46) by xhc-rcd-x07.cisco.com (173.37.183.81) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Dec 2014 16:02:19 -0600 Message-ID: <547E36ED.1020205@cisco.com> Date: Tue, 2 Dec 2014 15:02:21 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yaron Sheffer , IETF Security Directorate , The IESG , References: <5470E68D.3040204@gmail.com> In-Reply-To: <5470E68D.3040204@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.46] Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/IIBMdrPNzNvlOH9PTEp0jtM01JQ Subject: Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 22:02:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Yaron, Thank you very much for the review. My other comments are inline. On 11/22/14, 12:39 PM, Yaron Sheffer 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 document contains a large set of examples of JOSE objects: > JWK, JWS and JWE. The document is purely informational, though in > "real life", I would expect developers to use it as an > authoritative source. > > Summary > > The document is ready to be published, with some issues. > > By the way, I really appreciate the large effort that surely went > into creating this document. > Thank you! It's always great to hear one's efforts are appreciated! > Details > > • Unless I missed it, the document does not mention a machine > readable repository of these examples, which I am sure the author > has created while writing the draft. Making such a repository > publicly available would result in a much more useful resource than > the current document, which essentially requires testers to scrape > the document when creating their test cases. > You did not miss it; I don't have a such a repository right now, but I can put one together. Would something on github.com be acceptable, or is there a better suggestion? > • (Not a comment to the current document:) I wonder why there is > nothing explicit to distinguish a public key from a private key, > and they are only distinguished by the presence or absence of > several parameters, something that will not be natural to most > developers. PEM is doing it very well: "-----BEGIN RSA PRIVATE > KEY-----". > > • 3.4: the text is contradictory re: zero-padding of the value "d". > Is it using the minimum number of octets, or exactly 256 octets > (for a 2048-bit key)? > The intent is that "d" is not zero-padded, and I overqualified in my text. Would the following be acceptable? For a 2048-bit key, the field "n" is 256 octets in length when decoded and the field "d" is not longer than 256 octets in length when decoded. > • Why invent a new term "octet key", for a simple "symmetric key"? Very good point. Will fix in the next revision. > > • 4.2: the first sentence discusses PS256, the actual example is > PS384. > Silly error that I thought I fixed long ago /-: Will fix in the next revision. > • 4.7: "only the JSON serialization" - please clarify which of the > three serializations is meant. Ditto top of 4.8. > Will fix in the next revision. > • 5.1.1: since this is a "cookbook", we should be using the public > key, not the private key. A private key would only be used in rare > cases. Similarly 5.2.1. > The private keys are included for both reproduction (which only needs the public key) and verification (which necessitates the private key). If I can put an online repository together, I can change the examples to just include the public keys; otherwise would the following in 5.1 (and 5.2) be sufficient? Note that only the RSA public key is necessary to perform the encryption. However, the example includes the RSA private key to allow readers to validate the example's output. > • 5.3.1: the "plaintext content" is a list of keys, which is > either confusing to the reader, or an actual error in the > document. > It is not in error. The most common usecase for password-based encryption was the import and export of key sets, and the Working Group desired a thorough example. Would it help if the following is added to 5.3? A common use of password-based encryption is the import/export of keys. Therefore this example uses a JWK Set for the plaintext content instead of the plaintext from figure 72. > • 5.3.5: In the General Serialization version, I don't understand > why only the encrypted key is per-recipient. I would expect the > PBES2 parameters too (e.g., the salt) to be per-recipient. > Presumably each of them is using a different password, and there's > no reason to use a common salt. Similarly in 5.4.5. > For compatibility across serializations (compact, general JSON, flattened JSON), all of the parameters need to be in the JWE Protected Header. In the general serialization, that means only the "encrypted_key" field is present for the (presumably) sole recipient. Would it be acceptable if the following were added to 5.3? Note that if password-based encryption is used for multiple recipients, it is expected that each recipient use different values for the PBES2 parameters "p2s" and "p2c". > • 5.7: same as above, it makes sense for the per-recipient key to > have an ID, rather than the content encryption key (typically an > ephemeral key). And then that ID should be in the per-recipient > data in 5.7.5. And similarly for 5.8. The later Sec. 5.13 shows a > syntax for multiple recipients that's inconsistent with the > single-recipient case, which would make sense if we got rid of the > array. > For compatibility across serializations (compact, general JSON, flattened JSON), all of the parameters need to be in the JWE Protected Header. Also, the mixing of "recipients" and "encrypted_key"/"header" in the top-level object is not permitted for the general serialization. > • 5.11: this example seems strange to me - why would anybody NOT > want to integrity-protect the key ID and algorithm? I would prefer > a more realistic example, or failing that, a recommendation to > developers to avoid this practice. Similarly 5.12, which is an even > worse idea. > Integrity protection was thoroughly discussed in the JOSE WG. While there are some limited attacks possible when some parameters are unprotected, the WG felt there were enough use cases where these attacks are mitigated through other means that integrity protection of the part of all of the header is not always required. > Thanks, Yaron > > _______________________________________________ secdir mailing > list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview And thanks again for the thorough review. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUfjbtAAoJEDWi+S0W7cO1rSUH/1j3BZKQz5zwo/N9/nlfFwmS JFGOCww9xOjc2PcdWh4XWh0325abNxc6iMLdiphbQXsad1eB/g5Zg/zXy/fRwv25 M7YMiaiAa2YAEDyogkMvX1ErQyoN3I9KKcAsxqQmftjpsosyeyfIi0KBJ+yNF8+X RNvR/wmzEeBjnJpoVCOI00gw5Zb9cjdTZAePrVJkm3wqUx0u98Rtj/Ws5P4LppWF jV7XJAkSo9yOZkfXYXUIArpLAtzgob/wfvEy32ESIzlDbQVI/fB7TeaowrM68xJj 7MEC1iATNW1KGWLnnt8VHY6x+qhH3tz+lyt+Qj5Hmr/BWCu0Rj12i2rbCh23SY4= =4rNI -----END PGP SIGNATURE----- From nobody Tue Dec 2 14:11:27 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED061A6F05 for ; Tue, 2 Dec 2014 14:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q9bSGyA9VOU for ; Tue, 2 Dec 2014 14:11:20 -0800 (PST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384261A1BFE for ; Tue, 2 Dec 2014 14:11:20 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id ij19so6244447vcb.36 for ; Tue, 02 Dec 2014 14:11:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g9/EkIWc3qlx4SgPGpu91er8VvuQI3uIdajzs+e53kU=; b=WbdM1EhIIOyua2PvaKXU1B+mXwqwNsjYGTzBHP6WHDlle3OWcPq0jLHb18spgWbePI yS7AzFHHfD8RHgoWwjethfwuSbr31K20vYEzIuUszgWhAKN/31bceIjobedU5LM+bQxh MI24eKMs0q7vWytQMRHZCtPssok0KRbO7/ENtXc+bgNUJ62M+p4n/XXzUQeAc7w2if/X ZREE/FmlH4rb0igrYXNgeMD7wq8ltY+qripvSQcquC5Y5eopgObVVz1ruzRTkHJhmAgb fOwihb337qh84Z9fMaXYojNoXsYXgcLcJWHKaYQKWL4r2d2aHWTQDgfocNqmtwBRsdbm TjfA== X-Gm-Message-State: ALoCoQln2uyORKlfNO2aXAqFoEhj69aTY0ZXq2lDCB0neObT7Ewa58GMItdHESINxh4jKEIQklCY MIME-Version: 1.0 X-Received: by 10.220.168.193 with SMTP id v1mr1020436vcy.39.1417558279442; Tue, 02 Dec 2014 14:11:19 -0800 (PST) Received: by 10.31.149.1 with HTTP; Tue, 2 Dec 2014 14:11:19 -0800 (PST) In-Reply-To: <547E36ED.1020205@cisco.com> References: <5470E68D.3040204@gmail.com> <547E36ED.1020205@cisco.com> Date: Tue, 2 Dec 2014 14:11:19 -0800 Message-ID: From: Richard Barnes To: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= Content-Type: multipart/alternative; boundary=047d7b5d450eb1e909050943016d Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/QBuDv0xLdgDVyIi92D9xnGbLxT0 Cc: draft-ietf-jose-cookbook.all@tools.ietf.org, The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 22:11:25 -0000 --047d7b5d450eb1e909050943016d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 2, 2014 at 2:02 PM, =E2=8C=98 Matt Miller = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello Yaron, > > Thank you very much for the review. My other comments are inline. > > On 11/22/14, 12:39 PM, Yaron Sheffer 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 document contains a large set of examples of JOSE objects: > > JWK, JWS and JWE. The document is purely informational, though in > > "real life", I would expect developers to use it as an > > authoritative source. > > > > Summary > > > > The document is ready to be published, with some issues. > > > > By the way, I really appreciate the large effort that surely went > > into creating this document. > > > > Thank you! It's always great to hear one's efforts are appreciated! > > > Details > > > > =E2=80=A2 Unless I missed it, the document does not mention a machine > > readable repository of these examples, which I am sure the author > > has created while writing the draft. Making such a repository > > publicly available would result in a much more useful resource than > > the current document, which essentially requires testers to scrape > > the document when creating their test cases. > > > > You did not miss it; I don't have a such a repository right now, but I > can put one together. Would something on github.com be acceptable, or > is there a better suggestion? > > > =E2=80=A2 (Not a comment to the current document:) I wonder why there i= s > > nothing explicit to distinguish a public key from a private key, > > and they are only distinguished by the presence or absence of > > several parameters, something that will not be natural to most > > developers. PEM is doing it very well: "-----BEGIN RSA PRIVATE > > KEY-----". > > > > =E2=80=A2 3.4: the text is contradictory re: zero-padding of the value = "d". > > Is it using the minimum number of octets, or exactly 256 octets > > (for a 2048-bit key)? > > > > The intent is that "d" is not zero-padded, and I overqualified in my > text. Would the following be acceptable? > > For a 2048-bit key, the field "n" is 256 octets in length when > decoded and the field "d" is not longer than 256 octets in > length when decoded. > > > > =E2=80=A2 Why invent a new term "octet key", for a simple "symmetric ke= y"? > > Very good point. Will fix in the next revision. > > > > > =E2=80=A2 4.2: the first sentence discusses PS256, the actual example i= s > > PS384. > > > > Silly error that I thought I fixed long ago /-: > > Will fix in the next revision. > > > =E2=80=A2 4.7: "only the JSON serialization" - please clarify which of = the > > three serializations is meant. Ditto top of 4.8. > > > > Will fix in the next revision. > > > =E2=80=A2 5.1.1: since this is a "cookbook", we should be using the pub= lic > > key, not the private key. A private key would only be used in rare > > cases. Similarly 5.2.1. > > > > The private keys are included for both reproduction (which only needs > the public key) and verification (which necessitates the private key). > > If I can put an online repository together, I can change the examples > to just include the public keys; otherwise would the following in 5.1 > (and 5.2) be sufficient? > > Note that only the RSA public key is necessary to perform the > encryption. However, the example includes the RSA private key to > allow readers to validate the example's output. > > > > =E2=80=A2 5.3.1: the "plaintext content" is a list of keys, which is > > either confusing to the reader, or an actual error in the > > document. > > > > It is not in error. The most common usecase for password-based > encryption was the import and export of key sets, and the Working > Group desired a thorough example. > > Would it help if the following is added to 5.3? > > A common use of password-based encryption is the import/export of > keys. Therefore this example uses a JWK Set for the plaintext > content instead of the plaintext from figure 72. > > > > =E2=80=A2 5.3.5: In the General Serialization version, I don't understa= nd > > why only the encrypted key is per-recipient. I would expect the > > PBES2 parameters too (e.g., the salt) to be per-recipient. > > Presumably each of them is using a different password, and there's > > no reason to use a common salt. Similarly in 5.4.5. > > > > For compatibility across serializations (compact, general JSON, > flattened JSON), all of the parameters need to be in the JWE Protected > Header. In the general serialization, that means only the > "encrypted_key" field is present for the (presumably) sole recipient. > > Would it be acceptable if the following were added to 5.3? > > Note that if password-based encryption is used for multiple > recipients, it is expected that each recipient use different > values for the PBES2 parameters "p2s" and "p2c". > > > =E2=80=A2 5.7: same as above, it makes sense for the per-recipient key = to > > have an ID, rather than the content encryption key (typically an > > ephemeral key). And then that ID should be in the per-recipient > > data in 5.7.5. And similarly for 5.8. The later Sec. 5.13 shows a > > syntax for multiple recipients that's inconsistent with the > > single-recipient case, which would make sense if we got rid of the > > array. > > > > For compatibility across serializations (compact, general JSON, > flattened JSON), all of the parameters need to be in the JWE Protected > Header. Also, the mixing of "recipients" and "encrypted_key"/"header" > in the top-level object is not permitted for the general serialization. > > > =E2=80=A2 5.11: this example seems strange to me - why would anybody NO= T > > want to integrity-protect the key ID and algorithm? I would prefer > > a more realistic example, or failing that, a recommendation to > > developers to avoid this practice. Similarly 5.12, which is an even > > worse idea. > > > > Integrity protection was thoroughly discussed in the JOSE WG. While > there are some limited attacks possible when some parameters are > unprotected, the WG felt there were enough use cases where these > attacks are mitigated through other means that integrity protection of > the part of all of the header is not always required. > It's also worth noting that of all of the CMS / S/MIME deployments that have existed for many years, none of them apply integrity protection to the CMS parameters that are equivalent to these JOSE parameters. --Richard > > > Thanks, Yaron > > > > _______________________________________________ secdir mailing > > list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > And thanks again for the thorough review. > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iQEcBAEBCgAGBQJUfjbtAAoJEDWi+S0W7cO1rSUH/1j3BZKQz5zwo/N9/nlfFwmS > JFGOCww9xOjc2PcdWh4XWh0325abNxc6iMLdiphbQXsad1eB/g5Zg/zXy/fRwv25 > M7YMiaiAa2YAEDyogkMvX1ErQyoN3I9KKcAsxqQmftjpsosyeyfIi0KBJ+yNF8+X > RNvR/wmzEeBjnJpoVCOI00gw5Zb9cjdTZAePrVJkm3wqUx0u98Rtj/Ws5P4LppWF > jV7XJAkSo9yOZkfXYXUIArpLAtzgob/wfvEy32ESIzlDbQVI/fB7TeaowrM68xJj > 7MEC1iATNW1KGWLnnt8VHY6x+qhH3tz+lyt+Qj5Hmr/BWCu0Rj12i2rbCh23SY4=3D > =3D4rNI > -----END PGP SIGNATURE----- > > --047d7b5d450eb1e909050943016d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 2, 2014 at 2:02 PM, =E2=8C=98 Matt Miller <mamille2@cisco= .com> wrote:
-----BEGIN PGP= SIGNED MESSAGE-----
Hash: SHA512

Hello Yaron,

Thank you very much for the review.=C2=A0 My other comments are inline.

On 11/22/14, 12:39 PM, Yaron Sheffer 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.=C2=A0 Document editors and=
> WG chairs should treat these comments just like any other last call > comments.
>
> This document contains a large set of examples of JOSE objects:
> JWK, JWS and JWE. The document is purely informational, though in
> "real life", I would expect developers to use it as an
> authoritative source.
>
> Summary
>
> The document is ready to be published, with some issues.
>
> By the way, I really appreciate the large effort that surely went
> into creating this document.
>

Thank you!=C2=A0 It's always great to hear one's efforts are= appreciated!

> Details
>
> =E2=80=A2 Unless I missed it, the document does not mention a machine<= br> > readable repository of these examples, which I am sure the author
> has created while writing the draft. Making such a repository
> publicly available would result in a much more useful resource than > the current document, which essentially requires testers to scrape
> the document when creating their test cases.
>

You did not miss it; I don't have a such a repository right now,= but I
can put one together.=C2=A0 Would something on github.com be acceptable, or
is there a better suggestion?

> =E2=80=A2 (Not a comment to the current document:) I wonder why there = is
> nothing explicit to distinguish a public key from a private key,
> and they are only distinguished by the presence or absence of
> several parameters, something that will not be natural to most
> developers. PEM is doing it very well: "-----BEGIN RSA PRIVATE > KEY-----".
>
> =E2=80=A2 3.4: the text is contradictory re: zero-padding of the value= "d".
> Is it using the minimum number of octets, or exactly 256 octets
> (for a 2048-bit key)?
>

The intent is that "d" is not zero-padded, and I overquali= fied in my
text.=C2=A0 Would the following be acceptable?

=C2=A0 =C2=A0For a 2048-bit key, the field "n" is 256 octets in l= ength when
=C2=A0 =C2=A0decoded and the field "d" is not longer than 256 oct= ets in
=C2=A0 =C2=A0length when decoded.


> =E2=80=A2 Why invent a new term "octet key", for a simple &q= uot;symmetric key"?

Very good point.=C2=A0 Will fix in the next revision.

>
> =E2=80=A2 4.2: the first sentence discusses PS256, the actual example = is
> PS384.
>

Silly error that I thought I fixed long ago /-:

Will fix in the next revision.

> =E2=80=A2 4.7: "only the JSON serialization" - please clarif= y which of the
> three serializations is meant. Ditto top of 4.8.
>

Will fix in the next revision.

> =E2=80=A2 5.1.1: since this is a "cookbook", we should be us= ing the public
> key, not the private key. A private key would only be used in rare
> cases. Similarly 5.2.1.
>

The private keys are included for both reproduction (which only need= s
the public key) and verification (which necessitates the private key).

If I can put an online repository together, I can change the examples
to just include the public keys; otherwise would the following in 5.1
(and 5.2) be sufficient?

=C2=A0 =C2=A0Note that only the RSA public key is necessary to perform the<= br> =C2=A0 =C2=A0encryption.=C2=A0 However, the example includes the RSA privat= e key to
=C2=A0 =C2=A0allow readers to validate the example's output.


> =E2=80=A2 5.3.1: the "plaintext content" is a list of keys, = which is
> either confusing to the reader, or an actual error in the
> document.
>

It is not in error.=C2=A0 The most common usecase for password-based=
encryption was the import and export of key sets, and the Working
Group desired a thorough example.

Would it help if the following is added to 5.3?

=C2=A0 =C2=A0A common use of password-based encryption is the import/export= of
=C2=A0 =C2=A0keys.=C2=A0 Therefore this example uses a JWK Set for the plai= ntext
=C2=A0 =C2=A0content instead of the plaintext from figure 72.


> =E2=80=A2 5.3.5: In the General Serialization version, I don't und= erstand
> why only the encrypted key is per-recipient. I would expect the
> PBES2 parameters too (e.g., the salt)=C2=A0 to be per-recipient.
> Presumably each of them is using a different password, and there's=
> no reason to use a common salt. Similarly in 5.4.5.
>

For compatibility across serializations (compact, general JSON,
flattened JSON), all of the parameters need to be in the JWE Protected
Header.=C2=A0 In the general serialization, that means only the
"encrypted_key" field is present for the (presumably) sole recipi= ent.

Would it be acceptable if the following were added to 5.3?

=C2=A0 =C2=A0Note that if password-based encryption is used for multiple =C2=A0 =C2=A0recipients, it is expected that each recipient use different =C2=A0 =C2=A0values for the PBES2 parameters "p2s" and "p2c&= quot;.

> =E2=80=A2 5.7: same as above, it makes sense for the per-recipient key= to
> have an ID, rather than the content encryption key (typically an
> ephemeral key). And then that ID should be in the per-recipient
> data in 5.7.5. And similarly for 5.8. The later Sec. 5.13 shows a
> syntax for multiple recipients that's inconsistent with the
> single-recipient case, which would make sense if we got rid of the
> array.
>

For compatibility across serializations (compact, general JSON,
flattened JSON), all of the parameters need to be in the JWE Protected
Header.=C2=A0 Also, the mixing of "recipients" and "encrypte= d_key"/"header"
in the top-level object is not permitted for the general serialization.

> =E2=80=A2 5.11: this example seems strange to me - why would anybody N= OT
> want to integrity-protect the key ID and algorithm? I would prefer
> a more realistic example, or failing that, a recommendation to
> developers to avoid this practice. Similarly 5.12, which is an even > worse idea.
>

Integrity protection was thoroughly discussed in the JOSE WG.=C2=A0 = While
there are some limited attacks possible when some parameters are
unprotected, the WG felt there were enough use cases where these
attacks are mitigated through other means that integrity protection of
the part of all of the header is not always required.
=
It's also worth noting that of all of the CMS / S/MIME d= eployments that have existed for many years, none of them apply integrity p= rotection to the CMS parameters that are equivalent to these JOSE parameter= s.

--Richard




> Thanks, Yaron
>
> _______________________________________________ secdir mailing
> list secdir@ietf.org https://ww= w.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

And thanks again for the thorough review.

- --
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org

iQEcBAEBCgAGBQJUfjbtAAoJEDWi+S0W7cO1rSUH/1j3BZKQz5zwo/N9/nlfFwmS
JFGOCww9xOjc2PcdWh4XWh0325abNxc6iMLdiphbQXsad1eB/g5Zg/zXy/fRwv25
M7YMiaiAa2YAEDyogkMvX1ErQyoN3I9KKcAsxqQmftjpsosyeyfIi0KBJ+yNF8+X
RNvR/wmzEeBjnJpoVCOI00gw5Zb9cjdTZAePrVJkm3wqUx0u98Rtj/Ws5P4LppWF
jV7XJAkSo9yOZkfXYXUIArpLAtzgob/wfvEy32ESIzlDbQVI/fB7TeaowrM68xJj
7MEC1iATNW1KGWLnnt8VHY6x+qhH3tz+lyt+Qj5Hmr/BWCu0Rj12i2rbCh23SY4=3D
=3D4rNI
-----END PGP SIGNATURE-----


--047d7b5d450eb1e909050943016d-- From nobody Tue Dec 2 14:44:05 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAEE1A1ACE; Tue, 2 Dec 2014 14:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLNkqJOniT-y; Tue, 2 Dec 2014 14:43:56 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7091A1AB8; Tue, 2 Dec 2014 14:43:56 -0800 (PST) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id A645C38F45; Tue, 2 Dec 2014 14:43:55 -0800 (PST) From: "Jim Schaad" To: "'? Matt Miller'" , "'Yaron Sheffer'" , "'IETF Security Directorate'" , "'The IESG'" , References: <5470E68D.3040204@gmail.com> <547E36ED.1020205@cisco.com> In-Reply-To: <547E36ED.1020205@cisco.com> Date: Tue, 2 Dec 2014 14:43:29 -0800 Message-ID: <03c001d00e81$65300400$2f900c00$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQCfLK/cFUOZt7KXRlpowFM5JqM6CgBG564yntxxgwA= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ChxPsDc22-rDxav5cEo55piHVnA Subject: Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 22:43:59 -0000 > -----Original Message----- > From: ? Matt Miller [mailto:mamille2@cisco.com] > Sent: Tuesday, December 02, 2014 2:02 PM > To: Yaron Sheffer; IETF Security Directorate; The IESG; = draft-ietf-jose- > cookbook.all@tools.ietf.org > Subject: Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Hello Yaron, >=20 > Thank you very much for the review. My other comments are inline. >=20 > On 11/22/14, 12:39 PM, Yaron Sheffer 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 document contains a large set of examples of JOSE objects: > > JWK, JWS and JWE. The document is purely informational, though in > > "real life", I would expect developers to use it as an authoritative > > source. > > > > Summary > > > > The document is ready to be published, with some issues. > > > > By the way, I really appreciate the large effort that surely went = into > > creating this document. > > >=20 > Thank you! It's always great to hear one's efforts are appreciated! >=20 > > Details > > > > Unless I missed it, the document does not mention a machine = readable > > repository of these examples, which I am sure the author has created > > while writing the draft. Making such a repository publicly available > > would result in a much more useful resource than the current = document, > > which essentially requires testers to scrape the document when > > creating their test cases. > > >=20 > You did not miss it; I don't have a such a repository right now, but I = can put > one together. Would something on github.com be acceptable, or is = there a > better suggestion? >=20 > > (Not a comment to the current document:) I wonder why there is > > nothing explicit to distinguish a public key from a private key, and > > they are only distinguished by the presence or absence of several > > parameters, something that will not be natural to most developers. = PEM > > is doing it very well: "-----BEGIN RSA PRIVATE KEY-----". > > > > 3.4: the text is contradictory re: zero-padding of the value "d". > > Is it using the minimum number of octets, or exactly 256 octets (for = a > > 2048-bit key)? > > >=20 > The intent is that "d" is not zero-padded, and I overqualified in my = text. > Would the following be acceptable? >=20 > For a 2048-bit key, the field "n" is 256 octets in length when > decoded and the field "d" is not longer than 256 octets in > length when decoded. >=20 >=20 > > Why invent a new term "octet key", for a simple "symmetric key"? >=20 > Very good point. Will fix in the next revision. >=20 > > > > 4.2: the first sentence discusses PS256, the actual example is > > PS384. > > >=20 > Silly error that I thought I fixed long ago /-: >=20 > Will fix in the next revision. >=20 > > 4.7: "only the JSON serialization" - please clarify which of the > > three serializations is meant. Ditto top of 4.8. > > >=20 > Will fix in the next revision. >=20 > > 5.1.1: since this is a "cookbook", we should be using the public > > key, not the private key. A private key would only be used in rare > > cases. Similarly 5.2.1. > > >=20 > The private keys are included for both reproduction (which only needs = the > public key) and verification (which necessitates the private key). >=20 > If I can put an online repository together, I can change the examples = to just > include the public keys; otherwise would the following in 5.1 (and = 5.2) be > sufficient? >=20 > Note that only the RSA public key is necessary to perform the > encryption. However, the example includes the RSA private key to > allow readers to validate the example's output. >=20 I believe that it makes far more sense to have the private keys as well = as the public keys. Historically in S/MIME people stated by trying to = decrypt known good messages and then went on to try and encrypt and test = against a known good decryption implementation. Additionally, one would of course need to have private keys on the = signing side as well. Jim >=20 > > 5.3.1: the "plaintext content" is a list of keys, which is either > > confusing to the reader, or an actual error in the document. > > >=20 > It is not in error. The most common usecase for password-based > encryption was the import and export of key sets, and the Working > Group desired a thorough example. >=20 > Would it help if the following is added to 5.3? >=20 > A common use of password-based encryption is the import/export of > keys. Therefore this example uses a JWK Set for the plaintext > content instead of the plaintext from figure 72. >=20 >=20 > > 5.3.5: In the General Serialization version, I don't understand > > why only the encrypted key is per-recipient. I would expect the > > PBES2 parameters too (e.g., the salt) to be per-recipient. > > Presumably each of them is using a different password, and there's > > no reason to use a common salt. Similarly in 5.4.5. > > >=20 > For compatibility across serializations (compact, general JSON, > flattened JSON), all of the parameters need to be in the JWE Protected > Header. In the general serialization, that means only the > "encrypted_key" field is present for the (presumably) sole recipient. >=20 > Would it be acceptable if the following were added to 5.3? >=20 > Note that if password-based encryption is used for multiple > recipients, it is expected that each recipient use different > values for the PBES2 parameters "p2s" and "p2c". >=20 > > 5.7: same as above, it makes sense for the per-recipient key to > > have an ID, rather than the content encryption key (typically an > > ephemeral key). And then that ID should be in the per-recipient > > data in 5.7.5. And similarly for 5.8. The later Sec. 5.13 shows a > > syntax for multiple recipients that's inconsistent with the > > single-recipient case, which would make sense if we got rid of the > > array. > > >=20 > For compatibility across serializations (compact, general JSON, > flattened JSON), all of the parameters need to be in the JWE Protected > Header. Also, the mixing of "recipients" and "encrypted_key"/"header" > in the top-level object is not permitted for the general = serialization. >=20 > > 5.11: this example seems strange to me - why would anybody NOT > > want to integrity-protect the key ID and algorithm? I would prefer > > a more realistic example, or failing that, a recommendation to > > developers to avoid this practice. Similarly 5.12, which is an even > > worse idea. > > >=20 > Integrity protection was thoroughly discussed in the JOSE WG. While > there are some limited attacks possible when some parameters are > unprotected, the WG felt there were enough use cases where these > attacks are mitigated through other means that integrity protection of > the part of all of the header is not always required. >=20 >=20 > > Thanks, Yaron > > > > _______________________________________________ secdir > mailing > > list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 > And thanks again for the thorough review. >=20 > - -- > - - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org >=20 > iQEcBAEBCgAGBQJUfjbtAAoJEDWi+S0W7cO1rSUH/1j3BZKQz5zwo/N9/nlfFw > mS > JFGOCww9xOjc2PcdWh4XWh0325abNxc6iMLdiphbQXsad1eB/g5Zg/zXy/fRw > v25 > M7YMiaiAa2YAEDyogkMvX1ErQyoN3I9KKcAsxqQmftjpsosyeyfIi0KBJ+yNF8+X > RNvR/wmzEeBjnJpoVCOI00gw5Zb9cjdTZAePrVJkm3wqUx0u98Rtj/Ws5P4Lpp > WF > jV7XJAkSo9yOZkfXYXUIArpLAtzgob/wfvEy32ESIzlDbQVI/fB7TeaowrM68xJj > 7MEC1iATNW1KGWLnnt8VHY6x+qhH3tz+lyt+Qj5Hmr/BWCu0Rj12i2rbCh23SY > 4=3D > =3D4rNI > -----END PGP SIGNATURE----- From nobody Wed Dec 3 04:02:07 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3401A1A74; Wed, 3 Dec 2014 04:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3E3WasfmPFf; Wed, 3 Dec 2014 04:02:04 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C941A1A7F; Wed, 3 Dec 2014 04:01:48 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so19783326wgh.20 for ; Wed, 03 Dec 2014 04:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Z8dvQ+NwRS8WSbWUNKB6wiIEkzMUpbc0SpJd44UC3kE=; b=gJT7uImU1Aq0rFL7Gi5cHL/EGkH5WyKedb00/fncnFaazAOKDKTJOTQaLDw6x+vV/x r3qtkB4atSjscfbrH34tkoFxnVIemClGFKlsJF9yjE1d21V7qPJwOG1E01iOI6Yo6TBR T8kR6s+gXd2IFlwdtIXisgAfUxxz7hpa1jknw62wIVaOTlGw5Wr/ZWOs5Ya1Zbh4Zlyy jsxxROMB9chLb69dCWuzSHATYsuxPKWa4cOOsXOKdLQF+BnOD0gnsJLh5mWcpVmoJwbP CqlBghgSCh7VGXeS/DtbKIqFmMNt67ODfUwgBYfgwhDfcAcrxLyVBQOgF0gAlTb6kxdy /dxg== X-Received: by 10.180.96.162 with SMTP id dt2mr101579120wib.66.1417608107669; Wed, 03 Dec 2014 04:01:47 -0800 (PST) Received: from [172.24.251.68] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id h13sm50477870wiw.4.2014.12.03.04.01.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 04:01:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1C994D20-EC69-4508-98B3-36AA56E86263" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: Date: Wed, 3 Dec 2014 14:01:44 +0200 Message-Id: <715DF31C-F5BF-4DBC-8D0F-6595F7B1F692@gmail.com> References: To: =?utf-8?Q?Magnus_Nystr=C3=B6m?= X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/f6uOd4JLvOevGlFdEz_tpM9TV_Q Cc: IESG , draft-josefsson-pkix-textual@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-josefsson-pkix-textual X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 12:02:05 -0000 --Apple-Mail=_1C994D20-EC69-4508-98B3-36AA56E86263 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Magnus [adding IESG] See below > On Dec 2, 2014, at 4:19 PM, Magnus Nystr=C3=B6m = wrote: >=20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > This memo documents textual encodings of various well-established = PKI-related data structures and formats. The document is intended to be = published as a Standards-Track RFC. > Comments and suggestions: >=20 > Section 5.1: > - For clarity and common keyword usage, suggest replacing "The = encoded data MUST be a BER (DER strongly preferred) encoded ASN.1..." = with: "The encoded data MUST be BER and SHOULD be a DER encoded = ASN.1..." (In fact this comment goes for all places where you have text = like "MUST be a BER (DER [strongly] preferred" - better to use = established RFC 2119 language). In general (this is not a hard and fast rule) a SHOULD should come with = an explanation of when it isn=E2=80=99t needed. Unless we have a good = case for saying when it=E2=80=99s OK to use non-DER, I=E2=80=99d rather = stick with the non-2119 =E2=80=9Cprefer=E2=80=9D. > - I wonder why you state "Parsers are NOT RECOMMENDED to treat "X509 = CERTIFICATE" or "X.509 CERTIFICATE" as equivalent to "CERTIFICATE", but = a valid exception may be for backwards compatibility (potentially = together with a warning)" since to my knowledge, they all refer to the = same structure and in the spirit of "strict in issuance, generous in = receipt", it would seem to be better to state: ""Parsers MAY treat ... = as equivalent to "CERTIFICATE" =E2=80=9C ? I=E2=80=99ll leave this to the authors to answer. > - I also wonder about the warning above since if the structure indeed = does parse as a certificate, what value would the warning bring (and to = whom)? ditto > Section 5.3: > I disagree with the deprecation of .cer in favor of .crt. The .cer = convention is used broadly. I would suggest updating the text to = recommend use of .crt OR .cer. Better yet, remove the section, since = this document specifically is about textual encodings and not file = extension naming and you do not discuss extension naming elsewhere. IDK. These formats are used mostly in files, and despite twenty years of = attempts, classification by extension is still the norm. .cer files = often contain either BER or a textual representation, while .crt tends = to mostly be textual. I don=E2=80=99t see why we shouldn=E2=80=99t = document this convention. > Section 6: > Same comments as for Section 5.1 above, but for CRLs... >=20 > Section 7: > Same comment as my first for Section 5.1. I note that you have the = same language with regards to parser flexibility here that I have = suggested for Section 5.1 and Section 6. >=20 > Security Considerations: > No particular comments. > =20 > =E2=80=94 Magnus Yoav --Apple-Mail=_1C994D20-EC69-4508-98B3-36AA56E86263 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Magnus

[adding IESG]

See below

On Dec 2, 2014, at 4:19 PM, = Magnus Nystr=C3=B6m <magnusn@gmail.com> wrote:

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

This memo = documents textual encodings of various well-established PKI-related data = structures and formats. The document is intended to be published as a = Standards-Track RFC.
Comments and suggestions:

Section 5.1:
 - For clarity and common keyword usage, suggest = replacing "The encoded data MUST be a BER (DER strongly preferred) = encoded ASN.1..." with: "The encoded data MUST be BER and SHOULD be a = DER encoded ASN.1..." (In fact this comment goes for all places where = you have text like "MUST be a BER (DER [strongly] preferred" - better to = use established RFC 2119 language).

In general (this is not a hard and fast rule) a = SHOULD should come with an explanation of when it isn=E2=80=99t needed. = Unless we have a good case for saying when it=E2=80=99s OK to use = non-DER, I=E2=80=99d rather stick with the non-2119 = =E2=80=9Cprefer=E2=80=9D.

- I = wonder why you state "Parsers are NOT RECOMMENDED to treat "X509 CERTIFICATE" or "X.509 CERTIFICATE" as equivalent to "CERTIFICATE", but a valid exception may be for backwards compatibility (potentially together with a warning)" since = to my knowledge, they all refer to the same structure and in the spirit = of "strict in issuance, generous in receipt", it would seem to be better = to state: ""Parsers MAY treat ... as equivalent to "CERTIFICATE" =E2=80=9C= ?

I=E2=80=99ll leave this to the authors to = answer.

- I also wonder about the warning = above since if the structure indeed does parse as a certificate, what = value would the warning bring (and to whom)?

ditto

Section 5.3:
I disagree with the deprecation of .cer in favor = of .crt. The .cer convention is used broadly. I would suggest updating = the text to recommend use of .crt OR .cer. Better yet, remove the = section, since this document specifically is about textual encodings and = not file extension naming and you do not discuss extension naming = elsewhere.

IDK. = These formats are used mostly in files, and despite twenty years of = attempts, classification by extension is still the norm. .cer files = often contain either BER or a textual representation, while .crt tends = to mostly be textual. I don=E2=80=99t see why we shouldn=E2=80=99t = document this convention.

Section 6:
Same comments as for = Section 5.1 above, but for CRLs...

Section 7:
Same comment as my first = for Section 5.1. I note that you have the same language with regards to = parser flexibility here that I have suggested for Section 5.1 and = Section 6.

Security Considerations:
No particular comments.
 
=E2=80=94 Magnus

Yoav


= --Apple-Mail=_1C994D20-EC69-4508-98B3-36AA56E86263-- From nobody Thu Dec 4 03:23:17 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480A31A01F2; Thu, 4 Dec 2014 03:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSsEmT_iX1LP; Thu, 4 Dec 2014 03:23:12 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 19FE71A0164; Thu, 4 Dec 2014 03:23:11 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sB4BN87n010846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Dec 2014 13:23:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sB4BN77g013692; Thu, 4 Dec 2014 13:23:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21632.17435.615548.514967@fireball.kivinen.iki.fi> Date: Thu, 4 Dec 2014 13:23:07 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-richardson-6tisch--security-6top.all@tools.ietf.org X-Edit-Time: 127 min X-Total-Time: 96 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xqPZrSNhkXyD8n4Y5yerG2BmSVc Subject: [secdir] Secdir review of draft-richardson-6tisch--security-6top-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 11:23: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. This is an early review, so these comments are mostly useful for the draft authors. This is first of the early reviews, I assigned this to myself in addition to normal round robin assignment. This is because I have been involved with 802.15.4 quite a lot lately, and I assumed that I would have something to say about this draft... This draft describes the part of the security architecture of the 6tisch. This draft describes how new node bootstraps itself to be part of the network and how to configure the node to be part of the 6tisch schedule. This document suggest a method where there is sepearate joining network with well-known key to be used when joining the network, i.e. device would first find out this joining network, talk to devices there, and then get the authorization to join the real network and get keys for that. This method does not work that well. First of all, I am not sure how many 15.4 coordinators can actually send out multiple becons at the same time. Usually a node starts sending beacons by calling MLME-START.request operation and while it does not say it directly it seems to indicate that new call to it will change the existing parameters of the beacon configuration, not start sending both sets, i.e. there is no way to use that to send two different set of beacons with that call. There is manual call MLME-BEACON.request to send beacons out, but it takes lots of its configuration from PIB, thus it cannot really be different from the normal beacon (that call is mostly meant for non-beacon enabled PANs where beacons are sent when other node asks for them by sending beacon request frame). So I do not think it is possible to have separate network for joining only. This would mean that there would be only one network, i.e one set of beacons, and all those beacons would be protected by the same key, and in draft proposes that to be the well-known key. The security of the TSCH depends on the fact that all nodes in the network knows the globally shared unique timestamp called ASN (absolute slot number). This value is used when calculating the AES-CCM Nonce, and if node can be tricked to belive ASN is lower than it was when the node last time sent packets out this can cause security vulnerability. The ASN is distributed to the nodes inside the beacon frames (inside the TSCH Syncronization IE, that is inside the Nested MLME Payload IE). If the beacons are protected by the well known key, then attackers will know that key, thus they can fake the beacons and perhaps trick the already existing members joining the network to use wrong ASN, or use wrong TSCH parameters / schedule. Regardless what key is used protecting the beacon, the attacker can always replay old frames giving out old ASN, so protection against wrong ASN needs to be done so that each node will store the last ASN they have seen to the stable storage, and does not allow the ASN to go backwards ever (same thing is done for the non-TSCH nodes for each frame counter they are using for sending or receiving). This storing of the ASN needs to happen every time device goes to sleep (or it needs to know time itself). Protection against the invalid TSCH parameters / schedule would also be very useful and using well-known key for beacons would not provide that. Because of all those reason, I would recommend that the beacons do use separate beacon key, which is NOT well known, but which is generated by the PAN coordinator, and distributed to everybody in the network (i.e. global broadcast key for beacons). As the joining node will need to know the parameters of the network, before it can know when it is allowed to send data to network, it needs to be able to read the beacon, so the beacon would need to use authentication only, i.e. no encryption would be used. The 802.15.4 has special text in there saying that when doing beacon scanning the device will store the information from the beacons it see even when it cannot do security processing for the frame. I.e. even if the node does not know the authentication key used to protect the beacon, it can see the beacon, parse it, and extract all parameters from it. The nodes knowing the beacon key, can actually verify the beacon MIC (message integrity code) and be sure it is proper and generated by the coordinator belonging to the network. As I described earlier, this does not protect the nodes who has lost sync with network (i.e. who has been sleeping so long that they do not know the current schedule and current ASN) against replays of the beacons by attacker. On the other hand as the AES-CCM nonce also has the extended address of the sender there, it is enough for the node to make sure he will never go backwards for ASN when sending packets using current network key. If he is tricked to send frames using wrong ASN, then other real nodes in the network will not be able to read those, but that is just DoS, not real security vulnerability, which would happen if he would generate frame with old ASN he has already used, which would generate same AES-CCM nonce. -- Another thing that could be clarified in this draft is the use of 802.15.9. The 15.9 allows generating pairwise keys between the nodes in the network and after those are created, it allows distributing the multicast or broadcast keys from one peer to another. So when looking at the figure 1 in the draft, the 802.15.9 would happen between the beacon and the router solicitation. I.e. when joining node sees the beacon from a coordinator it can start 15.9 negotiation with the coordinator and create pairwise keys with the coordinator. This connection could either be properly authenticated using for example raw-public keys, certificates or EAP (depending what key management protocol is used inside the 15.9), or it could be just unauthenticated first step protection. Then all future communications from the joining node to the coordinator (== joining assistant (proxy)) would be protected by that key. If real authentication method is used between the joining node and joining assistant, then this would actually be only thing needed to set up the security. For example if the joining node uses raw-public key and the join assistant then makes query to the JCE whether this key (or more accurately hash of key) should be allowed to join the network or not, then the JCE could verify that hash of the key is one of the devices that should be allowed to join the network. I.e. the manufacturer could create the raw public key on the device when it is manufactured, and then give the hashes of the keys of all devices shipped to site in electronical format (CD, over the network, whatever), and those hashes could be listed in the JCE before the device is ever turned on. When the device is turned on, the JCE would already know that this device is one of the new devices... This of course does not protect the device from joining wrong network. It is not clear for me how the current draft plans to solve the authentication problem. It has some text about using certificates and chains and certificates with serial numbers in format of extended address etc, but I do not think it really solves the problem. I do not think it is enough for the JCE to know that this device is in fact manufactured by company X, i.e. it has certificate from CA from X. JCE would rather know that this is actually the device that was supposed to be installed on site, i.e. I think it will need some kind of whitelist listing devices allowed to connect. For that whiteliste it is better to use hash of the public key on the device, than the extended address. -- One more aspect that is missing in the draft (or it might be, that it is on some other draft), is the fact that security in 15.4 is quite low level, i.e. almost everything is left for the upper layer (== this layer) to solve. For example the AES-CCM keys are identified using the Key Source and Key Index (and Key Identifier mode specifying how those are interpreted), but the management which Key Source and Key Index is used, is left for the upper layer to solve. I.e. when this draft says we use some key to protect the beacons (whether it is the well known key, or the per network broadcast beacon key), we need some document to map that to Key Source and Key Index. I.e. how does the node know which key is to be used when sending beacons, and how is it identified. This document (or some other document) can either specify protocol to distribute this information, or we can use fixed set for those. I.e. we could for example say that the beacon broadcast key is always "owned" by the JCE, which means that the Key Source of the key is always extended address of the JCE (== 8 octet KeySource). Or we can specify that short address of 0xfff0 from PAN 0xfff0 is reserved for the beacon broadcast key (== 4 octet KeySource field). I.e. we need to specify how different keys in the network are really identified. -- Hopefully these comments are useful for going forward with this draft. This draft is still in quite early phases, and actually reviewing it for more concrete proposals is hard, but on the other hand reviewing it in this early phases means that bigger changes can be done... -- kivinen@iki.fi From nobody Thu Dec 4 04:06:56 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED2D1A0277 for ; Thu, 4 Dec 2014 04:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McjaUx9MajuP for ; Thu, 4 Dec 2014 04:06:52 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 E5C481A0248 for ; Thu, 4 Dec 2014 04:06:51 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sB4C6olH026960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 4 Dec 2014 14:06:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sB4C6nw1022036; Thu, 4 Dec 2014 14:06:50 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21632.20057.601835.849308@fireball.kivinen.iki.fi> Date: Thu, 4 Dec 2014 14:06:49 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/A4KqClQ2GTDc8RRQ7Zr4hx98CTI Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 12:06:54 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Shaun Cooley is next in the rotation. For telechat 2014-12-04 Reviewer LC end Draft Sandy Murphy T 2014-11-25 draft-mcdonald-ipps-uri-scheme-17 Vincent Roca T 2014-11-27 draft-ietf-ccamp-rwa-info-23 For telechat 2014-12-18 Chris Lonvick TR2014-07-10 draft-secretaries-good-practices-07 Tina TSOU T 2014-12-08 draft-ietf-dnsop-dnssec-key-timing-06 Sean Turner T 2014-12-15 draft-ietf-ianaplan-icg-response-06 Carl Wallace T 2014-12-05 draft-ietf-json-text-sequence-09 Last calls and special requests: Derek Atkins 2014-12-29 draft-pechanec-pkcs11uri-16 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-07 Matt Lepinski 2014-11-18 draft-nottingham-safe-hint-05 Hilarie Orman E None draft-richardson-6tisch--security-6top-04 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Hannes Tschofenig 2014-12-01 draft-ietf-opsec-dhcpv6-shield-04 Sean Turner 2014-10-13 draft-ietf-mpls-lsp-ping-relay-reply-05 David Waltermire 2014-12-09 draft-ietf-kitten-cammac-00 Sam Weiler 2014-12-08 draft-ietf-l3vpn-acceptown-community-08 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-12 Brian Weis 2014-12-08 draft-ietf-l3vpn-end-system-04 Klaas Wierenga 2014-12-08 draft-ietf-mpls-tp-te-mib-09 Paul Wouters 2014-12-04 draft-ietf-tcpm-accecn-reqs-07 Tom Yu 2014-12-10 draft-ietf-tls-prohibiting-rc4-01 Dacheng Zhang 2014-12-16 draft-ietf-mile-enum-reference-format-10 -- kivinen@iki.fi From nobody Thu Dec 4 09:16:43 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45281A1B56 for ; Thu, 4 Dec 2014 09:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RybL2hL01h_0 for ; Thu, 4 Dec 2014 09:16:39 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85311A0266 for ; Thu, 4 Dec 2014 09:16:24 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id F0D2328B003D; Thu, 4 Dec 2014 12:16:23 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id CDCD71F804E; Thu, 4 Dec 2014 12:16:23 -0500 (EST) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_ED6918FF-6A4C-4486-B469-E9BF531AE7E4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 4 Dec 2014 12:16:23 -0500 Message-Id: <9C3E7BDB-82F5-4A75-82E6-F8E1075A84CD@tislabs.com> To: "secdir@ietf.org" , draft-mcdonald-ipps-uri-scheme@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/QPNYdlDZrhaVRkG-IgkCDxMSbzA Subject: [secdir] secdir review on draft-mcdonald-ipps-uri-scheme X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 17:16:42 -0000 --Apple-Mail=_ED6918FF-6A4C-4486-B469-E9BF531AE7E4 Content-Transfer-Encoding: quoted-printable 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. = Document editors and WG chairs should treat these comments just like = any other last call comments. This document proposes a new ipps: URI for secure IPP protocol use. The security considerations section of this document seems quite = thorough (and adds considerably to the original IPP documents series - = 2910, 2911, 2567, etc.) The authors should be complimented on the document clarity and = structure. Some comments below. -Sandy Section 1 This document updates [RFC2910] and [RFC2911]. =20 =20 This document updates: =20 It is easy to see that this documents covers topics in the sections listed, but not clear what the "update" is exactly. For example: b) IPP/1.1 Model and Semantics [RFC2911], by extending section 4.1.6=20= 'uriScheme' and section 4.4.1 'printer-uri-supported'; and=20 RFC2911 section 4.1.6 lists some "Standard values for this syntax type" for the uriScheme attibute - is it intended that this document add ipps: to that list? That would seem logical but is not explictly stated. section 4.2 The abstract protocol defined in IPP/1.1 Model and Semantics [RFC2911] places a limit of 1023 octets (NOT characters) on the length of a URI. =20 ... =20 Per PWG IPP Everywhere [PWG5100.14], for compatibility with existing IPP implementations, IPP Printers SHOULD NOT generate (or allow administrators to configure) URI lengths above 255 octets, because many older IPP Client implementations do not properly support these lengths. =20 Is this a concern for ipps in particular, or would it apply to ipp as well? (Is this one of the updates to RFC2911/RFC2910?) section 6.2.4 Either service discovery or directory protocols SHOULD be used first=20= or an IPP Client SHOULD first establish an 'ipp' connection (without=20= TLS [RFC5246] or any client authentication) to the target IPP Printer and use a Get-Printer-Attributes operation to discover the required IPP Client authentication mechanism(s) associated with a given 'ipps' URI. I am not sure what the client would do with the information of the Client Authentication types before it attempted the ipps connection, but retrieving that information with no protection seems dangerous. At least, should the unprotected request be limited to mention the ipps URI as the target and request only the uri-authentication-supported attribute? To at least limit the possibility that the response will include all attributes and the client will accept them before attempting the ipps connection? The following is a discussion of the potential for a tiered network of = Printer Objects. This document talks about "a downstream IPP printer" and "print gateway" and defines an IPP Printer as something that can receive operations from an "upstream" client or printer. I was curious as to whether the protocol is intended to be used in a hierarchy. Looking at other parts of the IPP document set: RFC2911 talks about possible "n-tier" client/server systems (sec 1.1), a client as a print server that sends requests to "another "downstream" print server." (sec 2.1) "Forwarding Servers" as a "gateway to a printing system" (sec 4.3.7.1), forwarding to a print system (sec 4.3.8), etc. RFC3196 talks about "forward received jobs (and other requests) to other devices and print servers/services" (sec 2). PWG 5100.14 (IPP Everywhere) speaks of a Printer as possibly representing a Logical Device which might forward the job (sec 2.2), and Indirect Imaging as "an intermediary service in a different administrative domain" (sec 2.3). The IPP protocol itself provides no mechanism to represent or create such interactions. But each Printer object can "turn around" and open a new IPP exchange, to accomplish the job it had received, and the originator will not be aware. And of course each intermediate service also has the opportunity to modify the job - change the attributes (eg copies) or even for an inline document to modify what is printed. There is also no way to know that the new IPP exchange used ipps. Perhaps this is just a standard part of any use of http - you never know whether the end site is employing other sites to provide the service. But since this seems to be part of the envisioned use case, not just an implementation device, it seems proper to consider the security in such circumstances. RFC2911 section 8.1.3, for example, notes that a document that is a reference to a URI: the print request can contain a reference, or pointer, to the document instead of the actual document itself (see sections 3.2.2 and 3.3.2). Standard methods currently do not exist for remote entities to "assume" the credentials of a client for forwarding requests to a 3rd party. It is anticipated that Print-By- Reference will be used to access "public" documents and that sophisticated methods for authenticating "proxies" is not specified in this document. Perhaps a similar thought applies to a tiered print service. Logical Devices, forwarding of job requests, printer objects that speak IPP to other printer objects, are anticipated to be used in environments where the client places complete trust in the print service or Printer object that it contacts and recursively any other services it might employ. Methods for authenticating Prineter objects, print services, etc, "downstream" of the Printer Object contacted by ipps are not specified. --Apple-Mail=_ED6918FF-6A4C-4486-B469-E9BF531AE7E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUgJbnAAoJEHplpQeet0IZ6vsP/0k0NYrT1k3EWuKMugLH2yaF Otd3PxH+cc1IbZSVVAv3cyidFmj+hRrm1/eo0sJnOzg6jNftPcTMkbh2cw9uswBL uZFdX6jlIcCdb6n01rKxZcgY1+lZSSGSvEl1nNIVL5ogBph1ScacZJhbumzs+wbU eMyLt7Y9I/lr8gVMfJFrrMp036NGptaUSzhQQdY9fN66022kREB9KthFz0vbT4jp hoIG8IpA3R3v/RR5U+iZ0aFXPfCxaRrvFJiJJfPsIl1cospxI28zHXzxKR8mhYU4 56xTdJxES60cFQ2yE47S4MMnrEC+tG6llkqJNi6hGH6qNyKwjAGVSSc6gBMIDYBO WKhA4D5824gRIOtP4XZ4awl0X8bXWMpyvM6X3xV01b/ldQkk5cV2Wa8TmXSJPFCI tj6ip4i0oxUNR+w5TQWw3ByYRe2hmlB/pfcX0wKLR9u4v+4cTyTG9TEVuj3CeRJv qBT6Sw4oH5vIFuYGvBvY//LgcvTpVVlx+TL35T7V7zTAEfYcT/KBfSjbU9+FJ2bV o3O2EPUztFVmGQbzH/T7yQFm5OCEnxZos99+0i1v//eYpUdIpQDWV0rcbZMa6U1N tdp0Jaj+SctvdcxEM1N5JrxyvnvatrWxia6bazZfhOH7H0BL1gSRExefvbjd0j42 E+Z1Qr1egjnENqKuXt1r =0Lao -----END PGP SIGNATURE----- --Apple-Mail=_ED6918FF-6A4C-4486-B469-E9BF531AE7E4-- From nobody Thu Dec 4 13:08:07 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4CD1A1AE1; Thu, 4 Dec 2014 13:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNc-AFYijHwg; Thu, 4 Dec 2014 13:07:50 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1EB1A1B69; Thu, 4 Dec 2014 13:07:48 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so29295236wiv.1 for ; Thu, 04 Dec 2014 13:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3HTc58h6zEp+SncTxIxdlk8hSruhjIYTmC42ToOpj2w=; b=dagG44VevD+2dMl+laih9LTu0mlOX8RS3FLTdk28HpKXuzcBnC0nZx/RI+sGr+ltw2 QKvUakYhwfixnJsyyWqbuBP9Dm8i16VlFTvItrBHm8vadFje3z8xCO6kOhxMxTbNqUYj jOewmATI57kTf5xFhPdJYMq2Q0zZltMpLvsAzNfpohoedCIMG7II7mKtjDZQ3sibrS6C qhzVVUo6KrzIvTSdPUytWArsEb6i09F5uMdd+6kQ+FyoYlJuo4schtEN2pfCRIcJK6OM EgCXHIWgBzPB0PJZoCQC04Z4B7pC69DMqYyTNOyDv8nlbRdCyEdCmyczFnH6Lne2rwOu TxBA== X-Received: by 10.180.107.136 with SMTP id hc8mr14338210wib.32.1417727267072; Thu, 04 Dec 2014 13:07:47 -0800 (PST) Received: from [10.0.0.9] (bzq-79-176-33-71.red.bezeqint.net. [79.176.33.71]) by mx.google.com with ESMTPSA id gy8sm18091821wib.23.2014.12.04.13.07.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Dec 2014 13:07:46 -0800 (PST) Message-ID: <5480CD20.6080300@gmail.com> Date: Thu, 04 Dec 2014 23:07:44 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= , IETF Security Directorate , The IESG , draft-ietf-jose-cookbook.all@tools.ietf.org References: <5470E68D.3040204@gmail.com> <547E36ED.1020205@cisco.com> In-Reply-To: <547E36ED.1020205@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/jA-aGnIV747FdtPIelk1S8Urv2o Subject: Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 21:07:55 -0000 Hi Matt, Please see my comments below. I have removed much of the original text, and only left points that need further discussion. Thanks, Yaron On 12/03/2014 12:02 AM, ⌘ Matt Miller wrote: [...] >> >> • Unless I missed it, the document does not mention a machine >> readable repository of these examples, which I am sure the author >> has created while writing the draft. Making such a repository >> publicly available would result in a much more useful resource than >> the current document, which essentially requires testers to scrape >> the document when creating their test cases. >> > > You did not miss it; I don't have a such a repository right now, but I > can put one together. Would something on github.com be acceptable, or > is there a better suggestion? GitHub would be a great place. > >> • (Not a comment to the current document:) I wonder why there is >> nothing explicit to distinguish a public key from a private key, >> and they are only distinguished by the presence or absence of >> several parameters, something that will not be natural to most >> developers. PEM is doing it very well: "-----BEGIN RSA PRIVATE >> KEY-----". >> >> • 3.4: the text is contradictory re: zero-padding of the value "d". >> Is it using the minimum number of octets, or exactly 256 octets >> (for a 2048-bit key)? >> > > The intent is that "d" is not zero-padded, and I overqualified in my > text. Would the following be acceptable? > > For a 2048-bit key, the field "n" is 256 octets in length when > decoded and the field "d" is not longer than 256 octets in > length when decoded. > Yes. > [snip] > >> • 5.1.1: since this is a "cookbook", we should be using the public >> key, not the private key. A private key would only be used in rare >> cases. Similarly 5.2.1. >> > > The private keys are included for both reproduction (which only needs > the public key) and verification (which necessitates the private key). > > If I can put an online repository together, I can change the examples > to just include the public keys; otherwise would the following in 5.1 > (and 5.2) be sufficient? > > Note that only the RSA public key is necessary to perform the > encryption. However, the example includes the RSA private key to > allow readers to validate the example's output. > I'm fine with this new text. > >> • 5.3.1: the "plaintext content" is a list of keys, which is >> either confusing to the reader, or an actual error in the >> document. >> > > It is not in error. The most common usecase for password-based > encryption was the import and export of key sets, and the Working > Group desired a thorough example. > > Would it help if the following is added to 5.3? > > A common use of password-based encryption is the import/export of > keys. Therefore this example uses a JWK Set for the plaintext > content instead of the plaintext from figure 72. > Yes, this would help. > >> • 5.3.5: In the General Serialization version, I don't understand >> why only the encrypted key is per-recipient. I would expect the >> PBES2 parameters too (e.g., the salt) to be per-recipient. >> Presumably each of them is using a different password, and there's >> no reason to use a common salt. Similarly in 5.4.5. >> > > For compatibility across serializations (compact, general JSON, > flattened JSON), all of the parameters need to be in the JWE Protected > Header. In the general serialization, that means only the > "encrypted_key" field is present for the (presumably) sole recipient. > > Would it be acceptable if the following were added to 5.3? > > Note that if password-based encryption is used for multiple > recipients, it is expected that each recipient use different > values for the PBES2 parameters "p2s" and "p2c". > So I still don't understand: don't we need an example that demonstrates how the JSON structure (or multiple structures) is generated so that "each recipient use(s) different values"? In general I don't understand this "compatibility" thing. Obviously there are some cases that cannot be expressed in all serialization types. Otherwise why would we need three of them? >> • 5.7: same as above, it makes sense for the per-recipient key to >> have an ID, rather than the content encryption key (typically an >> ephemeral key). And then that ID should be in the per-recipient >> data in 5.7.5. And similarly for 5.8. The later Sec. 5.13 shows a >> syntax for multiple recipients that's inconsistent with the >> single-recipient case, which would make sense if we got rid of the >> array. >> > > For compatibility across serializations (compact, general JSON, > flattened JSON), all of the parameters need to be in the JWE Protected > Header. Also, the mixing of "recipients" and "encrypted_key"/"header" > in the top-level object is not permitted for the general serialization. > Still confused. Sorry. >> • 5.11: this example seems strange to me - why would anybody NOT >> want to integrity-protect the key ID and algorithm? I would prefer >> a more realistic example, or failing that, a recommendation to >> developers to avoid this practice. Similarly 5.12, which is an even >> worse idea. >> > > Integrity protection was thoroughly discussed in the JOSE WG. While > there are some limited attacks possible when some parameters are > unprotected, the WG felt there were enough use cases where these > attacks are mitigated through other means that integrity protection of > the part of all of the header is not always required. So (personal opinion here) I think the WG took a security risk that should not have been taken in 2014, for a minor performance gain. We have seen too many protocols fail because of integrity-protection shortcuts. Who would have thought you need to integrity-protect the padding field! The fact that CMS took this route back in 1999 is sort of irrelevant, as we've all learned a lot since then. From nobody Fri Dec 5 02:47:49 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F411ACE30; Fri, 5 Dec 2014 02:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVX96HybbyPy; Fri, 5 Dec 2014 02:47:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A2C1A0127; Fri, 5 Dec 2014 02:47:45 -0800 (PST) Received: from [192.168.131.135] ([80.92.119.109]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M0QLp-1XiBkN1VYT-00uZJP; Fri, 05 Dec 2014 11:47:22 +0100 Message-ID: <54818D34.4060604@gmx.net> Date: Fri, 05 Dec 2014 11:47:16 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-opsec-dhcpv6-shield@tools.ietf.org OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="o285e6qjgqlmSCJ1JGN465RmXgPiRggsh" X-Provags-ID: V03:K0:fkkt8/qZkhVnfg8lYcwq3AoYdNSFqAyjHszZLGairEyNZmAynVx oRQpyYG3ONga+6YD4rZPds40ExOR/CR6hwLqfAVjoxYlG4zyav81SHDVF5l8PTa0YDdBdpm t0smcgRRxrduinY3vcQcFykMGzkHqIVCikaPuwl0Zz6An+gNBgA/EyqVp9Ij017+D4a+9h3 6Fq8+HnG2oWIZhq/LQRmA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/gkgM_hmX_zK7-F3RAUSklC2twzg Subject: [secdir] SecDir Review of draft-ietf-opsec-dhcpv6-shield X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 10:47:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o285e6qjgqlmSCJ1JGN465RmXgPiRggsh Content-Type: text/plain; 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 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 specifies packet filtering criterion so that DHCPv6-server messages are discarded by the layer-2 device unless they are received on a specific (previously configured) ports of the layer-2 device. The document is well-written and I don't see any problems with the write-up. While specifying packet filtering firewall rules is an implementation / configuration dependent task that does not require standardization as such this work follows earlier patterns, namely the RA-Guard mechanism for the protection against rogue router advertisements. The only question I have whether the document type (currently set to 'Best Current Practice') is appropriate. Ciao Hannes PS: Minor editorial nit: " Finally, we note that the security of a site employing DHCPv6 Shield could be further improved by deploying [I-D.ietf-savi-dhcp], to mitigate IPv6 address. spoofing attacks. ^^^ " --o285e6qjgqlmSCJ1JGN465RmXgPiRggsh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUgY00AAoJEGhJURNOOiAt2WoH/1l+6pmKOANW2lo6xhXV0QZI zPP2eryafp2vzrVBNrCbYpAYV32oigUCd5q8Vba3/ntYKnqFsMonunS3rqcXr9do tYXjdHvXKo5JuRAmevsiMUtGlUx+JTUt1QrIOcX7rtNN02+ZEmzi6UpaU1LKZ4DX pyFUudL8LIf4PllOyEPGfz0oY0wDNXOZKhNHIxesb1oLYEwDkD6xkumH29ZkZg3f 2vBAdqjMICeMPyPkndXxpIj/RkcT2ramBLNgTLrW27t2x7TqNUMroDfuogB1bCME na3ap36sfzEYvR2SQBO0t6doGzRJjp9TOH+4XHUgfErtVVmfNtUiBLwuWUttVAU= =hLSd -----END PGP SIGNATURE----- --o285e6qjgqlmSCJ1JGN465RmXgPiRggsh-- From nobody Fri Dec 5 04:36:53 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6691ACE3F; Fri, 5 Dec 2014 04:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvQ0qQ8P_9bH; Fri, 5 Dec 2014 04:36:48 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::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 7E4271ACE57; Fri, 5 Dec 2014 04:36:48 -0800 (PST) Received: from 248-241-235-201.fibertel.com.ar ([201.235.241.248] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xws7l-0004Xf-2X; Fri, 05 Dec 2014 13:36:41 +0100 Message-ID: <5481A448.8090805@si6networks.com> Date: Fri, 05 Dec 2014 09:25:44 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Hannes Tschofenig , secdir@ietf.org, iesg@ietf.org, draft-ietf-opsec-dhcpv6-shield@tools.ietf.org References: <54818D34.4060604@gmx.net> In-Reply-To: <54818D34.4060604@gmx.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/y4k1PNErYKY2DBbqUMzxWwCj6Mk Subject: Re: [secdir] SecDir Review of draft-ietf-opsec-dhcpv6-shield X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 12:36:50 -0000 Hi, Hannes, Thanks so much for your feedback! Please find my comments in-line.... On 12/05/2014 07:47 AM, Hannes Tschofenig wrote: > > The document is well-written and I don't see any problems with the > write-up. While specifying packet filtering firewall rules is an > implementation / configuration dependent task that does not > require standardization as such this work follows earlier patterns, > namely the RA-Guard mechanism for the protection against rogue > router advertisements. Other than following earlier patterns, the goal is to avoid implementation flaws (such as those described in RFC7113. > The only question I have whether the document type (currently set > to 'Best Current Practice') is appropriate. The idea is that this document specifies the best current way of implementing the filtering rules for such packets > PS: Minor editorial nit: > > " Finally, we note that the security of a site employing DHCPv6 > Shield could be further improved by deploying [I-D.ietf-savi-dhcp], > to mitigate IPv6 address. spoofing attacks. ^^^ " Will do. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Dec 5 10:22:04 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653781A1B70; Fri, 5 Dec 2014 10:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLN3y9sX5hak; Fri, 5 Dec 2014 10:22:01 -0800 (PST) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037E21A6EE7; Fri, 5 Dec 2014 10:22:01 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id p10so1138614pdj.25 for ; Fri, 05 Dec 2014 10:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=a6WvvI1ZY035qf6aKRYIfSrxODaxRn+iMCjWvm8a950=; b=SATiBzlsMCjH1GiWAgdbGOe9ssZUzhU4/OIAVWFTRo6mZRiaWf70d91IJ2iaOwbK8k QGZRkOqWSUgt8V06rkqZ3K/MiSCKu2GdNZVqU0YzqREKEpyMrz9i41KM5sIgmlMMpIbq 1K4Psy6aqKdXUd6aha3cSKPBAqk3v52t6B4avx/R0m1yBr/fYVBdSLxhBKpAUctOIYSs jK2dT85Hnsw4UMmWPj+vZcHwVIfmVB0mUqPytVk7CzNs+0FgEd7StM9tJBdxawVf91hi Sdc3KVEvX+j5/ChFFrY+AyN1Xq6sj125W1YnHqrORVgyZg2DhXaTF78stqlJYwCH9z1I /5eg== X-Received: by 10.70.46.201 with SMTP id x9mr30766872pdm.154.1417803720296; Fri, 05 Dec 2014 10:22:00 -0800 (PST) Received: from [192.168.1.76] (172-3-137-150.lightspeed.sntcca.sbcglobal.net. [172.3.137.150]) by mx.google.com with ESMTPSA id ps2sm29696386pdb.62.2014.12.05.10.21.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Dec 2014 10:21:59 -0800 (PST) Message-ID: <5481F7C4.3010708@gmail.com> Date: Fri, 05 Dec 2014 10:21:56 -0800 From: Chris Lonvick User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "iesg@ietf.org" , "secdir@ietf.org" , draft-secretaries-good-practices.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/DXu70lVgvP0-xQw8M1V7cqLx2Lg Subject: [secdir] SECDIR re-review of draft-secretaries-good-practices X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 18:22:02 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written 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. In my last review, the only security-related issue I raised was a nit about the WG Chairs knowing how to revoke privileges given to a secretary. The security considerations section has been revised to address this. I scanned through the other changes that had been made to this revision and found no other concerns. Finally, just a note to the IESG members that this document has been discussed on the "IETF Discuss" list over the past few weeks resulting from the Last Call announcement. Best regards, Chris From nobody Sat Dec 6 08:35:18 2014 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 B8F0C1AD3C9; Thu, 4 Dec 2014 06:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1417703794; bh=bV2I8SWsUu235XA5QpyeBqaYiCUrCfSrAUxNgSjpNmA=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=OFG66mRISI6LsmHhW+5KT4CRsatalairkItYhJqkE4i8WUlGJ84uxgGddFLiGXd/Z m7ENrOHIKsJQ1ppzJugVDeFExcBTM8acdm/DEgzxF790J/dlsC833EURNMhsqjjIk3 Amyfwjk7qm6QTNc6KjjWSQY+o2sUeG+8UPg9R/zg= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809AC1AD3D0 for ; Thu, 4 Dec 2014 06:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K5B8l-pz2GW for ; Thu, 4 Dec 2014 06:36:30 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C831A1B2B for ; Thu, 4 Dec 2014 06:36:29 -0800 (PST) Received: from eb.bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XwXW8-00041I-Af; Thu, 04 Dec 2014 09:36:28 -0500 To: new-work@ietf.org Date: Thu, 04 Dec 2014 15:36:17 +0100 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/5x2GXwcR_UjPObbyEBVyP_4sD9g X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/UeTwAgw3QIRyF0R4ay5Y16tnb_g X-Mailman-Approved-At: Sat, 06 Dec 2014 08:35:17 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Automotive Working Group (until 2015-01-06) 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, 04 Dec 2014 14:36:35 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Automotive Working Group: http://www.w3.org/2014/automotive/charter 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 2015-01-06 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 [2], 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 Ted Guild , or Kazuyuki Ashimura , Staff Contacts. Thank you, Coralie Mercier, W3C Communications [1] http://www.w3.org/2014/Process-20140801/#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sat Dec 6 08:35:21 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB9E1AD56E for ; Fri, 5 Dec 2014 10:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPKuqEpbFL7J for ; Fri, 5 Dec 2014 10:54:22 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027B51AD56D for ; Fri, 5 Dec 2014 10:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417805655; x=2281719255; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6z8M42FqTDYnHObh4VHeO02KVV/zqzq9zHXev3SmcN4=; b=f+Cgqv0SzVMamF0EDyFvY9zYAq94TmGdbIKUSkn9pfj5KRzNF69RPLc48mQNLfdc RY2U8wJFqi7xwQ6Z6VivSWq8zY3nyrOraJaMJm7+c0dNjfHoGsZDqYcyIIqyWdSj I9+hnbvY6jdbqofZbjDmN0Ej6PcmSckvl8MHvtV+XPyANS96GcPQK6wIrixwM/vt wMXBg0gzqPC6sJsrM5wbndLOTO26stjhnCXL1UGvWWLaddWNVDNRD2ERmLniLJu6 ZHpwtWVCESNiGzGKrqcYELMqX2EE3WIyi9yHuxIvIKocmD37AUpRn7ElIjvKB07U aqN8vEYuOyV5TY6W3JrSWw==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 0E.64.26546.75FF1845; Fri, 5 Dec 2014 10:54:15 -0800 (PST) X-AuditID: 11973e11-f79af6d0000067b2-bc-5481ff57cb37 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 1B.D6.05439.D5FF1845; Fri, 5 Dec 2014 10:54:21 -0800 (PST) Received: from [17.153.39.20] by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG400JS8HUAOK30@marigold.apple.com> for secdir@ietf.org; Fri, 05 Dec 2014 10:54:14 -0800 (PST) MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-type: multipart/signed; boundary="Apple-Mail=_2523CC1A-AB21-4C97-9F65-C0F15F489BB5"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <9C3E7BDB-82F5-4A75-82E6-F8E1075A84CD@tislabs.com> Date: Fri, 05 Dec 2014 13:54:10 -0500 Message-id: <1679DF62-2474-4A79-BA34-3DA722CFA398@apple.com> References: <9C3E7BDB-82F5-4A75-82E6-F8E1075A84CD@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUi2FAYrBv+vzHEYN4qZYsPCx+yODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/jCp8wF1/0r1r7/zdrA+Neji5GTQ0LAROJS22JWCFtM4sK9 9WxdjFwcQgJ7GSVWbDrD3MXIAVa0sj0cIj6JSeLj6SfMEM4PRokvjw8wgnQLC9hINPw5wwRi 8wroSTQ9ecwEUsQsMIVRYunL1+wgCTYBNYnfk/pYQaZyCthLbJlqCxJmEVCVaOp/B9bLLBAh 8XnXN6g5NhJ3+haAlQsJ2EnM2qQPEhYBKj9xag3U0bIS/y6eYQdZJSGwhk3iRtNV9gmMQrOQ nDEL2RmzwHZoSyxb+Jp5FtBcZgEdickLGSHCphJP3m5ng7CtJX7OeQQVV5SY0v2QfQEj+ypG odzEzBzdzDwjvcSCgpxUveT83E2MoHiYbie4g/H4KqtDjAIcjEo8vCskGkOEWBPLiitzDzFK c7AoifO+4wUKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGyzE554RLerK+Tdj9Mny3qUvQs7 BT55OuY+5rqbIbPxuEDA1O5Vb6+4XLz6+fCyJoZdPU3bl//1+ywQsSdNzkT+AvcHd8NvdkHb BQJXilhz3ytL/nf1xbs5JxundMwUMl56ZOIH+6gsM3cB32rTGS3Lc4wm7frD9G3hXqVTQbPe uOiXnvZ5cU2JpTgj0VCLuag4EQAngCxMaAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUi2FDcohv7vzHEYNEbEYsPCx+yODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/jCp8wF1/0r1r7/zdrA+Neji5GDQ0LARGJle3gXIyeQKSZx 4d56ti5GLg4hgUlMEh9PP2GGcH4wSnx5fIARpEpYwEai4c8ZJhCbV0BPounJYyaQImaBKYwS S1++ZgdJsAmoSfye1McKsoFTwF5iy1RbkDCLgKpEU/87sF5mgQiJz7u+Qc2xkbjTtwCsXEjA TmLWJn2QsAhQ+YlTa1ghjpOV+HfxDPsERv5ZSDbPQrZ5FthYbYllC18zzwIaxSygIzF5ISNE 2FTiydvtbBC2tcTPOY+g4ooSU7ofsi9gZF/FKFCUmpNYaayXWFCQk6qXnJ+7iREcvoXBOxj/ LLM6xCjAwajEw7tCojFEiDWxrLgy9xCjCtCIRxtWX2CUYsnLz0tVEuFNng2U5k1JrKxKLcqP LyrNSS0+xCjNwaIkzlvxDiglkJ5YkpqdmlqQWgSTZeLglGpgXHD3qOHhe0cOl/Hxe/zft3Bl 8jQBG8HvN+xviHyyaN/gbrnoUYFVz/Nfk6fu/v3IzWPXWXsGQUtp5xsNkYv8Z8Yova7NKvtk GtERwazA4JH56XaxFev7Y3xndCMC2PYqPP5tZNy9Jr/hb9qCKt4OIcU2v8q88/9Yl23ceLrt 7wPdpCmOjQV7lViKMxINtZiLihMBO6GuTmcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xBbE9pudek1a3cTFPV1-jJKNn7M X-Mailman-Approved-At: Sat, 06 Dec 2014 08:35:17 -0800 Cc: draft-mcdonald-ipps-uri-scheme@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] secdir review on draft-mcdonald-ipps-uri-scheme X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 18:54:26 -0000 --Apple-Mail=_2523CC1A-AB21-4C97-9F65-C0F15F489BB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sandra, Thanks for your comments! A few responses inline below... > On Dec 4, 2014, at 12:16 PM, Sandra Murphy wrote: > ... > RFC2911 section 4.1.6 lists some "Standard values for this syntax > type" for the uriScheme attibute - is it intended that this document > add ipps: to that list? That would seem logical but is not explictly > stated. Yes, per the whole IANA registration thing... :) > section 4.2 >=20 > The abstract protocol defined in IPP/1.1 Model and Semantics > [RFC2911] places a limit of 1023 octets (NOT characters) on the > length of a URI. =20 > ... =20 > Per PWG IPP Everywhere [PWG5100.14], for compatibility with existing > IPP implementations, IPP Printers SHOULD NOT generate (or allow > administrators to configure) URI lengths above 255 octets, because > many older IPP Client implementations do not properly support these > lengths. =20 >=20 > Is this a concern for ipps in particular, or would it apply to ipp as > well? (Is this one of the updates to RFC2911/RFC2910?) It is, and is documented in RFC 3510 (which formally defines and = registers the "ipp" URI scheme...) > section 6.2.4 >=20 > Either service discovery or directory protocols SHOULD be used first=20= > or an IPP Client SHOULD first establish an 'ipp' connection (without=20= > TLS [RFC5246] or any client authentication) to the target IPP = Printer > and use a Get-Printer-Attributes operation to discover the required > IPP Client authentication mechanism(s) associated with a given = 'ipps' > URI. >=20 > I am not sure what the client would do with the information of the > Client Authentication types before it attempted the ipps connection, > but retrieving that information with no protection seems dangerous. > At least, should the unprotected request be limited to mention the > ipps URI as the target and request only the > uri-authentication-supported attribute? To at least limit the > possibility that the response will include all attributes and the > client will accept them before attempting the ipps connection? Actually, I think this needs to be updated. We should instead focus on = using the Get-Printer-Attributes request to query the authentication = requirements - this might cause a reconnect (in the case of a TLS client = certificate being needed for authentication) but we don't want to say = "downgrade to ipp" to do it. > The following is a discussion of the potential for a tiered network of = Printer Objects. >=20 >=20 > This document talks about "a downstream IPP printer" and "print > gateway" and defines an IPP Printer as something that can receive > operations from an "upstream" client or printer. >=20 > I was curious as to whether the protocol is intended to be used in a > hierarchy. The model we use allows for "fan-out" of print jobs, but how that = fan-out is implemented is not part of IPP (although it naturally can be = implemented that way...) There is some work in the PWG for defining how to securely do fan-out... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_2523CC1A-AB21-4C97-9F65-C0F15F489BB5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO0jCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUiMIIECqADAgECAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkq hkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzEyMTcw MDAwMDBaFw0xNDEyMTcyMzU5NTlaMCExHzAdBgkqhkiG9w0BCQEWEG1zd2VldEBhcHBsZS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDXb0GGUQlc3NMCGLyDp/9D7+81MLiL2wHz P1txcnpqmcd33SsV+FsTdseTQt4YQRxq1FoqyR+65eiLddmxkOtbhwCuY7CYpFeZPpjmI2WijSCs Y9LmCJNzCkJrJjPLd53XauZqdpscFf1OwBT089X4IXZKk2/zZB2OXgPCqpLGnqsHzIKGohlXglIa bVp16LHGvDwJG/ovbuaxKJOc4GPkD9CLliyRDXwOKnRDLB/jgMDBjr/XzQoHHWqRZ43kmGo+9Juq lIquOOvvGtq4VLBFCkGsjjII55tm4FLjce6Tr7PyYMyJWaE8/5ZZhNR1kRBs0o0Zy1sEPfH7KX3m VgPvAgMBAAGjggHgMIIB3DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4E FgQU7SgSaBvZMWYrE6iYOPsK9dpeLLYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYD VR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAE PzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8u bmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHow UgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9k b2NhLmNvbTAbBgNVHREEFDASgRBtc3dlZXRAYXBwbGUuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAY OSi0CubvYBiO+bvr2B/4urjAypaUyCzv6/xaTdom6qcAAdpZ/aCrzyANf696PgwQvO06p5SQIj1u AAxR6UZqpaa29E7vaffJz/8JebQWYxD/HWOIh9Ewdwdq/SR8EcMCUNtAqiabgp/XZry9tebGUqry X5blZSHAEAi8ad2SjCAtqTSorbMHY4x3bmiro9kzHsa8zLa0RkbRRfaXDHJ7KhNkLSVKlz1e/zOF k9skVJiOE4T7fTvX5jx9pLudoXW+reKl78HUEpAx7caNyf1XP4w0dv33nnQ4UJhtFfY+rR7Lhum1 VYXBolp0pkqD34NdxZUMJcWU8hbYjGdoyC8qMYIDrjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMAkGBSsOAwIaBQCgggHZMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MTIwNTE4NTQxMFowIwYJ KoZIhvcNAQkEMRYEFM0QFlN6nLRRaLI/m69qnQrYOi4GMIG6BgkrBgEEAYI3EAQxgawwgakwgZMx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDlB7dXxclLEedquPvGX8CGMIG8Bgsq hkiG9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNV BAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUH t1fFyUsR52q4+8ZfwIYwDQYJKoZIhvcNAQEBBQAEggEAHBR5ZfQfFkY7SGUhQDDtYs+Lvim9Sgsb XCHuwYKl2zGFDXuOhWLywQllzu8bslnAo5qsU67YGd/UPSSW1XFAUlJaAWbe0qpRe2bRKblAskfJ kKqXXnszEC70Om1rEk+ZSapA2+8lt+sBrWgHMBDSPahPKl0q3IHagyl4ceLyfCx7eZDsM+YAwT+v 81XV6N4BdUPbTDkGxZvm8QNp5FJ/ECesNsMWeN6tBEBqoEAaS7UXbEnda5HDB9o7UwYlMs08iH75 4FgpQqJlnDNjYO6tCrm+bUN0hBonTYzcv5iD6c5KDJNx/Bs03gP7GpCp2SMfSGdL3+nF0GMw6z0S 2FUCoQAAAAAAAA== --Apple-Mail=_2523CC1A-AB21-4C97-9F65-C0F15F489BB5-- From nobody Mon Dec 8 10:34:24 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10681AC3DC; Mon, 8 Dec 2014 10:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.999 X-Spam-Level: X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FROM_12LTRDOM=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XEY2wDHwSnz; Mon, 8 Dec 2014 10:34:20 -0800 (PST) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9336A1A87D9; Mon, 8 Dec 2014 10:34:20 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1Xy38V-0004Bj-07; Mon, 08 Dec 2014 11:34:19 -0700 Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1Xy38U-00050K-5Z; Mon, 08 Dec 2014 11:34:18 -0700 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id sB8IXeEk004510; Mon, 8 Dec 2014 11:33:40 -0700 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id sB8IXd8Q004508; Mon, 8 Dec 2014 11:33:39 -0700 Date: Mon, 8 Dec 2014 11:33:39 -0700 Message-Id: <201412081833.sB8IXd8Q004508@sylvester.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org, draft-richardson-6tisch--security-6top.all@tools.ietf.org X-XM-AID: U2FsdGVkX19Bod5suqhkvG5hMIQPFYUq X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ******;iesg@ietf.org, secdir@ietf.org, draft-richardson-6tisch--security-6top.all@tools.ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 478 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 2.9 (0.6%), b_tie_ro: 2.1 (0.4%), parse: 0.93 (0.2%), extract_message_metadata: 9 (1.9%), get_uri_detail_list: 3.6 (0.7%), tests_pri_-1000: 3.9 (0.8%), tests_pri_-950: 1.69 (0.4%), tests_pri_-900: 1.36 (0.3%), tests_pri_-400: 28 (5.8%), check_bayes: 26 (5.4%), b_tokenize: 8 (1.7%), b_tok_get_all: 9 (1.9%), b_comp_prob: 3.1 (0.7%), b_tok_touch_all: 2.2 (0.5%), b_finish: 0.82 (0.2%), tests_pri_0: 420 (87.9%), tests_pri_500: 6 (1.2%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qxT9Cx6mue0UhlPd4dUJU3A8IX8 Subject: [secdir] Comments on draft-richardson-6tisch--security-6top-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 18:34:21 -0000 Informal security comments on draft-richardson-6tisch--security-6top-04.txt I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. This is an early review, so these comments are mostly useful for the draft authors. Tero Kivinen has already sent his comments, and he clearly knows more about the details of 6tisch than I do, but I'll weigh in with my own impressions anyway. The draft is daunting for a neophyte in this 801.15.4e world, and I have to admit that I almost gave up when I reached this text: The joining node will not participate in the route-over RPL mesh, but rather will be seen by the network as being a 6lowpan only leaf-node. I was fortunate to find an IPSO Alliance document that is a fairly good introduction to the technology and the acronyms. The problem is to use an existing protocol to provide a way for a pre-provisioned node to securely join a wireless network. Because the node initially has no IP address, the authentication must take place without requiring the node to use layer 3 protocols. The solution uses a special "Join Network" with a well-known key and an untrusted intermediate node (Join Assistant). The Join Assistant helps the joining node by acting as a cache for certificates and a proxy for requests to join the routing mesh. The joining node's join request is forwarded to a border router and thence to an authoritative entity, the Join Coordination Entity (JCE). The JCE initiates a conversation with the joining node using DTLS; the traffic is relayed through the Join Assistant. A minor issue with the protocol is the encryption with a well-known key. This serves no security purpose, but it allows traffic filtering to keep the traffic on the special Join Network separate from the regular network. That confuses me --- surely some packet marker would be better for filtering than encryption would? Another confusing point is step 1B "send router solicitation". I'm not sure what destination address is in this. Perhaps the beacon provides the information for use by the joining node. Overall, the problem with the draft's suggested framework for mutual authentication between the joining node and the JCE is that there is a great deal of setup using an trusted node. The joining node has no reason to the trust the Join Assistant or anything it receives from it. Thus, it can be easily fooled into trying to join the wrong network, and the long conversation that this entails before ultimately failing may be quite a burden. Kivinen notes that replay attacks are possible, and these will always be a problem with unauthenticated exchanges. It seems better to avoid them rather than to leave someone the problem of proving later than none of them succeed. It seems clear that the initial communication must have mutual authentication. I'd expect the joining node to start with a signed join request, and nothing would proceed further until the JCE found the device ID in its access list and decided to proceed with further authentication. The joining node should not communicate further until it has some reason to believe it is on the correct network. Even with that change, there is always the possibility of a malicious relay node-in-the-middle. It could cause the joining node to communicate with a very distant instance of the correct network, for example. This might violate some proximity assumptions. The malicious node could arbitrarily block communication and cause unintended behavior of the network. From nobody Mon Dec 8 11:34:04 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1761ACDF5; Mon, 8 Dec 2014 11:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBg8pkeudEbY; Mon, 8 Dec 2014 11:33:52 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670901ACDF1; Mon, 8 Dec 2014 11:33:29 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BA602200A7; Mon, 8 Dec 2014 14:37:06 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 6973F637F5; Mon, 8 Dec 2014 14:33:28 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4F0CB63745; Mon, 8 Dec 2014 14:33:28 -0500 (EST) From: Michael Richardson To: "Hilarie Orman" In-Reply-To: <201412081833.sB8IXd8Q004508@sylvester.rhmr.com> References: <201412081833.sB8IXd8Q004508@sylvester.rhmr.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/3zcACNWnMvtWCBZx2bpk9lm2-KA Cc: 6tisch-security@ietf.org, secdir@ietf.org Subject: Re: [secdir] Comments on draft-richardson-6tisch--security-6top-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 19:34:00 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= re: https://mailarchive.ietf.org/arch/msg/secdir/qxT9Cx6mue0UhlPd4dUJU3A8IX8 Hilarie Orman wrote: > A minor issue with the protocol is the encryption with a well-known > key. This serves no security purpose, but it allows traffic filtering > to keep the traffic on the special Join Network separate from the > regular network. That confuses me --- surely some packet marker would > be better for filtering than encryption would? sadly, 802.15.4 lacks both the SNAP header, and even such a thing as an ethertype. But, we have decided to dispense with this in a new revision. > Another confusing point is step 1B "send router solicitation". I'm > not sure what destination address is in this. Perhaps the beacon > provides the information for use by the joining node. IPv6 router solicitations are multicast, so it does not need to know a place to send it. > It seems clear that the initial communication must have mutual > authentication. I'd expect the joining node to start with a signed > join request, and nothing would proceed further until the JCE found > the device ID in its access list and decided to proceed with > further authentication. The joining node should not communicate > further until it has some reason to believe it is on the correct > network. The intent is that the device ID travels up the network to the JCE, just as you said, and that the device stays silent until the JCE see it. You are suggesting that the new device sign it's ID. Can you explain the value of that? (The exact way in which the device ID travels up has changed several times. We believed that we could use an extended ARO in the IPv6 Neighbour discovery which is part of 6lowpan, but we are having some doubts) > Even with that change, there is always the possibility of a malicious > relay node-in-the-middle. It could cause the joining node to > communicate with a very distant instance of the correct network, for > example. This might violate some proximity assumptions. The > malicious node could arbitrarily block communication and cause > unintended behavior of the network. Yes, so in draft-ietf-roll-security-threats (in AUTH48) this is called a wormhole attack. It's unclear how this situation is different than (intentionally) having a really good antenna, but I agree it is a concern. --=-=-= Content-Disposition: inline Content-Description: Signature -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVIX9BYCLcPvd0N1lAQLkwgf/b9YntU0yFusD8evyGGpkd/7OOfy2NYsG bUB1jKb1yUdbAJmbIfuyX5wWjMGE0TJobqAy2aYQgOOhJdIodYNqb5X2nlcDTnM6 erny6t8b/uDC3iRfZpPYumGQ6X/NJi45Epb+dv1wkYUQa87y2ie5KGOXSbNMwtWr fziQbekaJj77R0aRIlnx+gzuYqPG4arCgglln201xScXJ/5CST4cmJ1LvIxCLNUU iiM+nEaWgOAUgJSxCRmt2WZpxUGW7z1zMxvPrdV++eash8DGDJXAvOzoHz/kGXtD z+oz3kLSsejB6vG0r/8mnYanE7uA3MJkWkDUXsUbVQL8xN97QXy02Q== =H79t -----END PGP SIGNATURE----- --==-=-=-- From nobody Mon Dec 8 16:56:29 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCB41A1AE1; Mon, 8 Dec 2014 16:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBrMXjTe2Mzn; Mon, 8 Dec 2014 16:56:15 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4531A1AC8; Mon, 8 Dec 2014 16:56:15 -0800 (PST) Received: from Philemon (unknown [4.30.143.162]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 4BAB438F21; Mon, 8 Dec 2014 16:56:14 -0800 (PST) From: "Jim Schaad" To: "'Yaron Sheffer'" , "'? Matt Miller'" , "'IETF Security Directorate'" , "'The IESG'" , References: <5470E68D.3040204@gmail.com> <547E36ED.1020205@cisco.com> <5480CD20.6080300@gmail.com> In-Reply-To: <5480CD20.6080300@gmail.com> Date: Mon, 8 Dec 2014 16:55:46 -0800 Message-ID: <008e01d0134a$de516bd0$9af44370$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCfLK/cFUOZt7KXRlpowFM5JqM6CgBG564yAiKD1zie1ObF0A== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LW7D52hI4KCviST3ngMzVjdNywk Subject: Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 00:56:19 -0000 > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Thursday, December 04, 2014 1:08 PM > To: ? Matt Miller; IETF Security Directorate; The IESG; = draft-ietf-jose- > cookbook.all@tools.ietf.org > Subject: Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06 >=20 > Hi Matt, >=20 > Please see my comments below. I have removed much of the original = text, > and only left points that need further discussion. >=20 > Thanks, > Yaron >=20 > On 12/03/2014 12:02 AM, ? Matt Miller wrote: > [...] >=20 > > > >> 5.3.5: In the General Serialization version, I don't understand > >> why only the encrypted key is per-recipient. I would expect the > >> PBES2 parameters too (e.g., the salt) to be per-recipient. > >> Presumably each of them is using a different password, and there's > >> no reason to use a common salt. Similarly in 5.4.5. > >> > > > > For compatibility across serializations (compact, general JSON, > > flattened JSON), all of the parameters need to be in the JWE = Protected > > Header. In the general serialization, that means only the > > "encrypted_key" field is present for the (presumably) sole = recipient. > > > > Would it be acceptable if the following were added to 5.3? > > > > Note that if password-based encryption is used for multiple > > recipients, it is expected that each recipient use different > > values for the PBES2 parameters "p2s" and "p2c". > > >=20 > So I still don't understand: don't we need an example that = demonstrates > how the JSON structure (or multiple structures) is generated so that > "each recipient use(s) different values"? It is not clear to me what you are asking for at this point. Section = 5.13 has a demonstration of how to deal with multiple recipients for a = set of key management algorithms, but for every different type of key = management that is possible. It is not clear to me that a password = based encryption is a good place to show multiple recipients. =20 The JWE specification allows for three different locations for = parameters to be placed. Any parameter can go in any of these different = locations and they are all treated differently. There are rules that a = parameter of any given name cannot occur in two different locations, = this means that if one did have multiple recipient situations, that = parameters which have the same name but are different would be forced = into the unprotected bag of the per recipient location. This would be = true for any of the different parameters - the most common would the = 'alg' parameter which is generally different for each recipient. >=20 > In general I don't understand this "compatibility" thing. Obviously > there are some cases that cannot be expressed in all serialization > types. Otherwise why would we need three of them? I will assume that you have read (or at least scanned) section 7 of the = JWE document. However a summary of it is: * Compact serialization does not support either the global or per = recipient unprotected parameter bag * Compact serialization does not support application AAD information. * Compact serialization and Flattened JSON serialization only support = one recipient Since the document is attempting to show all three serializations where = possible, this does impose a restriction on where parameters can be = placed. >=20 > >> 5.7: same as above, it makes sense for the per-recipient key to > >> have an ID, rather than the content encryption key (typically an > >> ephemeral key). And then that ID should be in the per-recipient > >> data in 5.7.5. And similarly for 5.8. The later Sec. 5.13 shows a > >> syntax for multiple recipients that's inconsistent with the > >> single-recipient case, which would make sense if we got rid of the > >> array. > >> > > > > For compatibility across serializations (compact, general JSON, > > flattened JSON), all of the parameters need to be in the JWE = Protected > > Header. Also, the mixing of "recipients" and = "encrypted_key"/"header" > > in the top-level object is not permitted for the general = serialization. > > >=20 > Still confused. Sorry. This has the same basic response. The protected parameter bag is not associated with the content = encryption key. It applies equally to the content encryption key and = the recipient key. A parameter such as kid is defined as only applying = to a CEK in the direct encryption case (which can be argued is the = recipient key). In all other cases the kid parameter always applies to = the recipient key and not to the CEK. You cannot make an association of = keys and location of attributes. >=20 > >> 5.11: this example seems strange to me - why would anybody NOT > >> want to integrity-protect the key ID and algorithm? I would prefer > >> a more realistic example, or failing that, a recommendation to > >> developers to avoid this practice. Similarly 5.12, which is an even > >> worse idea. > >> > > > > Integrity protection was thoroughly discussed in the JOSE WG. While > > there are some limited attacks possible when some parameters are > > unprotected, the WG felt there were enough use cases where these > > attacks are mitigated through other means that integrity protection = of > > the part of all of the header is not always required. >=20 > So (personal opinion here) I think the WG took a security risk that > should not have been taken in 2014, for a minor performance gain. We > have seen too many protocols fail because of integrity-protection > shortcuts. Who would have thought you need to integrity-protect the > padding field! The fact that CMS took this route back in 1999 is sort = of > irrelevant, as we've all learned a lot since then. Allowing for integrity protection of kid and algorithm would have ended = up with a very different looking structure than what we had. This was = the approach that was going to be used by the authors of the draft and = was universally and roundly rejected by the WG. If that is really what = you want to do, then one might as well create n messages each for one = recipient and protected the parameters in that way rather than create a = multi-recipient message. The final effect is going to be the same as = either one needs to have a very complex structure of the protected = structure where every recipient is included there (and thus force a full = re-encryption by anybody changing the set of recipients) or each = recipient has to be done independently in order to create a MAC value = just for that recipient. Neither of these approaches is very = appetizing.=20 How would you go about doing such a design to make it so that only a = single encryption process is needed, and so that one can add new = recipients without having to do a full decrypt and re-encrypt if one = wants to either add or strip recipients from a message? If full integrity protection is needed, one can always do a single = message per recipient. However, changing something like the kid is not = currently very useful. The fact that one finds the wrong key is much = less of an attack (other than a DOS attack) with authenticated = encryption that it was before with normal symmetric encryption. Failing = to successfully decrypt a message is not a huge attack vector that the = WG cared about given that it can be accomplished by just changing one = byte in the cipher text as well. Jim From nobody Mon Dec 8 19:18:44 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B810A1A07BE; Mon, 8 Dec 2014 19:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTJHIyVC3cm5; Mon, 8 Dec 2014 19:18:40 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9C51A0052; Mon, 8 Dec 2014 19:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3513; q=dns/txt; s=iport; t=1418095121; x=1419304721; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=i/2ZWO8TBuY2dxgsigqaAFIy6FULfhJxwLL4j0v/ZJk=; b=Ddhx19abiYsfO4ulJjK0SUwpDqhAT7wxWzxemQKCjGrmoo24r5AcfzHg p5FP/tApxiUuMhRsYXVd82V5Z2Lxq89F3DTtzryBl8kWklPXEMfyVzwlI tl2Tpw9tbVebO/eeUe9chSTfo+H3X25J/PzdT81DyCUi5/CxLCbdP47vX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAHlphlStJA2L/2dsb2JhbABZgwaBLswXgS8WAQEBAQF9hAl5EgGBACcEAQ2IPdZZAQEBAQEBAQEBAQEBAQEBAQEbkDyDKIEVBY4NhRk+gz6RaoIGFoFSgjR+AQEB X-IronPort-AV: E=Sophos;i="5.07,542,1413244800"; d="scan'208";a="103833958" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP; 09 Dec 2014 03:18:40 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sB93IdcW009606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 03:18:39 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.222]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 21:18:38 -0600 From: "Brian Weis (bew)" To: "secdir@ietf.org" , The IESG Thread-Topic: Secdir review of draft-ietf-l3vpn-end-system-04 Thread-Index: AQHQE17Th68HkvC4CUyzb2E6TowKjg== Date: Tue, 9 Dec 2014 03:18:38 +0000 Message-ID: <6BAB7B9A-1A70-4957-ADC2-1836F22A4219@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.161.48] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/EBaz-JicYlyFOxgXJ6QO7Ow2XKU Cc: "draft-ietf-l3vpn-end-system.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-ietf-l3vpn-end-system-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 03:18:41 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. This subject of this document is "BGP-signaled end-system IP/VPNs=94, which= defines a system where an L3VPN system is supported on =93end systems", w= hich means servers sitting in a data center. It describes how the L2VPN con= trol plane and forwarding plane can be implemented in a network virtualizat= ion environment. Three actors are described, which together implement the L= 3VPN PE role.=20 The security goal of the L3VPN is to maintain isolation between sets of use= rs (e.g., customers of a provider). A new XMPP-based signaling protocol is = described in order for two of the actors (=93End System=94 and =93End Syste= m Route Server=94) to pass IP reachability information for each set of user= s. The Security Considerations section is fairly light. It should be a bit mor= e verbose in describing the new threats that this system have over and abov= e a traditional L3VPN. The following comments try to tease out what those t= hreats might be. 1. The first paragraph of Security Considerations says =93It is important t= o secure the end-system access to End-System Route Servers and the BGP infr= astructure itself.=94 I=92m not sure if this is intended to mean that the e= nd-system (and it=92s virtual machines) aren=92t trusted and should be isol= ated from the RSs and BGP infrastructure, or if this a preamble to the next= paragraph stating that the XMPP session needs to be secured.=20 But in either case since the L3VPN PE functionality is now no longer physic= ally isolated form the customer images, it is important to describe what ne= w threats this approach adds to the PE role. Maybe the last paragraph in t= he section is trying to make the point that there are new threats, but if s= o should say more about the need for separation of virtual and infrastructu= re traffic. E.g., this mitigates traffic from a virtual machine attacking = the infrastructure traffic or creating a denial of service by clogging up t= he infrastructure with frames. 2. The second paragraph of Security Considerations mentions that the XMPP s= ession needs to be secured. It describes the use of certificates, but this = isn=92t enough. Certificates need to be used with a protocol that uses cert= ificates for peer authentication. I think it=92s common to protect XMPP wit= h TLS, for example so you might want to look into that. Once a peer is auth= enticated with its certificate, then the router server can perform authoriz= ation. It is important to give at least one complete example of a method to= secure the session. 3. The third paragraph of Security Considerations mentions a couple of conv= entional methods for securing BGP. Is this more than what is typically reco= mmended within an L3VPN BGP (as opposed to a BGP speaker connected to anoth= er provider)? If so, it would be good to say what are the additional threat= s that require more security. 4. Section 6 mentions external Forwarders, and says that in this case "VPN = routing information received from the Route Server(s) SHOULD NOT be propaga= ted to the end-system.=94 Is there a security consideration here? Brian =20 From nobody Tue Dec 9 04:58:43 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDBE1A0451; Tue, 9 Dec 2014 04:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cvg7jaG8O6o; Tue, 9 Dec 2014 04:58:39 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12581A0382; Tue, 9 Dec 2014 04:58:38 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB9CwXtJ020027; Tue, 9 Dec 2014 12:58:34 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB9CwWOc019954 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 12:58:33 GMT From: "Adrian Farrel" To: "'Brian Weis \(bew\)'" , , "'The IESG'" References: <6BAB7B9A-1A70-4957-ADC2-1836F22A4219@cisco.com> In-Reply-To: <6BAB7B9A-1A70-4957-ADC2-1836F22A4219@cisco.com> Date: Tue, 9 Dec 2014 12:58:28 -0000 Message-ID: <03b501d013af$d3d831b0$7b889510$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIJn+TKigYJrUPuhhBd0T9Q0sVJqZwUH0WQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21160.007 X-TM-AS-Result: No--16.562-10.0-31-10 X-imss-scan-details: No--16.562-10.0-31-10 X-TMASE-MatchedRID: rYpa/RC+czGnykMun0J1wlaOpp/sV5nVOhJ9m53n4aB94HxmQFPHy80y BterFDqMTWLw2jvbfpxcQYBu5oPw5eyt+a9Mtf+eY1bQMCMvmn5u/Xr6CKXiN+lbXcFLWE8Nnyh q6lBOGcPxffyXmzOSajaRX1a76aO+fmfYZ4AgHuf87vS8PQu3wEDwj88nLgRT+fSAR8SgE2/2Ff tIOGQdVRamW28UkvWj1DnYAC+kmPQLazoQyrpm0mgws6g0ewz2IWrhso05H/UoDMZ3xV44iAdqb 5fC0EclT5dYubiiJHlbi0xMSjgYy/c+5H0kOor6bO8iLwtqcBpimi8LvNfmr23D6f6IpbLIjIPC JAAhgXOJbzYit3edRXUnFuXHTdk7EZG6oCaQzfaIED/RsFAua1AI6wCVrE3vyPQR7DhM3jbSnGT DBuqUfUjH681EJoCobxvtht9+1IqmR/fjfo0BcBMxKDqgAFSzq8zHTxACKxZfIVH4zHfuZxr7Fy aVZKQrHijGu6j9ufeDGa0p6svLIwx5TL3qCTgEngIgpj8eDcC063Wh9WVqgqbyPFGTn+O41GcRA JRT6POOhzOa6g8KrXDnVpFD1AD09WJqbyZEN6TGgkAWKBZcDRE7qfqKIrKQ/oFj1EY1BAs= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/I6OwU--SZmehLWVgIXq877egIpY Cc: draft-ietf-l3vpn-end-system.all@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-l3vpn-end-system-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 12:58:41 -0000 Thanks Brian, Authors: please develop updates or a response. Thanks, Adrian > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Brian Weis (bew) > Sent: 09 December 2014 03:19 > To: secdir@ietf.org; The IESG > Cc: draft-ietf-l3vpn-end-system.all@tools.ietf.org > Subject: Secdir review of draft-ietf-l3vpn-end-system-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 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 subject of this document is "BGP-signaled end-system IP/VPNs", which > defines a system where an L3VPN system is supported on "end systems", which > means servers sitting in a data center. It describes how the L2VPN control plane > and forwarding plane can be implemented in a network virtualization > environment. Three actors are described, which together implement the L3VPN > PE role. > > The security goal of the L3VPN is to maintain isolation between sets of users > (e.g., customers of a provider). A new XMPP-based signaling protocol is > described in order for two of the actors ("End System" and "End System Route > Server") to pass IP reachability information for each set of users. > > The Security Considerations section is fairly light. It should be a bit more verbose > in describing the new threats that this system have over and above a traditional > L3VPN. The following comments try to tease out what those threats might be. > > 1. The first paragraph of Security Considerations says "It is important to secure > the end-system access to End-System Route Servers and the BGP infrastructure > itself." I'm not sure if this is intended to mean that the end-system (and it's > virtual machines) aren't trusted and should be isolated from the RSs and BGP > infrastructure, or if this a preamble to the next paragraph stating that the XMPP > session needs to be secured. > > But in either case since the L3VPN PE functionality is now no longer physically > isolated form the customer images, it is important to describe what new threats > this approach adds to the PE role. Maybe the last paragraph in the section is > trying to make the point that there are new threats, but if so should say more > about the need for separation of virtual and infrastructure traffic. E.g., this > mitigates traffic from a virtual machine attacking the infrastructure traffic or > creating a denial of service by clogging up the infrastructure with frames. > > 2. The second paragraph of Security Considerations mentions that the XMPP > session needs to be secured. It describes the use of certificates, but this isn't > enough. Certificates need to be used with a protocol that uses certificates for > peer authentication. I think it's common to protect XMPP with TLS, for example > so you might want to look into that. Once a peer is authenticated with its > certificate, then the router server can perform authorization. It is important to > give at least one complete example of a method to secure the session. > > 3. The third paragraph of Security Considerations mentions a couple of > conventional methods for securing BGP. Is this more than what is typically > recommended within an L3VPN BGP (as opposed to a BGP speaker connected to > another provider)? If so, it would be good to say what are the additional threats > that require more security. > > 4. Section 6 mentions external Forwarders, and says that in this case "VPN routing > information received from the Route Server(s) SHOULD NOT be propagated to > the end-system." Is there a security consideration here? > > Brian > From nobody Tue Dec 9 10:35:27 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1171A01C6; Tue, 9 Dec 2014 10:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAxPjnzSwKZ9; Tue, 9 Dec 2014 10:35:23 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3195A1A00D1; Tue, 9 Dec 2014 10:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7319; q=dns/txt; s=iport; t=1418150123; x=1419359723; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=B90914AsAiu92RSIn8moXMe14oE/sxnQTGX1XC91Q0A=; b=gB7+ZshA13lhsCPPCbeXXFXGcrSgJn2TuM4lmXVV1QI2a8papvqiDZSW lpK0Em3HUpQ3nCxKxV7k28+ycpt/ynlcqC2ah6AIMjaS4jkpydap4vD1C qMsIQCdmRHxCdTljmADXBhItDWNIkDYMYXN1qajOpy2YEbSH7dlnj4JTV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFACdAh1StJA2E/2dsb2JhbABZgwZSWASDAcMehgkCgSYWAQEBAQF9hAMBAQQjDwE5CgIRCxgCAgUPBwsCAgkDAgECAUUGAQwGAgEBiDQNwB+XGgEBAQEBAQEBAgEBAQEBAQEBARmBJokkhRolOhiCV4FHBYlCiCSFPIENMIIvghOIDYNeggAcgXJPgQMCHgYcfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="378839676" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP; 09 Dec 2014 18:35:22 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sB9IZMGE005458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 18:35:22 GMT Received: from [64.101.72.27] (64.101.72.27) by xhc-rcd-x03.cisco.com (173.37.183.77) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 12:35:21 -0600 Message-ID: <548740F1.4010607@cisco.com> Date: Tue, 9 Dec 2014 11:35:29 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yaron Sheffer , IETF Security Directorate , The IESG , References: <5470E68D.3040204@gmail.com> <547E36ED.1020205@cisco.com> <5480CD20.6080300@gmail.com> In-Reply-To: <5480CD20.6080300@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [64.101.72.27] Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/lRyIIo8daqW99bc-GCsNgaHZG5Y Subject: Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 18:35:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Yaron, I believe < https://tools.ietf.org/html/draft-ietf-jose-cookbook-07 > addresses most of your comments; the exceptions being those points still under discussion (see Jim Schaad's latest reply). Please let me know if I missed anything I thought I fixed. Thank you, - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 12/4/14, 2:07 PM, Yaron Sheffer wrote: > Hi Matt, > > Please see my comments below. I have removed much of the original > text, and only left points that need further discussion. > > Thanks, Yaron > > On 12/03/2014 12:02 AM, ⌘ Matt Miller wrote: [...] >>> >>> • Unless I missed it, the document does not mention a machine >>> readable repository of these examples, which I am sure the >>> author has created while writing the draft. Making such a >>> repository publicly available would result in a much more >>> useful resource than the current document, which essentially >>> requires testers to scrape the document when creating their >>> test cases. >>> >> >> You did not miss it; I don't have a such a repository right now, >> but I can put one together. Would something on github.com be >> acceptable, or is there a better suggestion? > > GitHub would be a great place. > >> >>> • (Not a comment to the current document:) I wonder why there >>> is nothing explicit to distinguish a public key from a private >>> key, and they are only distinguished by the presence or absence >>> of several parameters, something that will not be natural to >>> most developers. PEM is doing it very well: "-----BEGIN RSA >>> PRIVATE KEY-----". >>> >>> • 3.4: the text is contradictory re: zero-padding of the value >>> "d". Is it using the minimum number of octets, or exactly 256 >>> octets (for a 2048-bit key)? >>> >> >> The intent is that "d" is not zero-padded, and I overqualified in >> my text. Would the following be acceptable? >> >> For a 2048-bit key, the field "n" is 256 octets in length when >> decoded and the field "d" is not longer than 256 octets in length >> when decoded. >> > > Yes. > >> > [snip] >> >>> • 5.1.1: since this is a "cookbook", we should be using the >>> public key, not the private key. A private key would only be >>> used in rare cases. Similarly 5.2.1. >>> >> >> The private keys are included for both reproduction (which only >> needs the public key) and verification (which necessitates the >> private key). >> >> If I can put an online repository together, I can change the >> examples to just include the public keys; otherwise would the >> following in 5.1 (and 5.2) be sufficient? >> >> Note that only the RSA public key is necessary to perform the >> encryption. However, the example includes the RSA private key >> to allow readers to validate the example's output. >> > > I'm fine with this new text. > >> >>> • 5.3.1: the "plaintext content" is a list of keys, which is >>> either confusing to the reader, or an actual error in the >>> document. >>> >> >> It is not in error. The most common usecase for password-based >> encryption was the import and export of key sets, and the >> Working Group desired a thorough example. >> >> Would it help if the following is added to 5.3? >> >> A common use of password-based encryption is the import/export >> of keys. Therefore this example uses a JWK Set for the >> plaintext content instead of the plaintext from figure 72. >> > > Yes, this would help. > >> >>> • 5.3.5: In the General Serialization version, I don't >>> understand why only the encrypted key is per-recipient. I would >>> expect the PBES2 parameters too (e.g., the salt) to be >>> per-recipient. Presumably each of them is using a different >>> password, and there's no reason to use a common salt. Similarly >>> in 5.4.5. >>> >> >> For compatibility across serializations (compact, general JSON, >> flattened JSON), all of the parameters need to be in the JWE >> Protected Header. In the general serialization, that means only >> the "encrypted_key" field is present for the (presumably) sole >> recipient. >> >> Would it be acceptable if the following were added to 5.3? >> >> Note that if password-based encryption is used for multiple >> recipients, it is expected that each recipient use different >> values for the PBES2 parameters "p2s" and "p2c". >> > > So I still don't understand: don't we need an example that > demonstrates how the JSON structure (or multiple structures) is > generated so that "each recipient use(s) different values"? > > In general I don't understand this "compatibility" thing. > Obviously there are some cases that cannot be expressed in all > serialization types. Otherwise why would we need three of them? > >>> • 5.7: same as above, it makes sense for the per-recipient key >>> to have an ID, rather than the content encryption key >>> (typically an ephemeral key). And then that ID should be in the >>> per-recipient data in 5.7.5. And similarly for 5.8. The later >>> Sec. 5.13 shows a syntax for multiple recipients that's >>> inconsistent with the single-recipient case, which would make >>> sense if we got rid of the array. >>> >> >> For compatibility across serializations (compact, general JSON, >> flattened JSON), all of the parameters need to be in the JWE >> Protected Header. Also, the mixing of "recipients" and >> "encrypted_key"/"header" in the top-level object is not permitted >> for the general serialization. >> > > Still confused. Sorry. > >>> • 5.11: this example seems strange to me - why would anybody >>> NOT want to integrity-protect the key ID and algorithm? I would >>> prefer a more realistic example, or failing that, a >>> recommendation to developers to avoid this practice. Similarly >>> 5.12, which is an even worse idea. >>> >> >> Integrity protection was thoroughly discussed in the JOSE WG. >> While there are some limited attacks possible when some >> parameters are unprotected, the WG felt there were enough use >> cases where these attacks are mitigated through other means that >> integrity protection of the part of all of the header is not >> always required. > > So (personal opinion here) I think the WG took a security risk > that should not have been taken in 2014, for a minor performance > gain. We have seen too many protocols fail because of > integrity-protection shortcuts. Who would have thought you need to > integrity-protect the padding field! The fact that CMS took this > route back in 1999 is sort of irrelevant, as we've all learned a > lot since then. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUh0DxAAoJEDWi+S0W7cO1yn8H/3qu51pBi99f8FmuI/ZyW+9+ LJfToPCcaTlSWqLR14mzApvm2VTgX60R89+ykQzVcvRIqZZvr4gqtJFnNtSUsGgs PWEU837QEi0B/xfLADk6YF8om3B5XR6SX1xS4BSY4+oxh1XjIeRFoNqE2XLcFCd/ P5NLs5NH3ZJS4khKFTgw7dzYBiSWUf+DEOZaPb8vcRVRUy7giJlKbax5u1jQgk9X 1e7+W72rpjSVfd9+cP7Jme4Atz/K7MKawebz+6UsTVRH3dImwg4qy2IggMrGxrba TZXdXE4wxVVlbc768cTjZJPtHwZ/HH/e/sgNrUK66WSrBveoBDf7v8NGu7+pS8w= =3XEs -----END PGP SIGNATURE----- From nobody Tue Dec 9 10:52:44 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBEA1A6FB2 for ; Tue, 9 Dec 2014 10:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFfr_jubIQoz for ; Tue, 9 Dec 2014 10:52:41 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545691A1DFA for ; Tue, 9 Dec 2014 10:52:41 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id b6so1031407lbj.36 for ; Tue, 09 Dec 2014 10:52:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ue9qLtbtIOxPxefn/88FH8aCUhXsY+VizUgtG/dt+Eg=; b=Xtm73Yh2g0YPudvzC5/gto0qbMta6XLl6ZeHEJrqGyV+nCrtpxWk4MnclWzL5/rZaw f0O3VJVC2kHOyyDRCnyhUX/mZqHDhm+X3NZoB5jz/j8ijf1OViSDpF4BznJ/nkRf6jOT dMad/5hB1DyW99WnY6W1w7MJsuz/1R25fFhtyNrkmausGWaWoGdiwt9zw3l0tYMEWiqg 35QMadI4WiB6a5MicVJilIktT4mIAsMIO3hNGJQx9lkkidQGozhRrLrZ9NrOLnUEusrU HyiQbJaWrMHEEZ3eU8P4bmkxMoRFxDgCPbNIHCGoGpVZdf3Latjh2XyX8ryarRnVTBmp Lwrw== MIME-Version: 1.0 X-Received: by 10.152.4.233 with SMTP id n9mr23616835lan.61.1418151159881; Tue, 09 Dec 2014 10:52:39 -0800 (PST) Received: by 10.112.49.52 with HTTP; Tue, 9 Dec 2014 10:52:39 -0800 (PST) Date: Tue, 9 Dec 2014 13:52:39 -0500 Message-ID: From: Kathleen Moriarty To: "secdir@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/raTc8UwZthELt1BTSZff2rO-Ws8 Subject: [secdir] New boilerplate for reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 18:52:43 -0000 Hello, Stephen & I worked on an alternate boilerplate for reviews per request from several ADs as editors are a bit confused with the current text. They are not sure what to do with the reviews. Ideally, we'd like them to address your comments during last call and then Stephen & I can pick up points that were not adequately addressed. Here is a proposal for alternate text, let us know what you think: 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. Thank you. -- Best regards, Kathleen From nobody Tue Dec 9 10:55:36 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19311A87A4 for ; Tue, 9 Dec 2014 10:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2Rv-qiUOc5j for ; Tue, 9 Dec 2014 10:55:32 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 4D3311A87A3 for ; Tue, 9 Dec 2014 10:55:32 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id sB9ItTax017761 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 9 Dec 2014 19:55:30 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id sB9ItQop002270 for ; Tue, 9 Dec 2014 19:55:29 +0100 (CET) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1418151329; bh=x4nSly+3N4GlwTQwUBnb5ktsgZHJXEIw958Jcim5ztg=; h=Date:From:To:Subject:References:In-Reply-To; b=3EVMbsX0Z7TZ4ogBcCpvkvEruh/O8kCxnWHBQHNzQbXEpttOjstSV4SKk3fqdJyxW yytlIzEorCRKeYE5z3MrVnJpNEcU/UTH7ktMahxngras8BJY3+xnBz3IX2wSuZ1N/p AqgyKjJMbl3uNsHK128Ub/2YhABJKzwvCTXhmJVY= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.116] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)) for secdir@ietf.org; Tue, 9 Dec 2014 19:55:24 +0100 Message-ID: <5487459C.1060004@sunet.se> Date: Tue, 09 Dec 2014 19:55:24 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: secdir@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09NpuTuxD - d2d7842507e1 - 20141209 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/DQrAd2PdS6IxvFihfkNrE1u4jRs Subject: Re: [secdir] New boilerplate for reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 18:55:34 -0000 On 12/09/2014 07:52 PM, Kathleen Moriarty wrote: > Hello, > > Stephen & I worked on an alternate boilerplate for reviews per request > from several ADs as editors are a bit confused with the current text. > They are not sure what to do with the reviews. Ideally, we'd like > them to address your comments during last call and then Stephen & I > can pick up points that were not adequately addressed. > > Here is a proposal for alternate text, let us know what you think: > > 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. > > Thank you. > Reads a lot like the last one. Good :-) Cheers Leif From nobody Tue Dec 9 12:40:11 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A734E1A017C; Tue, 9 Dec 2014 12:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwNLhHafTrsg; Tue, 9 Dec 2014 12:40:07 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3897F1A017A; Tue, 9 Dec 2014 12:40:07 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id z12so1922468wgg.15 for ; Tue, 09 Dec 2014 12:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ViWZdHn0Z6fMGb9+kC2rivumj9pCS7TJUV2j0aA61J4=; b=AKCqmMBFCbbKcWYY8+K+ikY1i5gHG9esZOwloBbLdAwujuQUAKhVZtGpJSOOdKG9vZ 19AnV6O9V1tLr6AAx1euIkzGNSKrXIVHQXSgfPfIY5eeLY6RFAOaZHv0J908Y0SAnaJu Ygh5Ik1KOfT2DP0fx1yQPgKqCSf/oNfiB7kYZq0LJ1t8qx8YGLU7NRFVxvNonro1wPsB LbQrQihb2rWuzTMAC+D9Ube6N3FO08NYUpZcsZUvwHllzlRJKP/xAM6N0fnRMRfjDeBH THznsZF2RSeMC9Nc94Jeg5PVQ8b37W5VUQ0lMoAc9HoTkb/VnDb/4sbU6A1T1YWT05X8 BMIQ== X-Received: by 10.180.82.170 with SMTP id j10mr425597wiy.35.1418157605833; Tue, 09 Dec 2014 12:40:05 -0800 (PST) Received: from [10.0.0.9] (bzq-79-176-33-71.red.bezeqint.net. [79.176.33.71]) by mx.google.com with ESMTPSA id u9sm3180410wjy.37.2014.12.09.12.40.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Dec 2014 12:40:04 -0800 (PST) Message-ID: <54875E23.9080207@gmail.com> Date: Tue, 09 Dec 2014 22:40:03 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= , IETF Security Directorate , The IESG , draft-ietf-jose-cookbook.all@tools.ietf.org References: <5470E68D.3040204@gmail.com> <547E36ED.1020205@cisco.com> <5480CD20.6080300@gmail.com> <548740F1.4010607@cisco.com> In-Reply-To: <548740F1.4010607@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/SlgfSa3qpttFmiavl5DaaeXzPoA Subject: Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 20:40:09 -0000 Hi Matt, Yes, I believe it does. I will respond to Jim's mail separately. Thanks, Yaron On 12/09/2014 08:35 PM, ⌘ Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello Yaron, > > I believe < https://tools.ietf.org/html/draft-ietf-jose-cookbook-07 > > addresses most of your comments; the exceptions being those points > still under discussion (see Jim Schaad's latest reply). Please let me > know if I missed anything I thought I fixed. > > > Thank you, > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > On 12/4/14, 2:07 PM, Yaron Sheffer wrote: >> Hi Matt, >> >> Please see my comments below. I have removed much of the original >> text, and only left points that need further discussion. >> >> Thanks, Yaron >> >> On 12/03/2014 12:02 AM, ⌘ Matt Miller wrote: [...] >>>> >>>> • Unless I missed it, the document does not mention a machine >>>> readable repository of these examples, which I am sure the >>>> author has created while writing the draft. Making such a >>>> repository publicly available would result in a much more >>>> useful resource than the current document, which essentially >>>> requires testers to scrape the document when creating their >>>> test cases. >>>> >>> >>> You did not miss it; I don't have a such a repository right now, >>> but I can put one together. Would something on github.com be >>> acceptable, or is there a better suggestion? >> >> GitHub would be a great place. >> >>> >>>> • (Not a comment to the current document:) I wonder why there >>>> is nothing explicit to distinguish a public key from a private >>>> key, and they are only distinguished by the presence or absence >>>> of several parameters, something that will not be natural to >>>> most developers. PEM is doing it very well: "-----BEGIN RSA >>>> PRIVATE KEY-----". >>>> >>>> • 3.4: the text is contradictory re: zero-padding of the value >>>> "d". Is it using the minimum number of octets, or exactly 256 >>>> octets (for a 2048-bit key)? >>>> >>> >>> The intent is that "d" is not zero-padded, and I overqualified in >>> my text. Would the following be acceptable? >>> >>> For a 2048-bit key, the field "n" is 256 octets in length when >>> decoded and the field "d" is not longer than 256 octets in length >>> when decoded. >>> >> >> Yes. >> >>> >> [snip] >>> >>>> • 5.1.1: since this is a "cookbook", we should be using the >>>> public key, not the private key. A private key would only be >>>> used in rare cases. Similarly 5.2.1. >>>> >>> >>> The private keys are included for both reproduction (which only >>> needs the public key) and verification (which necessitates the >>> private key). >>> >>> If I can put an online repository together, I can change the >>> examples to just include the public keys; otherwise would the >>> following in 5.1 (and 5.2) be sufficient? >>> >>> Note that only the RSA public key is necessary to perform the >>> encryption. However, the example includes the RSA private key >>> to allow readers to validate the example's output. >>> >> >> I'm fine with this new text. >> >>> >>>> • 5.3.1: the "plaintext content" is a list of keys, which is >>>> either confusing to the reader, or an actual error in the >>>> document. >>>> >>> >>> It is not in error. The most common usecase for password-based >>> encryption was the import and export of key sets, and the >>> Working Group desired a thorough example. >>> >>> Would it help if the following is added to 5.3? >>> >>> A common use of password-based encryption is the import/export >>> of keys. Therefore this example uses a JWK Set for the >>> plaintext content instead of the plaintext from figure 72. >>> >> >> Yes, this would help. >> >>> >>>> • 5.3.5: In the General Serialization version, I don't >>>> understand why only the encrypted key is per-recipient. I would >>>> expect the PBES2 parameters too (e.g., the salt) to be >>>> per-recipient. Presumably each of them is using a different >>>> password, and there's no reason to use a common salt. Similarly >>>> in 5.4.5. >>>> >>> >>> For compatibility across serializations (compact, general JSON, >>> flattened JSON), all of the parameters need to be in the JWE >>> Protected Header. In the general serialization, that means only >>> the "encrypted_key" field is present for the (presumably) sole >>> recipient. >>> >>> Would it be acceptable if the following were added to 5.3? >>> >>> Note that if password-based encryption is used for multiple >>> recipients, it is expected that each recipient use different >>> values for the PBES2 parameters "p2s" and "p2c". >>> >> >> So I still don't understand: don't we need an example that >> demonstrates how the JSON structure (or multiple structures) is >> generated so that "each recipient use(s) different values"? >> >> In general I don't understand this "compatibility" thing. >> Obviously there are some cases that cannot be expressed in all >> serialization types. Otherwise why would we need three of them? >> >>>> • 5.7: same as above, it makes sense for the per-recipient key >>>> to have an ID, rather than the content encryption key >>>> (typically an ephemeral key). And then that ID should be in the >>>> per-recipient data in 5.7.5. And similarly for 5.8. The later >>>> Sec. 5.13 shows a syntax for multiple recipients that's >>>> inconsistent with the single-recipient case, which would make >>>> sense if we got rid of the array. >>>> >>> >>> For compatibility across serializations (compact, general JSON, >>> flattened JSON), all of the parameters need to be in the JWE >>> Protected Header. Also, the mixing of "recipients" and >>> "encrypted_key"/"header" in the top-level object is not permitted >>> for the general serialization. >>> >> >> Still confused. Sorry. >> >>>> • 5.11: this example seems strange to me - why would anybody >>>> NOT want to integrity-protect the key ID and algorithm? I would >>>> prefer a more realistic example, or failing that, a >>>> recommendation to developers to avoid this practice. Similarly >>>> 5.12, which is an even worse idea. >>>> >>> >>> Integrity protection was thoroughly discussed in the JOSE WG. >>> While there are some limited attacks possible when some >>> parameters are unprotected, the WG felt there were enough use >>> cases where these attacks are mitigated through other means that >>> integrity protection of the part of all of the header is not >>> always required. >> >> So (personal opinion here) I think the WG took a security risk >> that should not have been taken in 2014, for a minor performance >> gain. We have seen too many protocols fail because of >> integrity-protection shortcuts. Who would have thought you need to >> integrity-protect the padding field! The fact that CMS took this >> route back in 1999 is sort of irrelevant, as we've all learned a >> lot since then. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iQEcBAEBCgAGBQJUh0DxAAoJEDWi+S0W7cO1yn8H/3qu51pBi99f8FmuI/ZyW+9+ > LJfToPCcaTlSWqLR14mzApvm2VTgX60R89+ykQzVcvRIqZZvr4gqtJFnNtSUsGgs > PWEU837QEi0B/xfLADk6YF8om3B5XR6SX1xS4BSY4+oxh1XjIeRFoNqE2XLcFCd/ > P5NLs5NH3ZJS4khKFTgw7dzYBiSWUf+DEOZaPb8vcRVRUy7giJlKbax5u1jQgk9X > 1e7+W72rpjSVfd9+cP7Jme4Atz/K7MKawebz+6UsTVRH3dImwg4qy2IggMrGxrba > TZXdXE4wxVVlbc768cTjZJPtHwZ/HH/e/sgNrUK66WSrBveoBDf7v8NGu7+pS8w= > =3XEs > -----END PGP SIGNATURE----- > From nobody Tue Dec 9 16:21:27 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186F01A0399; Tue, 9 Dec 2014 16:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTbpLncbOy_y; Tue, 9 Dec 2014 16:21:18 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775AE1A0318; Tue, 9 Dec 2014 16:21:18 -0800 (PST) X-AuditID: 12074425-f798e6d000000d1a-5e-548791fd8c14 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 dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id C5.90.03354.DF197845; Tue, 9 Dec 2014 19:21:17 -0500 (EST) 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 sBA0LGLA027073; Tue, 9 Dec 2014 19:21:16 -0500 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBA0LEAj028994; Tue, 9 Dec 2014 19:21:15 -0500 From: Tom Yu To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tls-prohibiting-rc4.all@tools.ietf.org Date: Tue, 09 Dec 2014 19:21:13 -0500 Message-ID: Lines: 24 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUixCmqrPt3YnuIwYpXwhar985kspjxZyKz xYeFD1kcmD2WLPnJ5PHl8me2AKYoLpuU1JzMstQifbsErow/x1+yFMziqvj8fiFzA+Nyji5G Tg4JAROJzeefsELYYhIX7q1n62Lk4hASWMwksW/VckYIZwOjxKYVO5ghnNeMEguv/mUCaWET kJY4fnkXmC0iECex/WMfmC0sYC0xvfcSmM0ioCrRe/oxG4jNK6Arced0PzOIzSPAKTH5Ww8z RFxQ4uTMJywgNrOAlsSNfy+ZJjDyzkKSmoUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGu hV5uZoleakrpJkZQULG7qO5gnHBI6RCjAAejEg+vhmVbiBBrYllxZe4hRkkOJiVR3is17SFC fEn5KZUZicUZ8UWlOanFhxglOJiVRHjXsgDleFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRm p6YWpBbBZGU4OJQkeL9PAGoULEpNT61Iy8wpQUgzcXCCDOcBGn4QpIa3uCAxtzgzHSJ/ilFR Spz3FkhCACSRUZoH1wuL+leM4kCvCPP2glTxABMGXPcroMFMQINfJLaCDC5JREhJNTDOTFhp 8J0lpmZKlFvUjZRLfguZFOpLdTZ6NR0UCPJgP711heauTVvnWM/4mNIeo8Hy6MqikmuzOjZ/ Z1KTOaSnoBrP0jztTsuxVrn1WVtkdk26Mnmf3cblaR5d0Zsbot9/k/q23aWze8X/ZzZPXK4a ruWo3NF23v6czEz+bQ3ZU56z6F15sX+dEktxRqKhFnNRcSIAFyhDpNUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/kk0GZru3HqolZrE-221riBIcWjY Subject: [secdir] secdir review of draft-ietf-tls-prohibiting-rc4-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 00:21: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. Summary: ready with minor issues This document deprecates RC4 cipher suites in TLS due to attacks that can recover repeated plaintexts given about 2^26 sessions. Accordingly, it says that TLS implementations MUST NOT use RC4 cipher suites. However, I noticed that RFC 5469 specifies only "SHOULD NOT" for single-DES cipher suites in TLS. I don't know whether a 2^56 offline exhaustive key search that reveals an initial plaintext is directly comparable to a 2^26 online attack that reveals the entire plaintext, but it seems odd that single-DES is only "SHOULD NOT" while RC4 is "MUST NOT". Perhaps this document is not the right place to fix that discrepancy. On the other hand, I am wondering if an unintended consequence of sites or implementations disabling RC4 cipher suites is falling back to single-DES. What prevents this fallback from happening? I don't have a lot of the relevant information about TLS implementations as deployed. From nobody Tue Dec 9 16:50:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB541A6EF0; Tue, 9 Dec 2014 16:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIbUL4clVye4; Tue, 9 Dec 2014 16:50:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518321A1B7C; Tue, 9 Dec 2014 16:50:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9CD7BBDD8; Wed, 10 Dec 2014 00:50:00 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqNzROyiyFq5; Wed, 10 Dec 2014 00:49:59 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.41.57.238]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0D3ADBDFB; Wed, 10 Dec 2014 00:49:59 +0000 (GMT) Message-ID: <548798B3.6070205@cs.tcd.ie> Date: Wed, 10 Dec 2014 00:49:55 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Tom Yu , iesg@ietf.org, secdir@ietf.org, draft-ietf-tls-prohibiting-rc4.all@tools.ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qWXs4B0GuHizpF2R6Nrhrvuk0Tw Subject: Re: [secdir] secdir review of draft-ietf-tls-prohibiting-rc4-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 00:50:11 -0000 Hi Tom, On 10/12/14 00:21, Tom Yu wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Summary: ready with minor issues > > This document deprecates RC4 cipher suites in TLS due to attacks that > can recover repeated plaintexts given about 2^26 sessions. Accordingly, > it says that TLS implementations MUST NOT use RC4 cipher suites. > > However, I noticed that RFC 5469 specifies only "SHOULD NOT" for > single-DES cipher suites in TLS. I don't know whether a 2^56 offline > exhaustive key search that reveals an initial plaintext is directly > comparable to a 2^26 online attack that reveals the entire plaintext, > but it seems odd that single-DES is only "SHOULD NOT" while RC4 is "MUST > NOT". Perhaps this document is not the right place to fix that > discrepancy. That point was debated at length by the WG, which eventually did reach a relatively strong consensus on the MUST NOT despite the knowledge that some people might need to keep RC4 around even after this is published. > On the other hand, I am wondering if an unintended consequence of sites > or implementations disabling RC4 cipher suites is falling back to > single-DES. What prevents this fallback from happening? I don't have a > lot of the relevant information about TLS implementations as deployed. No, single-DES doesn't feature. Triple-DES is implemented but slow. AES as a h/w instruction on various chips (incl. many intel processors and others) is relatively widely available and is faster and better than RC4. For those without AES h/w the likely evolution will be to chacha20 which is also being worked between the TLS WG and CFRG and which is actually already deployed in some browsers. (And which has good lineage via the eStream crypto competition. Well, good enough according to CFRG, which is why they're involved.) Cheers, S. > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From nobody Tue Dec 9 16:55:56 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFFC1A1B7C; Tue, 9 Dec 2014 16:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HMRnPc2rGJK; Tue, 9 Dec 2014 16:52:48 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:782]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71D571A0396; Tue, 9 Dec 2014 16:52:48 -0800 (PST) Received: from BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) by BN3PR0301MB1188.namprd03.prod.outlook.com (25.160.156.15) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 10 Dec 2014 00:52:26 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 10 Dec 2014 00:52:25 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0031.000; Wed, 10 Dec 2014 00:52:25 +0000 From: Andrei Popov To: Tom Yu , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-tls-prohibiting-rc4.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-tls-prohibiting-rc4-01 Thread-Index: AQHQFA8/R5nH5Nf+j02x4a9+JAqd9ZyH+/EA Date: Wed, 10 Dec 2014 00:52:25 +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: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1251;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; x-forefront-prvs: 0421BF7135 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(46034005)(189002)(13464003)(377454003)(199003)(51914003)(99286002)(54356999)(76176999)(101416001)(50986999)(54606007)(21056001)(106356001)(106116001)(105586002)(86612001)(99396003)(87936001)(2171001)(120916001)(2656002)(2201001)(86362001)(107886001)(92566001)(107046002)(102836002)(68736005)(40100003)(33656002)(230783001)(74316001)(122556002)(97736003)(54206007)(76576001)(2501002)(77156002)(62966003)(31966008)(4396001)(20776003)(19580405001)(64706001)(19580395003)(46102003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1188; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/T5DlFoyATMuSTooVsN4OG6cymRg X-Mailman-Approved-At: Tue, 09 Dec 2014 16:55:55 -0800 Subject: Re: [secdir] secdir review of draft-ietf-tls-prohibiting-rc4-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 00:52:50 -0000 Thanks for the review Tom, There are definitely other weak cipher suites defined for TLS: EXPORT, NULL= , MD5, DES to name a few. It was not easy to reach consensus on deprecating= just one algorithm (RC4). Bundling other weak crypto into the same I-D wou= ld probably have caused even more opposition, so my preference would be to = tackle those in separate I-D(s). > On the other hand, I am wondering if an unintended consequence of sites o= r implementations disabling RC4 cipher suites is falling back to single-DES= . What prevents this fallback from happening? Unlike RC4 (which is widely supported and preferred by multiple TLS clients= and servers), single-DES is already disabled by default in those TLS clien= ts and servers that receive regular updates. Publishing an IETF document pr= ohibiting single-DES is probably still worthwhile, just less impactful in t= erms of providing guidance to the industry. Cheers, Andrei -----Original Message----- From: Tom Yu [mailto:tlyu@mit.edu]=20 Sent: Tuesday, December 9, 2014 4:21 PM To: iesg@ietf.org; secdir@ietf.org; draft-ietf-tls-prohibiting-rc4.all@tool= s.ietf.org Subject: secdir review of draft-ietf-tls-prohibiting-rc4-01 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 minor issues This document deprecates RC4 cipher suites in TLS due to attacks that can r= ecover repeated plaintexts given about 2^26 sessions. Accordingly, it says= that TLS implementations MUST NOT use RC4 cipher suites. However, I noticed that RFC 5469 specifies only "SHOULD NOT" for single-DES= cipher suites in TLS. I don't know whether a 2^56 offline exhaustive key = search that reveals an initial plaintext is directly comparable to a 2^26 o= nline attack that reveals the entire plaintext, but it seems odd that singl= e-DES is only "SHOULD NOT" while RC4 is "MUST NOT". Perhaps this document = is not the right place to fix that discrepancy. On the other hand, I am wondering if an unintended consequence of sites or = implementations disabling RC4 cipher suites is falling back to single-DES. = What prevents this fallback from happening? I don't have a lot of the rel= evant information about TLS implementations as deployed. From nobody Tue Dec 9 18:02:42 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4981A8785 for ; Tue, 9 Dec 2014 18:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dH7A1eS0GDr for ; Tue, 9 Dec 2014 18:02:38 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181451A6FE5 for ; Tue, 9 Dec 2014 18:02:38 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kq14so1760409pab.6 for ; Tue, 09 Dec 2014 18:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=9l7hZ3GDmsplDYjnVwMvXqeJdXuT8ASfYwwYPht3hKY=; b=h2Lym8wWSZFA/+0mc6RIAVQkXMouPCb/GGicAN5xbJPtuoF2yzohjunzvZhs7K31fD gRnX4nW4mTDmLWaD9MpRQ1sG3VthRmEcnzMruqQGOQjfaT8WAk7GFh00LGWBOD8UsDUU KiW786maYvoxEI1eWDUoOS3+SVY3PKtDthU7eMaCbv7d/BFmZSskMNfR9064tkq7qmt+ yG9H9vDOU898MG//7kCMxn5Vqs6dG/zHQgP1D1vclvlBpNQTrGIz6QWrlZNQkDeQkhZq CA3WfiJnRNEfb0fVOTUZ0RrCFjh7MnLsPwRMOCA8QJyeg0mkQM+Cn01LXj97X7QCh3an TXGw== X-Received: by 10.66.227.41 with SMTP id rx9mr2188049pac.153.1418176957236; Tue, 09 Dec 2014 18:02:37 -0800 (PST) Received: from spandex.local (216-67-120-90.dynamic.cdma.acsalaska.net. [216.67.120.90]) by mx.google.com with ESMTPSA id ye4sm16368pab.35.2014.12.09.18.02.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Dec 2014 18:02:36 -0800 (PST) Message-ID: <5487A9BB.4040603@gmail.com> Date: Tue, 09 Dec 2014 17:02:35 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: secdir@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/cQUIhLOpbNOB33h8dNgq0OWWIyo Subject: Re: [secdir] New boilerplate for reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 02:02:39 -0000 On 12/9/14 9:52 AM, Kathleen Moriarty wrote: > Here is a proposal for alternate text, let us know what you think: Should we be construing this as a suggestion to minimize comments on document issues not related to security? Melinda From nobody Tue Dec 9 18:59:57 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2EF1A8871 for ; Tue, 9 Dec 2014 18:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0ixuY7wbhep for ; Tue, 9 Dec 2014 18:59:55 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B351A87C4 for ; Tue, 9 Dec 2014 18:59:54 -0800 (PST) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBA2xq6h027497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 21:59:53 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sBA2xq6h027497 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418180393; bh=jrtSu4JbuCx0pBq3/USxbfFgfWQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ni4RGmPx35JNfw/V4Xae8Xv4Eo9nF7/mYJf5GzMOKeqlsoD1S4FgtxRefmKHrjfSp QrXSREnOdm5c0ObLTJfEYzQE9VC8xwoqQlvITkcseyMOBclFBxBLasZAo4w9w6Jets 32FMJ4PWmZC/wznKCO3Qfcw83JpuMbkzNVJC2dsw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sBA2xq6h027497 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd02.lss.emc.com (RSA Interceptor); Tue, 9 Dec 2014 21:59:42 -0500 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBA2xfqU006718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 21:59:42 -0500 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub13.corp.emc.com (128.222.70.234) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 9 Dec 2014 21:59:41 -0500 Received: from MX103CL02.corp.emc.com ([169.254.6.214]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 21:59:41 -0500 From: "Moriarty, Kathleen" To: Melinda Shore Thread-Topic: [secdir] New boilerplate for reviews Thread-Index: AQHQE+FzF8yzmALCK0+FryOYEp7L1ZyIZsmA//+8Ix8= Date: Wed, 10 Dec 2014 02:59:40 +0000 Message-ID: <9AFFE6C3-D462-4350-9923-BFAF2E32DFD5@emc.com> References: , <5487A9BB.4040603@gmail.com> In-Reply-To: <5487A9BB.4040603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Hyq8-G-szbDvEviMEXyGOR-Z598 Cc: "secdir@ietf.org" Subject: Re: [secdir] New boilerplate for reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 02:59:56 -0000 Sent from my iPhone > On Dec 9, 2014, at 9:02 PM, "Melinda Shore" wro= te: >=20 >> On 12/9/14 9:52 AM, Kathleen Moriarty wrote: >> Here is a proposal for alternate text, let us know what you think: >=20 > Should we be construing this as a suggestion to minimize > comments on document issues not related to security? Good question. The change suggestion is a result of editor confusion when = they receive a SecDir review. They usually respond to the reviewer (treat = it like any other last call comments), but some are not quite sure with the= current mention of it being for the ADs. Reviews are helpful whenever the= y come in, but if the comments have already been addressed in some way duri= ng the IETF last call, it makes it a lot easier in the IESG review. If a reviewer is familiar with other parts of the work and has helpful comm= ents & suggestions, please make them to help improve the draft. Stephen suggested some alternate words to "improving the security requireme= nts and considerations in IETF drafts" (intent is to capture that security = comments may be anywhere in the draft and not limited to the security consi= derations). The text would be: "improving the security and privacy propert= ies of IETF specifications". Thank you, Kathleen >=20 > Melinda >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue Dec 9 19:51:11 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03E31A88EB; Tue, 9 Dec 2014 19:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxVTWxK8x5Qw; Tue, 9 Dec 2014 19:51:02 -0800 (PST) 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 95AD71A88E1; Tue, 9 Dec 2014 19:51:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMR37666; Wed, 10 Dec 2014 03:51:00 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 10 Dec 2014 03:50:59 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.3]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 10 Dec 2014 11:50:57 +0800 From: "Zhangdacheng (Dacheng)" To: "secdir@ietf.org" , The IESG Thread-Topic: Secdir review of draft-ietf-mile-enum-reference-format-10 Thread-Index: AQHQFCyAVFkOFbI4vE6cR42dFpdb5w== Date: Wed, 10 Dec 2014 03:50:56 +0000 Message-ID: References: <6BAB7B9A-1A70-4957-ADC2-1836F22A4219@cisco.com> In-Reply-To: <6BAB7B9A-1A70-4957-ADC2-1836F22A4219@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/1tCQK-bTbzNJ2v3O4WuqUlHtm3Q Cc: "draft-ietf-mile-enum-reference-format.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-ietf-mile-enum-reference-format-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 03:51:04 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. This document is establishing a container for publicly available enumeratio= n values to be included in an IODEF [IODEF] document. Several questions abo= ut the proposed solution are listed as follows.=20 1) In this specification, a given enumeration is uniquely identified by the= specIndex attribute. However the usage of ID is not clearly introduced. In= the security consideration section, it is mentioned that the miss-match be= tween the index and the ID may cause problem. Could you please give me some= clues? 2) Where is section 2.2? 3) In the abstract, it is stated that "This memo establishes a stand-alone = data format to include both the external specification and specific enumera= tion value,. However, I didn't find the specific enumeration value in the e= xample provided in Section 2.1: " CXI-1234-XYZ http://cxi.example.com Foo " Cheers Dacheng From nobody Wed Dec 10 03:22:38 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70EA1A6FFA for ; Wed, 10 Dec 2014 03:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gh3K-BhdZ0QK for ; Wed, 10 Dec 2014 03:22:34 -0800 (PST) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 73BA91A1A1E for ; Wed, 10 Dec 2014 03:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1418210553; d=isode.com; s=selector; i=@isode.com; bh=CEuQfy+IfTPjY8pk5LIM0oUWys4N4XKz0ypAs6jyFUg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=NfREqQCo2T1rg2O3Fq0lw4Kkoj04he1XM/LHYihF2paJ/rl4r3ugitBYqqnpgWSAd4JKyS aMtrqi/2xqyWEkzoaoy4oPUR6hdphGE5OeMEnhIkIXqDGCVlvbe3+C4X5r4DZF6z+bLxHe TjaJUz44bgvx7qB64RR6v2F+MAI0i9E=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 10 Dec 2014 11:22:32 +0000 Message-ID: <54882CF2.2020809@isode.com> Date: Wed, 10 Dec 2014 11:22:26 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 To: Kathleen Moriarty , "secdir@ietf.org" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/_oQjZ5N4OnuNFLy9GTh6LTkVsfM Subject: Re: [secdir] New boilerplate for reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 11:22:36 -0000 On 09/12/2014 18:52, Kathleen Moriarty wrote: > Hello, > > Stephen & I worked on an alternate boilerplate for reviews per request > from several ADs as editors are a bit confused with the current text. > They are not sure what to do with the reviews. Ideally, we'd like > them to address your comments during last call and then Stephen & I > can pick up points that were not adequately addressed. > > Here is a proposal for alternate text, let us know what you think: > > 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. I think this better reflects reality, so I am supportive of the new boilerplate. From nobody Wed Dec 10 04:39:24 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F65F1A871F for ; Wed, 10 Dec 2014 04:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRhzvzibw0HE for ; Wed, 10 Dec 2014 04:39:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545301A1A81 for ; Wed, 10 Dec 2014 04:39:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3ECA5BE80; Wed, 10 Dec 2014 12:39:18 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ubkHEL-GImV; Wed, 10 Dec 2014 12:39:18 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1AD59BE7C; Wed, 10 Dec 2014 12:39:18 +0000 (GMT) Message-ID: <54883EF6.5000207@cs.tcd.ie> Date: Wed, 10 Dec 2014 12:39:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Moriarty, Kathleen" , Melinda Shore References: , <5487A9BB.4040603@gmail.com> <9AFFE6C3-D462-4350-9923-BFAF2E32DFD5@emc.com> In-Reply-To: <9AFFE6C3-D462-4350-9923-BFAF2E32DFD5@emc.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/P5Qie4W8qkq5hRBEB8h0KVx56E8 Cc: "secdir@ietf.org" Subject: Re: [secdir] New boilerplate for reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 12:39:23 -0000 On 10/12/14 02:59, Moriarty, Kathleen wrote: > If a reviewer is familiar with other parts of the work and has > helpful comments & suggestions, please make them to help improve the > draft. Right. Useful constructive comments should always be welcome if you have them. If you can separate those out from security or privacy issues that's nice, but mostly not needed since reviews aren't usually very long. And while we're on this, Kathleen and I asked Adrian Farrel (RTG AD) if he'd come along to the secdir lunch next time and give us his impressions of how secdir reviews are perceived from the other side. Could be fun:-) And should be useful since it was Adrian who was asking for a better boilerplate. Cheers, S. From nobody Thu Dec 11 04:17:26 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DF71ACE2E for ; Thu, 11 Dec 2014 04:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6GGIc-A2U9Y for ; Thu, 11 Dec 2014 04:17:23 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 A86AC1ACE28 for ; Thu, 11 Dec 2014 04:17:21 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sBBCHGBn019713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Dec 2014 14:17:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBBCHGsd010608; Thu, 11 Dec 2014 14:17:16 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21641.35660.321337.279056@fireball.kivinen.iki.fi> Date: Thu, 11 Dec 2014 14:17:16 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 2 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/GnJooJI9P0IdhTsmJzA0TmpoSM4 Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 12:17:25 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sam Hartman is next in the rotation. For telechat 2014-12-18 Reviewer LC end Draft Tina TSOU T 2014-12-08 draft-ietf-dnsop-dnssec-key-timing-06 Sean Turner T 2014-12-15 draft-ietf-ianaplan-icg-response-06 Carl Wallace T 2014-12-05 draft-ietf-json-text-sequence-10 Klaas Wierenga T 2014-12-08 draft-ietf-mpls-tp-te-mib-09 For telechat 2015-01-08 Shaun Cooley T 2015-01-05 draft-dawkins-iesg-one-or-more-04 Alan DeKok T 2015-01-01 draft-higgs-hbbtv-urn-00 Phillip Hallam-Baker T 2014-12-24 draft-ietf-pce-rfc7150bis-01 David Waltermire T 2014-12-09 draft-ietf-kitten-cammac-00 Last calls and special requests: Derek Atkins 2014-12-29 draft-pechanec-pkcs11uri-16 Donald Eastlake 2014-12-24 draft-ietf-httpauth-hoba-07 Shawn Emery 2014-12-24 draft-ietf-aqm-recommendation-08 Dorothy Gellert 2014-12-22 draft-ietf-ippm-rate-problem-08 Tobias Gondrom 2014-12-18 draft-ietf-mpls-ldp-ipv6-14 Olafur Gudmundsson 2014-12-24 draft-ietf-ospf-te-metric-extensions-08 Steve Hanna 2014-12-24 draft-ietf-roll-admin-local-policy-02 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Dan Harkins 2014-12-22 draft-ietf-tsvwg-port-use-06 David Harrington 2014-12-24 draft-ietf-tsvwg-sctp-dtls-encaps-07 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-07 Matt Lepinski 2014-11-18 draft-nottingham-safe-hint-05 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Sean Turner 2014-10-13 draft-ietf-mpls-lsp-ping-relay-reply-06 Sam Weiler 2014-12-08 draft-ietf-l3vpn-acceptown-community-08 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-12 Paul Wouters 2014-12-04 draft-ietf-tcpm-accecn-reqs-07 -- kivinen@iki.fi From nobody Thu Dec 11 08:30:57 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A741A1F04; Thu, 11 Dec 2014 08:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 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, FREEMAIL_REPLY=1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FFJDHerbpRf; Thu, 11 Dec 2014 08:30:51 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A851A6FC7; Thu, 11 Dec 2014 08:30:50 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id p10so5307810pdj.27 for ; Thu, 11 Dec 2014 08:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:from:to:cc:subject:importance:date :in-reply-to:references:content-type; bh=U15brPKdTKReW0bg6UkYSbirEFmZfvASAbngRq3Y0Iw=; b=dHcNZeqEvmmaepYbzXANKbubHllXEyfdJqcDjsVbRBC3b69OVSSoQj43liyTNTo11E Wwa2PiG5+iXNHVE0bBGAa/gK2rhwGL39CUbWTqYjhx5ncsauOcx5f26n8fwHG7utWHxs d5b9IrbjaEdn0FGsJfBjscKvTAVjhLTC1fQ/96PWNDwsd0z325sW+IYkD0iBh5fmeeGp mN2wnYvFNPsRl24BBtnloqpT6c0IoSXuJ+CL1n0IWPKoMY32EJP+yg5W9AerOELkLahs jRChYik6WI/ok+EmOM7xweK6HXZhGTZ0dXc2ymm7vbZz4a6rX6iWO3nV8LvDsZleM32p qLPg== X-Received: by 10.68.208.65 with SMTP id mc1mr18274172pbc.111.1418315449657; Thu, 11 Dec 2014 08:30:49 -0800 (PST) Received: from MAGNUSDevbox2.ntdev.corp.microsoft.com ([2001:4898:80e8:ee31::2]) by mx.google.com with ESMTPSA id bn13sm1851535pdb.4.2014.12.11.08.30.47 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 11 Dec 2014 08:30:48 -0800 (PST) Message-ID: <5489c6b8.6d59460a.0f26.4799@mx.google.com> MIME-Version: 1.0 From: To: =?utf-8?Q?Yoav_Nir?= Importance: Normal Date: Thu, 11 Dec 2014 16:26:34 +0000 In-Reply-To: <715DF31C-F5BF-4DBC-8D0F-6595F7B1F692@gmail.com> References: , <715DF31C-F5BF-4DBC-8D0F-6595F7B1F692@gmail.com> Content-Type: multipart/alternative; boundary="_9B80DCDA-2DDE-40F1-A071-AC2F13C01694_" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/mg5JbPbPaw1ATvhfsJxkyFxGrxE Cc: =?utf-8?Q?The_IESG?= , "=?utf-8?Q?draft-josefsson-pkix-textual@tools.ietf.org?=" , "=?utf-8?Q?secdir@ietf.org?=" Subject: Re: [secdir] =?utf-8?q?Secdir_review_of_draft-josefsson-pkix-textual?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 16:30:53 -0000 --_9B80DCDA-2DDE-40F1-A071-AC2F13C01694_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" VGhhbmtzIFlvYXYsDQoNCkkgZG9u4oCZdCB3YW50IHRvIGNyZWF0ZSBhIGxvbmcgdGhyZWFkIGhl cmUsIGJ1dCBqdXN0IHRvIG5vdGUgbXkgdGhpbmtpbmcgb24gdGhlIHR3byBhc3BlY3RzIHlvdSBj b21tZW50IG9uOg0KDQpPbiB0aGUgZmlyc3Qgb25lLCBJTUhPIHdlIHNob3VsZG7igJl0IGludHJv ZHVjZSBuZXcgbGFuZ3VhZ2UgaW4gYWRkaXRpb24gdG8gMjExOS4gSWYgdGhlcmUgaXMgYSDigJxn b29kIGNhc2XigJ0gZm9yIHNheWluZyBwcmVmZXJyZWQsIHRoZW4gSSBhbHNvIHRoaW5rIHRoZXJl IGlzIGEgZ29vZCBjYXNlIGZvciBzYXlpbmcg4oCcU0hPVUxELuKAnQ0KDQpPbiB0aGUgLmNlciBh bmQgLmNydCwgSSBtYWludGFpbiB0aGF0IHRoZSBkb2N1bWVudCBzaG91bGQgc3RpY2sgdG8gd2hh dCBpdHMgcHVycG9zZSBpcywgd2hpY2ggaXMg4oCcdGV4dHVhbCBlbmNvZGluZ3Mgb2YgdGhlIFB1 YmxpYy1LZXkgSW5mcmFzdHJ1Y3R1cmUgWC41MDkgKFBLSVgpLCBQdWJsaWMtS2V5IENyeXB0b2dy YXBoeSBTdGFuZGFyZHMgKFBLQ1MpLCBhbmQgQ3J5cHRvZ3JhcGhpYyBNZXNzYWdlIFN5bnRheCAo Q01TKeKAnS4gSW50cm9kdWNpbmcgZGVwcmVjYXRpb25zIGZvciBmaWxlIGV4dGVuc2lvbnMgc2Vl bXMgbm90IG9ubHkgdG8gYmUgZmFyIGF3YXkgZnJvbSB0aGF0IGJ1dCBhbHNvIHdpdGhvdXQgdGhv dWdodC10aHJvdWdoIGNvbnNlcXVlbmNlcy4NCg0KDQoNCg0KDQoNClNlbnQgZnJvbSBXaW5kb3dz IE1haWwNCg0KDQoNCg0KDQpGcm9tOiBZb2F2IE5pcg0KU2VudDog4oCOV2VkbmVzZGF54oCOLCDi gI4z4oCOIOKAjkRlY2VtYmVy4oCOLCDigI4yMDE0IOKAjjA04oCOOuKAjjAxDQpUbzogTWFnbnVz IE55c3Ryw7ZtDQpDYzogc2VjZGlyQGlldGYub3JnLCBkcmFmdC1qb3NlZnNzb24tcGtpeC10ZXh0 dWFsQHRvb2xzLmlldGYub3JnLCBUaGUgSUVTRw0KDQoNCg0KDQpIaSBNYWdudXMNCg0KDQoNClth ZGRpbmcgSUVTR10NCg0KDQoNCg0KU2VlIGJlbG93DQoNCg0KDQoNCg0KT24gRGVjIDIsIDIwMTQs IGF0IDQ6MTkgUE0sIE1hZ251cyBOeXN0csO2bSA8bWFnbnVzbkBnbWFpbC5jb20+IHdyb3RlOg0K DQoNCg0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1 cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1 bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdy aXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJl Y3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2Ug Y29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCg0KDQoN Cg0KDQoNCg0KDQpUaGlzIG1lbW8gZG9jdW1lbnRzIHRleHR1YWwgZW5jb2RpbmdzIG9mIHZhcmlv dXMgd2VsbC1lc3RhYmxpc2hlZCBQS0ktcmVsYXRlZCBkYXRhIHN0cnVjdHVyZXMgYW5kIGZvcm1h dHMuIFRoZSBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBiZSBwdWJsaXNoZWQgYXMgYSBTdGFuZGFy ZHMtVHJhY2sgUkZDLg0KQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zOg0KDQpTZWN0aW9uIDUuMToN Cg0KDQogLSBGb3IgY2xhcml0eSBhbmQgY29tbW9uIGtleXdvcmQgdXNhZ2UsIHN1Z2dlc3QgcmVw bGFjaW5nICJUaGUgZW5jb2RlZCBkYXRhIE1VU1QgYmUgYSBCRVIgKERFUiBzdHJvbmdseSBwcmVm ZXJyZWQpIGVuY29kZWQgQVNOLjEuLi4iIHdpdGg6ICJUaGUgZW5jb2RlZCBkYXRhIE1VU1QgYmUg QkVSIGFuZCBTSE9VTEQgYmUgYSBERVIgZW5jb2RlZCBBU04uMS4uLiIgKEluIGZhY3QgdGhpcyBj b21tZW50IGdvZXMgZm9yIGFsbCBwbGFjZXMgd2hlcmUgeW91IGhhdmUgdGV4dCBsaWtlICJNVVNU IGJlIGEgQkVSIChERVIgW3N0cm9uZ2x5XSBwcmVmZXJyZWQiIC0gYmV0dGVyIHRvIHVzZSBlc3Rh Ymxpc2hlZCBSRkMgMjExOSBsYW5ndWFnZSkuDQoNCg0KDQoNCg0KSW4gZ2VuZXJhbCAodGhpcyBp cyBub3QgYSBoYXJkIGFuZCBmYXN0IHJ1bGUpIGEgU0hPVUxEIHNob3VsZCBjb21lIHdpdGggYW4g ZXhwbGFuYXRpb24gb2Ygd2hlbiBpdCBpc27igJl0IG5lZWRlZC4gVW5sZXNzIHdlIGhhdmUgYSBn b29kIGNhc2UgZm9yIHNheWluZyB3aGVuIGl04oCZcyBPSyB0byB1c2Ugbm9uLURFUiwgSeKAmWQg cmF0aGVyIHN0aWNrIHdpdGggdGhlIG5vbi0yMTE5IOKAnHByZWZlcuKAnS4NCg0KDQoNCg0KDQoN Cg0KLSBJIHdvbmRlciB3aHkgeW91IHN0YXRlICJQYXJzZXJzIGFyZSBOT1QgUkVDT01NRU5ERUQg dG8gdHJlYXQgIlg1MDkgQ0VSVElGSUNBVEUiIG9yICJYLjUwOSBDRVJUSUZJQ0FURSIgYXMgZXF1 aXZhbGVudCB0byAiQ0VSVElGSUNBVEUiLCBidXQgYSB2YWxpZCBleGNlcHRpb24gbWF5IGJlIGZv ciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSAocG90ZW50aWFsbHkgdG9nZXRoZXIgd2l0aCBhIHdh cm5pbmcpIiBzaW5jZSB0byBteSBrbm93bGVkZ2UsIHRoZXkgYWxsIHJlZmVyIHRvIHRoZSBzYW1l IHN0cnVjdHVyZSBhbmQgaW4gdGhlIHNwaXJpdCBvZiAic3RyaWN0IGluIGlzc3VhbmNlLCBnZW5l cm91cyBpbiByZWNlaXB0IiwgaXQgd291bGQgc2VlbSB0byBiZSBiZXR0ZXIgdG8gc3RhdGU6ICIi UGFyc2VycyBNQVkgdHJlYXQgLi4uIGFzIGVxdWl2YWxlbnQgdG8gIkNFUlRJRklDQVRFIiDigJwg Pw0KDQoNCg0KDQpJ4oCZbGwgbGVhdmUgdGhpcyB0byB0aGUgYXV0aG9ycyB0byBhbnN3ZXIuDQoN Cg0KDQoNCg0KDQoNCi0gSSBhbHNvIHdvbmRlciBhYm91dCB0aGUgd2FybmluZyBhYm92ZSBzaW5j ZSBpZiB0aGUgc3RydWN0dXJlIGluZGVlZCBkb2VzIHBhcnNlIGFzIGEgY2VydGlmaWNhdGUsIHdo YXQgdmFsdWUgd291bGQgdGhlIHdhcm5pbmcgYnJpbmcgKGFuZCB0byB3aG9tKT8NCg0KDQoNCg0K ZGl0dG8NCg0KDQoNCg0KDQpTZWN0aW9uIDUuMzoNCg0KDQpJIGRpc2FncmVlIHdpdGggdGhlIGRl cHJlY2F0aW9uIG9mIC5jZXIgaW4gZmF2b3Igb2YgLmNydC4gVGhlIC5jZXIgY29udmVudGlvbiBp cyB1c2VkIGJyb2FkbHkuIEkgd291bGQgc3VnZ2VzdCB1cGRhdGluZyB0aGUgdGV4dCB0byByZWNv bW1lbmQgdXNlIG9mIC5jcnQgT1IgLmNlci4gQmV0dGVyIHlldCwgcmVtb3ZlIHRoZSBzZWN0aW9u LCBzaW5jZSB0aGlzIGRvY3VtZW50IHNwZWNpZmljYWxseSBpcyBhYm91dCB0ZXh0dWFsIGVuY29k aW5ncyBhbmQgbm90IGZpbGUgZXh0ZW5zaW9uIG5hbWluZyBhbmQgeW91IGRvIG5vdCBkaXNjdXNz IGV4dGVuc2lvbiBuYW1pbmcgZWxzZXdoZXJlLg0KDQoNCg0KDQpJREsuIFRoZXNlIGZvcm1hdHMg YXJlIHVzZWQgbW9zdGx5IGluIGZpbGVzLCBhbmQgZGVzcGl0ZSB0d2VudHkgeWVhcnMgb2YgYXR0 ZW1wdHMsIGNsYXNzaWZpY2F0aW9uIGJ5IGV4dGVuc2lvbiBpcyBzdGlsbCB0aGUgbm9ybS4gLmNl ciBmaWxlcyBvZnRlbiBjb250YWluIGVpdGhlciBCRVIgb3IgYSB0ZXh0dWFsIHJlcHJlc2VudGF0 aW9uLCB3aGlsZSAuY3J0IHRlbmRzIHRvIG1vc3RseSBiZSB0ZXh0dWFsLiBJIGRvbuKAmXQgc2Vl IHdoeSB3ZSBzaG91bGRu4oCZdCBkb2N1bWVudCB0aGlzIGNvbnZlbnRpb24uDQoNCg0KDQoNCg0K U2VjdGlvbiA2Og0KU2FtZSBjb21tZW50cyBhcyBmb3IgU2VjdGlvbiA1LjEgYWJvdmUsIGJ1dCBm b3IgQ1JMcy4uLg0KDQoNCg0KU2VjdGlvbiA3Og0KU2FtZSBjb21tZW50IGFzIG15IGZpcnN0IGZv ciBTZWN0aW9uIDUuMS4gSSBub3RlIHRoYXQgeW91IGhhdmUgdGhlIHNhbWUgbGFuZ3VhZ2Ugd2l0 aCByZWdhcmRzIHRvIHBhcnNlciBmbGV4aWJpbGl0eSBoZXJlIHRoYXQgSSBoYXZlIHN1Z2dlc3Rl ZCBmb3IgU2VjdGlvbiA1LjEgYW5kIFNlY3Rpb24gNi4NCg0KDQoNClNlY3VyaXR5IENvbnNpZGVy YXRpb25zOg0KDQoNCk5vIHBhcnRpY3VsYXIgY29tbWVudHMuDQogDQoNCuKAlCBNYWdudXMNCg0K DQpZb2F2 --_9B80DCDA-2DDE-40F1-A071-AC2F13C01694_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" CjxodG1sPgo8aGVhZD4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJXaW5kb3dzIE1h aWwgMTcuNS45NjAwLjIwNjg5Ij4KPHN0eWxlIGRhdGEtZXh0ZXJuYWxzdHlsZT0idHJ1ZSI+PCEt LQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0b206 MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbCB7Cm1hcmdpbjowaW47Cm1hcmdpbi1ib3R0 b206LjAwMDFwdDsKfQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGxpLk1zb0xpc3RQYXJh Z3JhcGhDeFNwRmlyc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCAKcC5Nc29MaXN0 UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGRpdi5N c29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBs aS5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3Qg ewptYXJnaW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1h cmdpbi1sZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsK fQotLT48L3N0eWxlPjwvaGVhZD4KPGJvZHkgZGlyPSJsdHIiPgo8ZGl2IGRhdGEtZXh0ZXJuYWxz dHlsZT0iZmFsc2UiIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDYWxpYnJpJywgJ1Nl Z29lIFVJJywgJ01laXJ5bycsICdNaWNyb3NvZnQgWWFIZWkgVUknLCAnTWljcm9zb2Z0IEpoZW5n SGVpIFVJJywgJ01hbGd1biBHb3RoaWMnLCAnc2Fucy1zZXJpZic7Zm9udC1zaXplOjEycHQ7Ij48 ZGl2PlRoYW5rcyBZb2F2LDwvZGl2PjxkaXY+SSBkb27igJl0IHdhbnQgdG8gY3JlYXRlIGEgbG9u ZyB0aHJlYWQgaGVyZSwgYnV0IGp1c3QgdG8gbm90ZSBteSB0aGlua2luZyBvbiB0aGUgdHdvIGFz cGVjdHMgeW91IGNvbW1lbnQgb246PC9kaXY+PGRpdj5PbiB0aGUgZmlyc3Qgb25lLCBJTUhPIHdl IHNob3VsZG7igJl0IGludHJvZHVjZSBuZXcgbGFuZ3VhZ2UgaW4gYWRkaXRpb24gdG8gMjExOS4g SWYgdGhlcmUgaXMgYSZuYnNwO+KAnGdvb2QgY2FzZeKAnSBmb3Igc2F5aW5nIHByZWZlcnJlZCwg dGhlbiBJIGFsc28gdGhpbmsgdGhlcmUgaXMgYSBnb29kIGNhc2UgZm9yIHNheWluZyZuYnNwO+KA nFNIT1VMRC7igJ08L2Rpdj48ZGl2Pk9uIHRoZSAuY2VyIGFuZCAuY3J0LCBJIG1haW50YWluIHRo YXQgdGhlIGRvY3VtZW50IHNob3VsZCBzdGljayB0byB3aGF0IGl0cyBwdXJwb3NlIGlzLCB3aGlj aCBpcyZuYnNwO+KAnHRleHR1YWwgZW5jb2RpbmdzIG9mIHRoZSBQdWJsaWMtS2V5IEluZnJhc3Ry dWN0dXJlIFguNTA5IChQS0lYKSwgUHVibGljLUtleSBDcnlwdG9ncmFwaHkgU3RhbmRhcmRzIChQ S0NTKSwgYW5kIENyeXB0b2dyYXBoaWMgTWVzc2FnZSBTeW50YXggKENNUynigJ0uIEludHJvZHVj aW5nIGRlcHJlY2F0aW9ucyBmb3IgZmlsZSBleHRlbnNpb25zIHNlZW1zIG5vdCBvbmx5IHRvIGJl IGZhciBhd2F5IGZyb20gdGhhdCBidXQgYWxzbyB3aXRob3V0IHRob3VnaHQtdGhyb3VnaCBjb25z ZXF1ZW5jZXMuPGJyPjwvZGl2PjxkaXYgZGF0YS1zaWduYXR1cmVibG9jaz0idHJ1ZSI+PGRpdj48 YnI+PC9kaXY+PGRpdj5TZW50IGZyb20gV2luZG93cyBNYWlsPC9kaXY+PGRpdj48YnI+PC9kaXY+ PC9kaXY+PGRpdiBzdHlsZT0icGFkZGluZy10b3A6IDVweDsgYm9yZGVyLXRvcC1jb2xvcjogcmdi KDIyOSwgMjI5LCAyMjkpOyBib3JkZXItdG9wLXdpZHRoOiAxcHg7IGJvcmRlci10b3Atc3R5bGU6 IHNvbGlkOyI+PGRpdj48Zm9udCBmYWNlPSIgJ0NhbGlicmknLCAnU2Vnb2UgVUknLCAnTWVpcnlv JywgJ01pY3Jvc29mdCBZYUhlaSBVSScsICdNaWNyb3NvZnQgSmhlbmdIZWkgVUknLCAnTWFsZ3Vu IEdvdGhpYycsICdzYW5zLXNlcmlmJyIgc3R5bGU9J2xpbmUtaGVpZ2h0OiAxNXB0OyBsZXR0ZXIt c3BhY2luZzogMC4wMmVtOyBmb250LWZhbWlseTogIkNhbGlicmkiLCAiU2Vnb2UgVUkiLCAiTWVp cnlvIiwgIk1pY3Jvc29mdCBZYUhlaSBVSSIsICJNaWNyb3NvZnQgSmhlbmdIZWkgVUkiLCAiTWFs Z3VuIEdvdGhpYyIsICJzYW5zLXNlcmlmIjsgZm9udC1zaXplOiAxMnB0Oyc+PGI+RnJvbTo8L2I+ Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnluaXIuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX3BhcmVu dCI+WW9hdiBOaXI8L2E+PGJyPjxiPlNlbnQ6PC9iPiZuYnNwO+KAjldlZG5lc2RheeKAjiwg4oCO M+KAjiDigI5EZWNlbWJlcuKAjiwg4oCOMjAxNCDigI4wNOKAjjrigI4wMTxicj48Yj5Ubzo8L2I+ Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm1hZ251c25AZ21haWwuY29tIiB0YXJnZXQ9Il9wYXJlbnQi Pk1hZ251cyBOeXN0csO2bTwvYT48YnI+PGI+Q2M6PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpz ZWNkaXJAaWV0Zi5vcmciIHRhcmdldD0iX3BhcmVudCI+c2VjZGlyQGlldGYub3JnPC9hPiwgPGEg aHJlZj0ibWFpbHRvOmRyYWZ0LWpvc2Vmc3Nvbi1wa2l4LXRleHR1YWxAdG9vbHMuaWV0Zi5vcmci IHRhcmdldD0iX3BhcmVudCI+ZHJhZnQtam9zZWZzc29uLXBraXgtdGV4dHVhbEB0b29scy5pZXRm Lm9yZzwvYT4sIDxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIiB0YXJnZXQ9Il9wYXJlbnQi PlRoZSBJRVNHPC9hPjwvZm9udD48L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGRpcj0i Ij5IaSBNYWdudXM8ZGl2Pjxicj48L2Rpdj48ZGl2PlthZGRpbmcgSUVTR108L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PlNlZSBiZWxvdzwvZGl2PjxkaXY+PGJyPjxkaXY+PGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGRpdj5PbiBEZWMgMiwg MjAxNCwgYXQgNDoxOSBQTSwgTWFnbnVzIE55c3Ryw7ZtICZsdDs8YSBocmVmPSJtYWlsdG86bWFn bnVzbkBnbWFpbC5jb20iIHRhcmdldD0iX3BhcmVudCI+bWFnbnVzbkBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPjxkaXY+ PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPkkgaGF2ZSByZXZpZXdlZCB0 aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MgCm9uZ29p bmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5 IHRoZSA8c3Bhbj5JRVNHPC9zcGFuPi4KIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmlt YXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSAKYXJlYSBkaXJlY3RvcnMuIERv Y3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgCmNvbW1lbnRz IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxkaXYgY2xhc3M9ImdtYWls X2V4dHJhIj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9Imx0ciI+PGRpdiBzdHls ZT0nZm9udC1mYW1pbHk6ICJDYWxpYnJpIiwiU2Vnb2UgVUkiLCJNZWlyeW8iLCJNaWNyb3NvZnQg WWFIZWkgVUkiLCJNaWNyb3NvZnQgSmhlbmdIZWkgVUkiLCJNYWxndW4gR290aGljIiwic2Fucy1z ZXJpZiI7JyBkaXI9Imx0ciI+PGRpdj48ZGl2Pjxmb250Pjxicj48L2ZvbnQ+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXY+PGZv bnQ+VGhpcyBtZW1vIGRvY3VtZW50cyB0ZXh0dWFsIGVuY29kaW5ncyBvZiB2YXJpb3VzIHdlbGwt ZXN0YWJsaXNoZWQgUEtJLXJlbGF0ZWQgZGF0YSBzdHJ1Y3R1cmVzIGFuZCBmb3JtYXRzLiBUaGUg ZG9jdW1lbnQgaXMgaW50ZW5kZWQgdG8gYmUgcHVibGlzaGVkIGFzIGEgU3RhbmRhcmRzLVRyYWNr IFJGQy48YnI+Q29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zOjwvZm9udD48YnI+PGJyPlNlY3Rpb24g NS4xOjxicj48L2Rpdj48ZGl2PiZuYnNwOy0gRm9yIGNsYXJpdHkgYW5kIGNvbW1vbiBrZXl3b3Jk IHVzYWdlLCBzdWdnZXN0IHJlcGxhY2luZyAiVGhlIGVuY29kZWQgZGF0YSBNVVNUIGJlIGEgQkVS IChERVIgc3Ryb25nbHkgcHJlZmVycmVkKSBlbmNvZGVkIEFTTi4xLi4uIiB3aXRoOiAiVGhlIGVu Y29kZWQgZGF0YSBNVVNUIGJlIEJFUiBhbmQgU0hPVUxEIGJlIGEgREVSIGVuY29kZWQgQVNOLjEu Li4iIChJbiBmYWN0IHRoaXMgY29tbWVudCBnb2VzIGZvciBhbGwgcGxhY2VzIHdoZXJlIHlvdSBo YXZlIHRleHQgbGlrZSAiTVVTVCBiZSBhIEJFUiAoREVSIFtzdHJvbmdseV0gcHJlZmVycmVkIiAt IGJldHRlciB0byB1c2UgZXN0YWJsaXNoZWQgUkZDIDIxMTkgbGFuZ3VhZ2UpLjxicj48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5J biBnZW5lcmFsICh0aGlzIGlzIG5vdCBhIGhhcmQgYW5kIGZhc3QgcnVsZSkgYSBTSE9VTEQgc2hv dWxkIGNvbWUgd2l0aCBhbiBleHBsYW5hdGlvbiBvZiB3aGVuIGl0IGlzbuKAmXQgbmVlZGVkLiBV bmxlc3Mgd2UgaGF2ZSBhIGdvb2QgY2FzZSBmb3Igc2F5aW5nIHdoZW4gaXTigJlzIE9LIHRvIHVz ZSBub24tREVSLCBJ4oCZZCByYXRoZXIgc3RpY2sgd2l0aCB0aGUgbm9uLTIxMTkg4oCccHJlZmVy 4oCdLjwvZGl2Pjxicj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4t Ym90dG9tOiAwcHg7Ij48ZGl2PjxkaXYgZGlyPSJsdHIiPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh Ij48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdj4tIEkgd29uZGVyIHdoeSB5b3Ugc3RhdGUg IlBhcnNlcnMgYXJlIE5PVAogICBSRUNPTU1FTkRFRCB0byB0cmVhdCAiWDUwOSBDRVJUSUZJQ0FU RSIgb3IgIlguNTA5IENFUlRJRklDQVRFIiBhcwogICBlcXVpdmFsZW50IHRvICJDRVJUSUZJQ0FU RSIsIGJ1dCBhIHZhbGlkIGV4Y2VwdGlvbiBtYXkgYmUgZm9yCiAgIGJhY2t3YXJkcyBjb21wYXRp YmlsaXR5IChwb3RlbnRpYWxseSB0b2dldGhlciB3aXRoIGEgd2FybmluZykiIHNpbmNlIHRvIG15 IGtub3dsZWRnZSwgdGhleSBhbGwgcmVmZXIgdG8gdGhlIHNhbWUgc3RydWN0dXJlIGFuZCBpbiB0 aGUgc3Bpcml0IG9mICJzdHJpY3QgaW4gaXNzdWFuY2UsIGdlbmVyb3VzIGluIHJlY2VpcHQiLCBp dCB3b3VsZCBzZWVtIHRvIGJlIGJldHRlciB0byBzdGF0ZTogIiJQYXJzZXJzIE1BWSB0cmVhdCAu Li4gYXMgZXF1aXZhbGVudCB0byAiQ0VSVElGSUNBVEUiIOKAnCA/PGJyPjwvZGl2PjwvZGl2Pjwv ZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj5J4oCZbGwgbGVhdmUg dGhpcyB0byB0aGUgYXV0aG9ycyB0byBhbnN3ZXIuPC9kaXY+PGRpdj48YnI+PGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PGRpdj48ZGl2IGRp cj0ibHRyIj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi PjxkaXY+LSBJIGFsc28gd29uZGVyIGFib3V0IHRoZSB3YXJuaW5nIGFib3ZlIHNpbmNlIGlmIHRo ZSBzdHJ1Y3R1cmUgaW5kZWVkIGRvZXMgcGFyc2UgYXMgYSBjZXJ0aWZpY2F0ZSwgd2hhdCB2YWx1 ZSB3b3VsZCB0aGUgd2FybmluZyBicmluZyAoYW5kIHRvIHdob20pPzxicj48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+ZGl0dG88L2Rpdj48 ZGl2Pjxicj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9t OiAwcHg7Ij48ZGl2PjxkaXYgZGlyPSJsdHIiPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj5TZWN0 aW9uIDUuMzo8YnI+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPkkgZGlzYWdyZWUgd2l0 aCB0aGUgZGVwcmVjYXRpb24gb2YgLmNlciBpbiBmYXZvciBvZiAuY3J0LiBUaGUgLmNlciBjb252 ZW50aW9uIGlzIHVzZWQgYnJvYWRseS4gSSB3b3VsZCBzdWdnZXN0IHVwZGF0aW5nIHRoZSB0ZXh0 IHRvIHJlY29tbWVuZCB1c2Ugb2YgLmNydCBPUiAuY2VyLiBCZXR0ZXIgeWV0LCByZW1vdmUgdGhl IHNlY3Rpb24sIHNpbmNlIHRoaXMgZG9jdW1lbnQgc3BlY2lmaWNhbGx5IGlzIGFib3V0IHRleHR1 YWwgZW5jb2RpbmdzIGFuZCBub3QgZmlsZSBleHRlbnNpb24gbmFtaW5nIGFuZCB5b3UgZG8gbm90 IGRpc2N1c3MgZXh0ZW5zaW9uIG5hbWluZyBlbHNld2hlcmUuPGJyIGNsZWFyPSJhbGwiPjwvZGl2 PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj5JREsuIFRoZXNlIGZvcm1h dHMgYXJlIHVzZWQgbW9zdGx5IGluIGZpbGVzLCBhbmQgZGVzcGl0ZSB0d2VudHkgeWVhcnMgb2Yg YXR0ZW1wdHMsIGNsYXNzaWZpY2F0aW9uIGJ5IGV4dGVuc2lvbiBpcyBzdGlsbCB0aGUgbm9ybS4g LmNlciBmaWxlcyBvZnRlbiBjb250YWluIGVpdGhlciBCRVIgb3IgYSB0ZXh0dWFsIHJlcHJlc2Vu dGF0aW9uLCB3aGlsZSAuY3J0IHRlbmRzIHRvIG1vc3RseSBiZSB0ZXh0dWFsLiBJIGRvbuKAmXQg c2VlIHdoeSB3ZSBzaG91bGRu4oCZdCBkb2N1bWVudCB0aGlzIGNvbnZlbnRpb24uPC9kaXY+PGRp dj48YnI+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog MHB4OyI+PGRpdj48ZGl2IGRpcj0ibHRyIj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+U2VjdGlv biA2Ojxicj5TYW1lIGNvbW1lbnRzIGFzIGZvciBTZWN0aW9uIDUuMSBhYm92ZSwgYnV0IGZvciBD UkxzLi4uPGJyPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+U2VjdGlvbiA3Ojxi cj5TYW1lIGNvbW1lbnQgYXMgbXkgZmlyc3QgZm9yIFNlY3Rpb24gNS4xLiBJIG5vdGUgdGhhdCB5 b3UgaGF2ZSB0aGUgc2FtZSBsYW5ndWFnZSB3aXRoIHJlZ2FyZHMgdG8gcGFyc2VyIGZsZXhpYmls aXR5IGhlcmUgdGhhdCBJIGhhdmUgc3VnZ2VzdGVkIGZvciBTZWN0aW9uIDUuMSBhbmQgU2VjdGlv biA2Ljxicj48YnI+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPlNlY3VyaXR5IENvbnNp ZGVyYXRpb25zOjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+Tm8gcGFydGljdWxh ciBjb21tZW50cy48YnI+Jm5ic3A7PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSI+4oCU IE1hZ251czwvZGl2Pgo8L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJyPjwvZGl2Pjxk aXY+WW9hdjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxicj48L2Rpdj48L2Rpdj48L2Rpdj4KPC9ib2R5 Pgo8L2h0bWw+Cg== --_9B80DCDA-2DDE-40F1-A071-AC2F13C01694_-- From nobody Fri Dec 12 09:15:45 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22C71A1BAA; Fri, 12 Dec 2014 09:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGQhRvjJltq8; Fri, 12 Dec 2014 09:15:37 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1191A6FBE; Fri, 12 Dec 2014 09:15:36 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id wo20so9122507obc.13 for ; Fri, 12 Dec 2014 09:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EEIaENm6yJIOWBbCBrv03oIzjU/IjeiHC4ZY9d1mVy0=; b=CzQJqhTZ8MGMWOQn5Ep6xVIl9rS9yoVUJBvw8Oot3uCm2gpJOsIOhTsDC9ZFczUKaL LYzioO+hrkE7MZNRwwvtI0JixhAJimImH0cEg/LNIL/6952pKNFyfauGGvdhZKx/9I+i N0GjxGMs0K5A+bAZMslK2cG05mcT7xhTKJK52ajYp5cvWXZZv5b36RxOYartcOPygn4S Ug8kzTQxpqy3H97A/GdwN1eoklbWnBId9oXeSXqZ2uUTMmbA1bZKDc6Qp0gbqFElAHkO DX+lC98lk81/EvzcspESe/DLMz10NyP7prZ7YUxRocpXskDmJuc6qvBqsvLPamRi6HrX vaog== X-Received: by 10.60.67.7 with SMTP id j7mr7417487oet.80.1418404536145; Fri, 12 Dec 2014 09:15:36 -0800 (PST) Received: from ?IPv6:2602:306:3406:4f00:1111:5e16:86f:8e4d? ([2602:306:3406:4f00:1111:5e16:86f:8e4d]) by mx.google.com with ESMTPSA id rh7sm787096oeb.0.2014.12.12.09.15.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 09:15:35 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: "Adam W. Montville" In-Reply-To: Date: Fri, 12 Dec 2014 11:15:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6A8E604C-DC8C-410E-A2F4-79B401FD0515@gmail.com> References: <6BAB7B9A-1A70-4957-ADC2-1836F22A4219@cisco.com> To: "Zhangdacheng (Dacheng)" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ppw7Y8Es8nNHpZCr7XnjEmAF608 Cc: The IESG , "draft-ietf-mile-enum-reference-format.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mile-enum-reference-format-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 17:15:40 -0000 Hi Dacheng, Thank you for your review=E2=80=A6responses inline. Adam > On Dec 9, 2014, at 9:50 PM, Zhangdacheng (Dacheng) = wrote: >=20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > This document is establishing a container for publicly available = enumeration values to be included in an IODEF [IODEF] document. Several = questions about the proposed solution are listed as follows.=20 > 1) In this specification, a given enumeration is uniquely = identified by the specIndex attribute. However the usage of ID is not = clearly introduced. In the security consideration section, it is = mentioned that the miss-match between the index and the ID may cause = problem. Could you please give me some clues? The enumeration specification is identified, so that the ID expressed in = a given IODEF (note v2 not v1) is understood. The ID is a reference to = a set of further information to be acquired through other means. As an = example, discovered vulnerabilities are often given a Common = Vulnerability Enumeration (CVE) identifier. This ID would be in the = element, and the specification for that ID=E2=80=99s = format is what is pointed to by the IANA registry. =20 > 2) Where is section 2.2? Good catch, thank you. > 3) In the abstract, it is stated that "This memo establishes a = stand-alone data format to include both the external specification and = specific enumeration value,. However, I didn't find the specific = enumeration value in the example provided in Section 2.1: > " > > CXI-1234-XYZ > > http://cxi.example.com > Foo > > =E2=80=9C That sentence should probably read (emphasis added): This memo = establishes a stand-alone data format to include both the external = specification and specific enumeration *identification* value. > Cheers >=20 > Dacheng >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Fri Dec 12 13:23:50 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B64F1A8A48; Fri, 12 Dec 2014 13:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hAjZDeVDJyo; Fri, 12 Dec 2014 13:23:41 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2571A8A39; Fri, 12 Dec 2014 13:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4906; q=dns/txt; s=iport; t=1418419421; x=1419629021; h=from:to:subject:date:message-id:mime-version; bh=tAA2hJ82WMK9m29RuQv0M3avNScgLnq8oBbvvlwghY4=; b=KObOjfFruWVR+MggnpBKDmLiZbheilQEZUgNb7AuMuiVjZ9E2bSzD/03 L6qWG8JGhjKa5RdPquyHJt55/zGUXBMqCnT/iTBJ2PUz8iZMmC6m3XD4U 0WB6yQV3lS0PnYHflxX2dTSDamZH0yHPyNWQBhfdPe2MHsXGZVuwuCJ7Z I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroFAAtci1StJV2Z/2dsb2JhbABZgkNDUlyDAshtAhx3FgEBAQEBfYQOAQQjCl4BDB4gAgQwJgEEARqIJMIRljUBAQEBAQEBAQEBAQEBAQEBAQEBGY9BgyAugRMFjX+aJiKDbIIzfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,566,1413244800"; d="scan'208,217";a="376787672" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 12 Dec 2014 21:23:40 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBCLNe3P028286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Dec 2014 21:23:40 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.7]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 15:23:40 -0600 From: "Shaun Cooley (shcooley)" To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-dawkins-iesg-one-or-more.all@tools.ietf.org" Thread-Topic: secdir review of draft-dawkins-iesg-one-or-more-04 Thread-Index: AdAWUadqekYtCSLlT9ybK5OU8684aQ== Date: Fri, 12 Dec 2014 21:23:39 +0000 Message-ID: <187A7B1DA239514F9146FC78B19AADE350329B7D@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.187.21] Content-Type: multipart/alternative; boundary="_000_187A7B1DA239514F9146FC78B19AADE350329B7Dxmbalnx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/76k0DBT9IbtW18kqcqZneqTKfgg Subject: [secdir] secdir review of draft-dawkins-iesg-one-or-more-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 21:23:42 -0000 --_000_187A7B1DA239514F9146FC78B19AADE350329B7Dxmbalnx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBw cmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4g IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVu dHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoaXMgZG9jdW1l bnQgY2hhbmdlcyB0aGUgbnVtYmVyIG9mIEFyZWEgRGlyZWN0b3JzIGluIGFuIElFVEYgQXJlYSBm cm9tIOKAnG9uZSBvciB0d2/igJ0gdG8g4oCcb25lIG9yIG1vcmXigJ0uICBUaGlzIGRvY3VtZW50 IGhhcyBubyBkaXJlY3QgaW50ZXJuZXQgc2VjdXJpdHkgaW1wbGljYXRpb25zLg0KDQpJIGNvbnNp ZGVyIHRoaXMgZG9jdW1lbnQgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLg0KDQotU2hhdW4NCg== --_000_187A7B1DA239514F9146FC78B19AADE350329B7Dxmbalnx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2 M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0 aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElF VEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4mbmJzcDsgVGhlc2UgY29t bWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3Vy aXR5IGFyZWEgZGlyZWN0b3JzLiZuYnNwOyBEb2N1bWVudA0KIGVkaXRvcnMgYW5kIFdHIGNoYWly cyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNh bGwgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZG9jdW1lbnQgY2hhbmdl cyB0aGUgbnVtYmVyIG9mIEFyZWEgRGlyZWN0b3JzIGluIGFuIElFVEYgQXJlYSBmcm9tIOKAnG9u ZSBvciB0d2/igJ0gdG8g4oCcb25lIG9yIG1vcmXigJ0uJm5ic3A7IFRoaXMgZG9jdW1lbnQgaGFz IG5vIGRpcmVjdCBpbnRlcm5ldCBzZWN1cml0eSBpbXBsaWNhdGlvbnMuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgY29uc2lkZXIgdGhpcyBkb2N1bWVudCByZWFkeSBmb3IgcHVibGljYXRpb24u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1TaGF1bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_187A7B1DA239514F9146FC78B19AADE350329B7Dxmbalnx10ciscoc_-- From nobody Sat Dec 13 08:01:29 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399091A01F4 for ; Sat, 13 Dec 2014 08:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UH-CyjEbjtL6 for ; Sat, 13 Dec 2014 08:01:25 -0800 (PST) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.70.6]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94ED81A01D6 for ; Sat, 13 Dec 2014 08:01:25 -0800 (PST) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id B3390D4B5C84; Sat, 13 Dec 2014 10:01:24 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 8FDDBD4B5BCD for ; Sat, 13 Dec 2014 10:01:24 -0600 (CST) Received: from [96.231.218.201] (port=62997 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xzp8F-0003ij-Bs for secdir@ietf.org; Sat, 13 Dec 2014 10:01:23 -0600 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Dec 2014 11:01:21 -0500 References: <7E631EA0-8577-4616-A885-331078D93115@ieca.com> To: secdir@ietf.org Message-Id: <51EBFE8D-74AE-4B84-B855-1D7733AA43AF@ieca.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.218.201 X-Exim-ID: 1Xzp8F-0003ij-Bs X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [96.231.218.201]:62997 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/JbHAmWquXJc85Tf6lduBnQbx0SY Subject: [secdir] Fwd: secdir review of draft-ietf-ianaplan-icg-response-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 16:01:27 -0000 And I managed to leave secdir off as a recipient. spt Begin forwarded message: > From: Sean Turner > Subject: secdir review of draft-ietf-ianaplan-icg-response-06 > Date: December 13, 2014 at 10:25:49 EST > To: draft-ietf-ianaplan-icg-response@tools.ietf.org, The IESG = , ietf@ietf.org >=20 > Do not be alarmed. I have reviewed this document as part of the = security > directorate=92s 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 > Summary: No security or privacy issues that I can see, but I do have > a couple of nits. >=20 > 0) General: >=20 > I guess it wasn=92t clear to me that the response will take on the = form of the > RFC or if the text not proceeded by =93>>>=94 in the main body will be = returned > in some of other form. >=20 > 1) Sec 1: >=20 > There=92s a pointer to ICG=92s charter and the RFP shouldn=92t we also = have a > pointer to the NTIA announcement: >=20 > = http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transitio= n-key-internet-domain-name-functions >=20 > 2) Abstract contains: >=20 > The IETF community is invited to > comment and propose changes to this document. >=20 > I guess this makes it crystal clear that folks could comment on the = draft, > but this sentence should be struck before going to the RFC editor. >=20 > 3) Sec I (section #s refer to RFP sections): Missing word >=20 > Missing =93the=94? r/on iana.org/on the iana.org >=20 > The IETF > community presently accesses the protocol parameter registries via > references based on iana.org domain name, and makes use of the term > "IANA" in the protocol parameter registry processes [RFC5226]. >=20 > 4) Sec I: missing =93.=94 at the end of the sentence: >=20 >>>> A description of any overlaps or interdependencies between your >>>> IANA requirements and the functions required by other customer >>>> communities >=20 > 5) Sec I: Overlap >=20 > I assume the overlap here is with the other two communities listed in > this RFP (i.e., names & numbers) and not the IEEE or W3C? >=20 > 6) Sec I: "RIR System"? >=20 > Through the IANA protocol > parameters registries, the IETF delegates unicast IP address and > AS number ranges to the RIR system [RFC7020],[RFC7249]. >=20 > I went and looked in RFCs 7020 and 7249 and could find no reference > to an =93RIR system=94 I found Internet Numbers Registry System was = that > what you=92re referring to? >=20 > 7) Sec I: Missing question/response? >=20 > In addition to the four bullets there is also this paragraph in the = RFP: >=20 > If your community relies on any other IANA service or activity > beyond the scope of the IANA functions contract, you may describe > them here. In this case please also describe how the service or > activity should be addressed by the transition plan. >=20 > And because the intro of the RFP says: >=20 > The IANA Stewardship Transition Coordination Group (ICG) seeks > complete formal responses to this RFP through processes which are to > be convened =85 >=20 > Don=92t we need to include a response to this question even if the = answer > is =93none=94 or =93see above=94? >=20 > 8) Sec II.A: r/the/The & r/all/All >=20 > IETF Response: the protocol parameters registries. >=20 > IETF Response: all policy sources relating to the protocol = parameters > registry are affected. >=20 > 9) Sec IV: Missing question? >=20 > The =93Risks=94 paragraph in the RFP includes the following question: >=20 > Description of how long the proposals in Section III are expected to > take to complete, and any intermediate milestones that may occur > before they are completed. >=20 > Does it need to be included along with the bullets in Sec IV? >=20 > 10) Sec V: missing question/response: >=20 > There are five bullets in sV this one is omitted: =20 >=20 > o The proposal must not replace the NTIA role with a government-led > or an inter-governmental organization solution. >=20 > Should we say something about our proposal not replacing > NTIA with a government-y organizational solution? I mean I know it=92s > obvious to you and me, but maybe being explicit here is better. >=20 > 11) Sec VI: add IETF LC? >=20 > I assume you=92re going to add a link to the IETF LC and maybe the = ballots > to the end of the list of actions. >=20 > 12) s3 (IANA Considerations) >=20 > r/is a response a request for/is a response to a request for >=20 > Cheers, >=20 > spt From nobody Sat Dec 13 10:25:52 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5773E1A1AA5 for ; Sat, 13 Dec 2014 10:25:49 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RanYDf-jQM8 for ; Sat, 13 Dec 2014 10:25:47 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF471A0103 for ; Sat, 13 Dec 2014 10:25:47 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id dc16so6612897qab.11 for ; Sat, 13 Dec 2014 10:25:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=OgRxAIr2vC+UHTrl3OpqesKDFcd9BYAItfD6vw3qxlg=; b=Wavu7ux/BCE9oR/qOb/iuVFQG4JUY0RCaHnlEbqIJyBPazF5HblJh49OM/ckJ377aJ D9SDU8Oz9lgD3GKAuVUZ24cLLqvhb7FIk+YwUj34CJnN2+27sC2Que1kAEAQAQ/2Fj5d Lb9ZtmuLm92ZSPq4aji21JkTHOenWVNvreu4/5tToCZl2OJ8Lo5prVaq3L2UnLWOB9Hb VX4q43GeXw7h/QnHExx3FomdZR1anOlSa4uR3D3Drn2MJZntNaJUPvU/9/MekE+HBf/I W3RIbz4kBmRnvRgjlqrZqqSoQQMQy8KspBUG9wuV1uskZqyLbGQ545FrUViD9/T0ego0 c3SQ== X-Gm-Message-State: ALoCoQliptYVFAKMM3Ela3/D4XkZiTqTFQO1hRFPCMISUs3Qr4BSAshD8EXuf9bB+V1ZMfYdmrjn X-Received: by 10.224.88.8 with SMTP id y8mr40844188qal.47.1418495146845; Sat, 13 Dec 2014 10:25:46 -0800 (PST) Received: from [192.168.2.58] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id v5sm5153301qaj.2.2014.12.13.10.25.39 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Dec 2014 10:25:46 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Sat, 13 Dec 2014 13:25:33 -0500 From: Carl Wallace To: , , Message-ID: Thread-Topic: secdir review of draft-ietf-json-text-sequence-11 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/NmKp0rCFVD4Sa1Oo9OiwoyG6UKk Subject: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 18:25:49 -0000 I have reviewed this document as part of the security directorate=E2=80=99s ongoing effort to review all IETF documents being processed by the IESG. These comments were written 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 describes a means of encoding and parsing arbitrarily large sequences of JSON texts. The document claims no new security considerations beyond those in RFC 7159. I have some concern that the addition of a LF by the JSON text sequence encoder that is not removed by the JSON text sequence parser has the potential to break detached JSON web signatures that cover JSON text sequence elements. A few general comments and questions are below: - In the abstract of version 11 the hex value for ASCII line feeds was changed to 0x1E from 0x0A. - In section 2.1, shouldn=E2=80=99t possible-JSON be defined as *(not-RS) to allo= w for parsing of ? - Section 2.3 should clarify that malformed JSON text sequences are also not fatal (I.e., arriving at an RS without having seen a LF). - The second paragraph of Section 2.3 suggests that an incremental JSON parser may be used across content from multiple sequence elements. The ABNF for encoders does not seem to support this. - The last sentence of the second paragraph in Section 2.4 is a bit confusing. If a JSON-text has no trailing ws and the LF from the JSON text sequence is used to match the ws rule, should this be reported as a malformed JSON text sequence, a malformed JSON-text or neither? - In section 2.4, the =E2=80=9Cparsers=E2=80=9D referenced in the second and third paragraphs should be qualified as JSON text sequence parsers or JSON parsers. =20 - In section 2.4, assuming the parser is a JSON text sequence parser, why is the MUST drop in the third paragraph necessary given potential use of incremental parsers mentioned in section 2.3 and later in 2.4? How do you distinguish between a =E2=80=9Cnon-self-delimited top-level value=E2=80=9D and a piece = of JSON-text being parsed incrementally? - The examples for possibly truncated JSON texts seem to assume that the LF appended by a JSON text sequence encoder is absent. How would a truncated JSON text within a properly delimited JSON text sequence be detected? For example, if a component feeding JSON text elements to a JSON text sequence encoder failed where the JSON text sequence encoder succeeds, the result would be a truncated JSON text within a valid JSON text sequence. I realize the ABNF should preclude encoding invalid JSON texts but there is no text that instructs encoders to fail when invalid JSON texts are detected. - The failure to address the LF in the parser section seems like it could cause problems for re-encoding. What would prevent accumulation of LF characters as a JSON text sequence was encoded, parsed, re-encoded, re-parsed and re-encoded? From nobody Sat Dec 13 11:29:28 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC261A1B36 for ; Sat, 13 Dec 2014 11:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTFpvfdLcJ3V for ; Sat, 13 Dec 2014 11:29:21 -0800 (PST) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [67.18.36.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894461A1AF6 for ; Sat, 13 Dec 2014 11:29:21 -0800 (PST) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id EB4C7767DAE38; Sat, 13 Dec 2014 13:29:20 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id D9BD9767DAE18 for ; Sat, 13 Dec 2014 13:29:20 -0600 (CST) Received: from [96.231.218.201] (port=63359 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XzsNT-0000rk-Tq; Sat, 13 Dec 2014 13:29:20 -0600 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 13 Dec 2014 14:29:18 -0500 To: draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org, secdir@ietf.org, The IESG , ietf@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.218.201 X-Exim-ID: 1XzsNT-0000rk-Tq X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [96.231.218.201]:63359 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Cy13MkPMP8dRcC8xkOHW-oAWpjM Subject: [secdir] secdir review of draft-ietf-mpls-lsp-ping-relay-reply X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 19:29:24 -0000 Do not be alarmed. I have reviewed this document as part of the security directorate=92s 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. Version: 06 Summary: Ready with some non-security/non-privacy nits. Ping mechanisms always give me the heebie-jeebies [1] because of the security concerns associated with them (i.e., DoS,=20 spoofing/hijacking/etc., and unauthorized disclosure). This document specifies an extension to the existing ECHO mechanism in RFC 4379 and it does nothing to address these concerns in fact it increases the concerns wrt DoS. *BUT* it rightly points this increase exposure out in the security considerations section. It provides remediation techniques similar to those specified in RFC 4379: rate limit and validate source against access list. This draft, unlike RFC 4379, does recommend that operators wishing to not disclose their nodes blank the address out in the TLV. This draft also refers to RFC 4379 for additional security considerations. WARNING - questions and nits follow: s3 - 1st paragraph: Relayed Echo Reply =93replaces=94 Echo Reply - does = this mean you=92re deprecating the use of =93Echo Reply=94? s4.1: Is the outermost label allowed to be set to 255 to support the =93ping=94 mode or must it always be set to 1, 2, etc. to support = =93traceroute" mode - as described in RFC 4379 s4.3? I know s5 is just an example but it really looks like this extension is just supposed to be for fault isolation. s4.1 - last paragraph: Does the next initiator put it=92s address in the = stack before or after the previous initiator? I assume it=92s after, but I = maybe missed that part? Would be good to state that explicitly. Cheers, spt [1] http://en.wikipedia.org/wiki/Heebie-jeebies_(idiom)= From nobody Sun Dec 14 22:30:10 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A0C1A1A00; Sun, 14 Dec 2014 22:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVbFAo9yC-zz; Sun, 14 Dec 2014 22:29:59 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589A41A0363; Sun, 14 Dec 2014 22:29:59 -0800 (PST) Received: from [192.168.1.12] (unknown [112.205.93.13]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B4D1D1801590; Mon, 15 Dec 2014 07:29:55 +0100 (CET) Message-ID: <548E7FDF.80801@pi.nu> Date: Mon, 15 Dec 2014 14:29:51 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sean Turner , draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org, secdir@ietf.org, The IESG References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7ftXCowZjOhDcVlZHox5qxyNILo Subject: Re: [secdir] secdir review of draft-ietf-mpls-lsp-ping-relay-reply X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 06:30:02 -0000 Sean, We had a "wrinkle" on this :( ! Two of the authors discovered (very late) something that needs to be addressed. I asked the AD to send the ducment back to the working group for "more work". I hope it be a smooth process, and that we'll get the document timely back on track again. Anyhow, I expect that the authors takes care of your comments during the "more work" process. /Loa On 2014-12-14 03:29, Sean Turner wrote: > Do not be alarmed. I have reviewed this document as part of the > security directorates ongoing effort to review all IETF documents being > processed by the IESG. These comments were written with the intent > of improving security requirements and considerations in IETF drafts. > Comments not addressed in last call may be included in AD reviews > during the IESG review. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Version: 06 > Summary: Ready with some non-security/non-privacy nits. > > Ping mechanisms always give me the heebie-jeebies [1] > because of the security concerns associated with them (i.e., DoS, > spoofing/hijacking/etc., and unauthorized disclosure). This document > specifies an extension to the existing ECHO mechanism in RFC 4379 > and it does nothing to address these concerns in fact it increases the > concerns wrt DoS. *BUT* it rightly points this increase exposure out in > the security considerations section. It provides remediation techniques > similar to those specified in RFC 4379: rate limit and validate source > against access list. This draft, unlike RFC 4379, does recommend that > operators wishing to not disclose their nodes blank the address out in > the TLV. This draft also refers to RFC 4379 for additional security > considerations. > > WARNING - questions and nits follow: > > s3 - 1st paragraph: Relayed Echo Reply replaces Echo Reply - does this > mean youre deprecating the use of Echo Reply? > > s4.1: Is the outermost label allowed to be set to 255 to support the > ping mode or must it always be set to 1, 2, etc. to support traceroute" > mode - as described in RFC 4379 s4.3? I know s5 is just an example > but it really looks like this extension is just supposed to be for fault > isolation. > > s4.1 - last paragraph: Does the next initiator put its address in the stack > before or after the previous initiator? I assume its after, but I maybe > missed that part? Would be good to state that explicitly. > > Cheers, > spt > > [1] http://en.wikipedia.org/wiki/Heebie-jeebies_(idiom) > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Dec 15 16:01:18 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708661A6FFA; Mon, 15 Dec 2014 16:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNxur-QIL01V; Mon, 15 Dec 2014 16:01:15 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 202691A6FDA; Mon, 15 Dec 2014 16:01:15 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id A706C350078; Mon, 15 Dec 2014 16:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=J0s/jYB9l1MLyeeLtqQ2bZIQcYM=; b=RbbipLUPzgz gSePFjRlyedKSgz2i5qhH49Iw6Y2EAa+3HHUAZopJmp9pRtazKOoNBEhbOdrsGVt MglpcHWaHwzAO5PNdNAPl75YxlF+ksh6hMsMSpcpoN2a1pJijmFXPBJ3OKVnr+wu YZiAH7owsw4oqHMALt3ce9/uJFgFovBQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id 38A1A35005B; Mon, 15 Dec 2014 16:01:14 -0800 (PST) Date: Mon, 15 Dec 2014 18:01:13 -0600 From: Nico Williams To: Carl Wallace Message-ID: <20141216000109.GP3241@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/nZWXALzIt4TFN1kIOP6IkqbzxIU Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 00:01:16 -0000 On Sat, Dec 13, 2014 at 01:25:33PM -0500, Carl Wallace wrote: > I have reviewed this document as part of the security directorate=E2=80= =99s > ongoing effort to review all IETF documents being processed by the IESG= . Thanks. > This document describes a means of encoding and parsing arbitrarily lar= ge > sequences of JSON texts. The document claims no new security > considerations beyond those in RFC 7159. I have some concern that the Though it turns out that RFC7159's security considerations section was probably too brief. Anyways. > addition of a LF by the JSON text sequence encoder that is not removed = by > the JSON text sequence parser has the potential to break detached JSON = web > signatures that cover JSON text sequence elements. A few general comme= nts > and questions are below: That's a good point. Signing individual JSON text sequence elements is outside the scope of this document. Either a complete sequence is signed, or individual texts are signed with a wrapper. I wouldn't recommend transferring a sequence of texts and a parallel sequence of signatures, say. > - In the abstract of version 11 the hex value for ASCII line feeds was > changed to 0x1E from 0x0A. Yeah, a widely noted typo :/ > - In section 2.1, shouldn=E2=80=99t possible-JSON be defined as *(not-R= S) to allow > for parsing of ? The preceding 1*RS in JSON-sequence takes care of that, although that assumes greedy ABNF matching (RFC5234 does not speak to greediness). > - Section 2.3 should clarify that malformed JSON text sequences are als= o > not fatal (I.e., arriving at an RS without having seen a LF). That's covered in detail in section 2.4. I wouldn't want to replicate any part of 2.4 in 2.3. > - The second paragraph of Section 2.3 suggests that an incremental JSON > parser may be used across content from multiple sequence elements. The > ABNF for encoders does not seem to support this. Are you thinking of a a sequence like ... being parsed as two JSON texts? Or are you thinking of a ? The latter must yield a parse error from the JSON text parser. As to the former... I think I'd thought about it and left it as-is, though I can't recall why, with the security considerations text about smuggling being sufficient (except it's not quite). How about this new text: After reading and parsing a JSON text, the sequence parser MUST skip to the RS byte following the JSON text (or terminate if at end of input). And in section 3: JSON text sequences like are sequences of one text, not two. JSON text sequence parser implementations may emit the first JSON text, but should detect and log such sequences. > - The last sentence of the second paragraph in Section 2.4 is a bit > confusing. If a JSON-text has no trailing ws and the LF from the JSON t= ext > sequence is used to match the ws rule, should this be reported as a > malformed JSON text sequence, a malformed JSON-text or neither? Neither. The LF doubles as the ws that makes the number/boolean/null parse correctly, and as the LF needed for the JSON text sequence. This is also true for string/array/object, but since those are self-delimited the presence of the LF is less critical. Section 2.4 is really a) justification for the LF, b) a warning to implementors not to include a bug where permissive parsing (not insisting on the trailing LF) results in very incorrect results when the top-level value type is a number (or boolean, or null). > - In section 2.4, the =E2=80=9Cparsers=E2=80=9D referenced in the secon= d and third > paragraphs should be qualified as JSON text sequence parsers or JSON > parsers. =20 When used without a qualifier the intended meaning is "JSON text sequence parser", but that's a mouthful. I may add text in section 1.1 about this. > - In section 2.4, assuming the parser is a JSON text sequence parser, w= hy > is the MUST drop in the third paragraph necessary given potential use o= f > incremental parsers mentioned in section 2.3 and later in 2.4? How do y= ou > distinguish between a =E2=80=9Cnon-self-delimited top-level value=E2=80= =9D and a piece of > JSON-text being parsed incrementally? See above. In my implementation I check that the last byte consumed by the [incremental] JSON text parser was a whitespace character. > - The examples for possibly truncated JSON texts seem to assume that th= e > LF appended by a JSON text sequence encoder is absent. How would a > truncated JSON text within a properly delimited JSON text sequence be > detected? [...] Well, if the LF is present then it's not truncated. E.g., the number in 1 may have been truncated, but the number in 123 cannot have been. > [...] For example, if a component feeding JSON text elements to a J= SON > text sequence encoder failed where the JSON text sequence encoder > succeeds, the result would be a truncated JSON text within a valid JSON > text sequence. I realize the ABNF should preclude encoding invalid JSON > texts but there is no text that instructs encoders to fail when invalid > JSON texts are detected. Yes, a JSON text sequence encoder should also encode the texts themselves. When it doesn't the result may be garbage, but the JSON text sequence parser can cope with such garbage. > - The failure to address the LF in the parser section seems like it cou= ld > cause problems for re-encoding. What would prevent accumulation of LF > characters as a JSON text sequence was encoded, parsed, re-encoded, > re-parsed and re-encoded? There's no requirement that parsing and re-encoding be the identity function. There's no such requirement for JSON texts, therefore there can't be for JSON text sequences. This comes up a lot for JSON implementations. Users often want the result of parsing and re-encoding to leave numbers as-is, object [key] names in the same order as in the input, indentation/whitespace the same, and so on. The answer is generally "sorry, that's ETOOHARD". (There are implementations that preserve object name/value insertion/ parse order. But keeping track of encoded number form along with parsed numbers can be a headache. Besides, implementations often lose number precision/range.) Nico --=20 From nobody Tue Dec 16 04:51:49 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101171A701F for ; Tue, 16 Dec 2014 04:51:44 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro-BXkLyzxK3 for ; Tue, 16 Dec 2014 04:51:41 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE1D1A1AE0 for ; Tue, 16 Dec 2014 04:51:40 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id k15so9644281qaq.10 for ; Tue, 16 Dec 2014 04:51:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=xb5E/juJFelmc/UcIGVuVT3Q7B/7PoW27v5LkYyaWTg=; b=V8yVqHQjCrspBOYZ3HC434SDZ8w4IG5Ji2e4xUzkP8U6lKaHLPU3sz3+1pXGXpQGQb 8+P5dz3vduLoY9eGbIz+V7/GSrV+h32Inh+2z1rWrVhCmd6L7p7+VZAFSlS+a5mn7fw/ i5um4VSDrckzmG48O/RfT5xt0flsDbnutu0GHQ2SA2jh8fyaUKb7WMh+nQI40W85I1Kz kdfdw8IFIQ65BeGnhj1gvCVFLn4ooNSKIhxJKcHuT/XHHSVZX4q/jaJBy/HwuzM6KoLy RT3VtzE527uSxzix50E7c1+CaW4NvShUSQ+UD/ZEBrIpFMzQw6uhYvW+YqrzGBbnpEUi wpiw== X-Gm-Message-State: ALoCoQlIr+2Mo6wNhduzWBpsfMjGzvg1ujAHTGtBEn0WEYqWey9ie5w9CagvghRqpehOGhBbcqiS X-Received: by 10.224.169.2 with SMTP id w2mr64388796qay.33.1418734300014; Tue, 16 Dec 2014 04:51:40 -0800 (PST) Received: from [192.168.2.39] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id 89sm635064qgz.39.2014.12.16.04.51.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Dec 2014 04:51:39 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Tue, 16 Dec 2014 07:51:32 -0500 From: Carl Wallace To: Nico Williams Message-ID: Thread-Topic: [secdir] secdir review of draft-ietf-json-text-sequence-11 References: <20141216000109.GP3241@localhost> In-Reply-To: <20141216000109.GP3241@localhost> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Wz-RUiSxvzK41vBy1O-WEQOFZ3A Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 12:51:44 -0000 Inline... On 12/15/14, 7:01 PM, "Nico Williams" wrote: > >> This document describes a means of encoding and parsing arbitrarily >>large >> sequences of JSON texts. The document claims no new security >> considerations beyond those in RFC 7159. I have some concern that the > >Though it turns out that RFC7159's security considerations section was >probably too brief. Anyways. Seems a good place to augment since you have noticed shortcomings. > >> addition of a LF by the JSON text sequence encoder that is not removed >>by >> the JSON text sequence parser has the potential to break detached JSON >>web >> signatures that cover JSON text sequence elements. A few general >>comments >> and questions are below: > >That's a good point. Signing individual JSON text sequence elements is >outside the scope of this document. Either a complete sequence is >signed, or individual texts are signed with a wrapper. I wouldn't >recommend transferring a sequence of texts and a parallel sequence of >signatures, say. It=E2=80=99s probably worth stating up front the process of encoding a JSON text sequence alters the JSON text sequence elements and that signing individual elements is outside the scope. > >> - In section 2.1, shouldn=E2=80=99t possible-JSON be defined as *(not-RS) to >>allow >> for parsing of ? > >The preceding 1*RS in JSON-sequence takes care of that, although that >assumes greedy ABNF matching (RFC5234 does not speak to greediness). OK. > >> - Section 2.3 should clarify that malformed JSON text sequences are also >> not fatal (I.e., arriving at an RS without having seen a LF). > >That's covered in detail in section 2.4. I wouldn't want to replicate >any part of 2.4 in 2.3. I don=E2=80=99t recall seeing any mention of malformed JSON text sequences. I think you either get to a next or end of the stream. > >> - The second paragraph of Section 2.3 suggests that an incremental JSON >> parser may be used across content from multiple sequence elements. The >> ABNF for encoders does not seem to support this. > >Are you thinking of a a sequence like > ... being parsed as two JSON texts? I was thinking more like . > >Or are you thinking of a ? > >The latter must yield a parse error from the JSON text parser. > >As to the former... I think I'd thought about it and left it as-is, >though I can't recall why, with the security considerations text about >smuggling being sufficient (except it's not quite). > >How about this new text: > > After reading and parsing a JSON text, the sequence parser MUST skip > to the RS byte following the JSON text (or terminate if at end of > input). I think this text would be a nice addition. I noticed the lack of calling out "read until end if no " but it seemed implied. > >And in section 3: > > JSON text sequences like are > sequences of one text, not two. JSON text sequence parser > implementations may emit the first JSON text, but should detect and > log such sequences. > >> - The last sentence of the second paragraph in Section 2.4 is a bit >> confusing. If a JSON-text has no trailing ws and the LF from the JSON >>text >> sequence is used to match the ws rule, should this be reported as a >> malformed JSON text sequence, a malformed JSON-text or neither? > >Neither. The LF doubles as the ws that makes the number/boolean/null >parse correctly, and as the LF needed for the JSON text sequence. Is this doubling simply trying to save a byte or something else? In any case, the JSON text sequence parser cannot know whether the LF is serving as the ws for the entire number that was to have been encoded or a truncated value. It seems better for the JSON text sequence encoder to encode what it gets as a sequence, the JSON text sequence parser to remove what the encoder added with the JSON parser left to figure out what to do with the =E2=80=9Cpossible JSON=E2=80=9D and/or error indicating a sequence parsing err= or. =20 Reporting possible truncation would be just as easy when finding a 123 instead of 123. If the only purpose of the is to attempt to serve in place of missing , simply parsing from to seems fine. Given a missing is not the only form of possible truncation, it doesn=E2=80=99t buy much to add the . > >This is also true for string/array/object, but since those are >self-delimited the presence of the LF is less critical. > >Section 2.4 is really > >a) justification for the LF, > >b) a warning to implementors not to include a bug where permissive > parsing (not insisting on the trailing LF) results in very incorrect > results when the top-level value type is a number (or boolean, or > null). As noted above, the warning about possibly truncated JSON text is necessary, not sure about a). > >> - In section 2.4, assuming the parser is a JSON text sequence parser, >>why >> is the MUST drop in the third paragraph necessary given potential use of >> incremental parsers mentioned in section 2.3 and later in 2.4? How do >>you >> distinguish between a =E2=80=9Cnon-self-delimited top-level value=E2=80=9D and a pie= ce >>of >> JSON-text being parsed incrementally? > >See above. In my implementation I check that the last byte consumed by >the [incremental] JSON text parser was a whitespace character. > >> - The examples for possibly truncated JSON texts seem to assume that the >> LF appended by a JSON text sequence encoder is absent. How would a >> truncated JSON text within a properly delimited JSON text sequence be >> detected? [...] > >Well, if the LF is present then it's not truncated. E.g., the number in >1 may have been truncated, but the number in 123 cannot >have been. I think this is where we differ. How can the JSON text sequence decoder know whether or not 123 was the complete value that should have been encoded in the sequence? The component that generated 123 may have been intended to pass 1234 before it failed. In this case, the JSON text sequence encoder is not doing a favor by supplying the as the . I would prefer for the JSON text sequence encoder to not alter what it is encoding by lending the to the element. > >> [...] For example, if a component feeding JSON text elements to a >>JSON >> text sequence encoder failed where the JSON text sequence encoder >> succeeds, the result would be a truncated JSON text within a valid JSON >> text sequence. I realize the ABNF should preclude encoding invalid JSON >> texts but there is no text that instructs encoders to fail when invalid >> JSON texts are detected. > >Yes, a JSON text sequence encoder should also encode the texts >themselves. When it doesn't the result may be garbage, but the JSON >text sequence parser can cope with such garbage. This gets at my question about the ABNF not supporting incremental encoding. An incremental snip may not parse (for any number of reasons) so the sequence encoder has a bit of state to maintain. In any case, calling out this =E2=80=9Cshould also encode" for encoders would be a helpful addition. This probably causes some interop problems worth mentioning where one encoder just encodes what it is handed without re-encoding, possibly in support of incremental encoding, while another (subsequently used) encoder does try to parse each element. > >> - The failure to address the LF in the parser section seems like it >>could >> cause problems for re-encoding. What would prevent accumulation of LF >> characters as a JSON text sequence was encoded, parsed, re-encoded, >> re-parsed and re-encoded? > >There's no requirement that parsing and re-encoding be the identity >function. There's no such requirement for JSON texts, therefore there >can't be for JSON text sequences. > >This comes up a lot for JSON implementations. Users often want the >result of parsing and re-encoding to leave numbers as-is, object [key] >names in the same order as in the input, indentation/whitespace the >same, and so on. The answer is generally "sorry, that's ETOOHARD". > >(There are implementations that preserve object name/value insertion/ >parse order. But keeping track of encoded number form along with parsed >numbers can be a headache. Besides, implementations often lose number >precision/range.) OK, though as noted above I still don=E2=80=99t see the need for adding the in the encoder without removing it in the corresponding parser. From nobody Tue Dec 16 08:32:49 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47C31A1BEC; Tue, 16 Dec 2014 08:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkqnXX6kmgFl; Tue, 16 Dec 2014 08:32:43 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 97FD51A1BE7; Tue, 16 Dec 2014 08:32:43 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 5E16720047B89; Tue, 16 Dec 2014 08:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=4hMu9oTSxBLkrgbUDDoOaLHHQ20=; b=iGEsr2CRJCo FRJs9Xv3yOZWF+Lhyiaba3QQNogeZ8PKqcxWFqbQVQ6xXtvJG+UQiue1TZxejmPZ Czz3sy/1+cBH7Uz9VHQv9qT74YYFrFV3tp0uJ8x7kv6frx0tkFyU9NTDquSGsDuK gYfTEULVcr9nn3Yt5Jx0I9rWoTtafCYs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id E95AA20047B88; Tue, 16 Dec 2014 08:32:42 -0800 (PST) Date: Tue, 16 Dec 2014 10:32:42 -0600 From: Nico Williams To: Carl Wallace Message-ID: <20141216163238.GT3241@localhost> References: <20141216000109.GP3241@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xRAOppTow83YEjiHEm5ztOtusp8 Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:32:44 -0000 On Tue, Dec 16, 2014 at 07:51:32AM -0500, Carl Wallace wrote: > On 12/15/14, 7:01 PM, "Nico Williams" wrote: > > > >> This document describes a means of encoding and parsing arbitrarily > >>large > >> sequences of JSON texts. The document claims no new security > >> considerations beyond those in RFC 7159. I have some concern that t= he > > > >Though it turns out that RFC7159's security considerations section was > >probably too brief. Anyways. >=20 > Seems a good place to augment since you have noticed shortcomings. Indeed. > >> [...] > >That's a good point. Signing individual JSON text sequence elements i= s > >outside the scope of this document. Either a complete sequence is > >signed, or individual texts are signed with a wrapper. I wouldn't > >recommend transferring a sequence of texts and a parallel sequence of > >signatures, say. >=20 > It=E2=80=99s probably worth stating up front the process of encoding a = JSON text > sequence alters the JSON text sequence elements and that signing > individual elements is outside the scope. OK, that will be section 3 (security considerations text), something like: Parsing and re-encoding a JSON text sequence need not produce the same sequence of octets. Do not rely on being able to reproduce the same inputs to a cryptographic integrity protection function. > >> - Section 2.3 should clarify that malformed JSON text sequences are = also > >> not fatal (I.e., arriving at an RS without having seen a LF). > > > >That's covered in detail in section 2.4. I wouldn't want to replicate > >any part of 2.4 in 2.3. >=20 > I don=E2=80=99t recall seeing any mention of malformed JSON text sequen= ces. I > think you either get to a next or end of the stream. Section 2.3 actually says "malformed" in its first sentence. It mentions truncation only as an example of why a JSON text might be malformed, in the second sentent. There is also mention of malformed JSON texts in section 2.4 (explaining why 'true' must not be produce upon merely consuming the 'e' in it, as the next octet might not be a ws, nor RS). Here's the proposed change: OLD: 2.3. Incomplete JSON texts are not fatal NEW: 2.3. Incomplete or malformed JSON texts are not fatal (and s/textm/text,/) > >> - The second paragraph of Section 2.3 suggests that an incremental J= SON > >> parser may be used across content from multiple sequence elements. = The > >> ABNF for encoders does not seem to support this. > > > >Are you thinking of a a sequence like > > ... being parsed as two JSON texts? >=20 > I was thinking more like character>. The ABNF for encoding assumes proper operation, yes. The parser ABNF takes care of malformed JSON texts. This may be a simplification, but I think it's a useful one. > >Or are you thinking of a ? > > > >The latter must yield a parse error from the JSON text parser. > > > >As to the former... I think I'd thought about it and left it as-is, > >though I can't recall why, with the security considerations text about > >smuggling being sufficient (except it's not quite). > > > >How about this new text: > > > > After reading and parsing a JSON text, the sequence parser MUST ski= p > > to the RS byte following the JSON text (or terminate if at end of > > input). >=20 > I think this text would be a nice addition. I noticed the lack of calli= ng > out "read until end if no " but it seemed implied. OK. > [extensive discussion of the LF elided] > > OK, though as noted above I still don=E2=80=99t see the need for adding= the > in the encoder without removing it in the corresponding parser. There is no need to remove it in the sequence parser, though the sequence parser may do it. The sequence parser need only reject top-level number/true/false/null values whose text did not end in a whitespace. A sequence parser could do this by insisting that the sequence element end in an LF, and it can remove the trailing LF as well as leaving it in, as the trailing LF's presence (or absence) does not affect the validity of the JSON text to be parsed. Adding the LF in the sequence encoder does not hurt, since all JSON texts can end with arbitrary amounts of ws. It merely helps delimit sequence elements, both to ensure that top-level numbers/true/false/null are delimited, and to help keep lines shorter for users using $PAGER and $EDITOR to view JSON text sequences. Delimiting otherwise non-self- delimiting texts is an important function. Nico --=20 From nobody Tue Dec 16 09:20:53 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1EE1A6FFC for ; Tue, 16 Dec 2014 09:20:49 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl_PAS7vhKgm for ; Tue, 16 Dec 2014 09:20:44 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5DC1A7001 for ; Tue, 16 Dec 2014 09:20:14 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id q108so8475785qgd.34 for ; Tue, 16 Dec 2014 09:20:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=0fxKMhit1l919aKpJsfmon/veFkEGA5Jc+XiShoO8Qg=; b=bo99zwlA08kgT9nEzm0+ryvT9xAk6bxfeNpvYoUhIBP0qtAa1vhB5Aq0RPSVg4OXF8 SLVuH2Wni8Kk4xgicFCOpzUcvXsgglwMojCk3voeskEgaAGamhJb57o10gTgZXVgCsR7 E1PZbUvIL6o3El84QaOToCno95kJi0RRkY2MXVATlr7IsTu/tGyTN4Cx/9451MyaN/Bp azKY+9L7ULk3gQm1HdU2f7QuMXFgS2yg48hurCjrgwap7Q2w2P0BUTG5+uyOob92khhq 5RzFfNcdifKTDgAm9r7YTq2qo9buypknnuaNW0Ka20WO+PiCRD+g0jRkvl490n1pF839 d9Qg== X-Gm-Message-State: ALoCoQmd/6kBjE9PAFnP61bKWC3ginYZx1o1khrPGH7FOiPFnIJrWF13jxd1nJTDwtjTbGUXPt8u X-Received: by 10.224.7.197 with SMTP id e5mr67068908qae.71.1418750413411; Tue, 16 Dec 2014 09:20:13 -0800 (PST) Received: from [192.168.2.39] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id r16sm1364509qay.10.2014.12.16.09.20.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Dec 2014 09:20:12 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Tue, 16 Dec 2014 12:20:08 -0500 From: Carl Wallace To: Nico Williams Message-ID: Thread-Topic: [secdir] secdir review of draft-ietf-json-text-sequence-11 References: <20141216000109.GP3241@localhost> <20141216163238.GT3241@localhost> In-Reply-To: <20141216163238.GT3241@localhost> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Y6lnDL-KtKm1g-GaEEhf4wTT8SU Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:20:49 -0000 On 12/16/14, 11:32 AM, "Nico Williams" wrote: > >> >> [...] >> >That's a good point. Signing individual JSON text sequence elements is >> >outside the scope of this document. Either a complete sequence is >> >signed, or individual texts are signed with a wrapper. I wouldn't >> >recommend transferring a sequence of texts and a parallel sequence of >> >signatures, say. >>=20 >> It=E2=80=99s probably worth stating up front the process of encoding a JSON te= xt >> sequence alters the JSON text sequence elements and that signing >> individual elements is outside the scope. > >OK, that will be section 3 (security considerations text), something >like: > > Parsing and re-encoding a JSON text sequence need not produce the > same sequence of octets. Do not rely on being able to reproduce the > same inputs to a cryptographic integrity protection function. If supporting signing is not important to anyone, OK. This seems like a significant sacrifice, especially when positioned against the benefit of adding but not removing s. > >> >> - Section 2.3 should clarify that malformed JSON text sequences are >>also >> >> not fatal (I.e., arriving at an RS without having seen a LF). >> > >> >That's covered in detail in section 2.4. I wouldn't want to replicate >> >any part of 2.4 in 2.3. >>=20 >> I don=E2=80=99t recall seeing any mention of malformed JSON text sequences. I >> think you either get to a next or end of the stream. > >Section 2.3 actually says "malformed" in its first sentence. It >mentions truncation only as an example of why a JSON text might be >malformed, in the second sentent. I am making a distinction between failure to parse a JSON text and failure to parse a JSON text sequence. I think the text only addresses the former. >> >> [extensive discussion of the LF elided] How can a decoder know that 123 was what the originator intended and not something that was terminated by the text sequence encoder? The originator may have intended 1234. There seems to be some assumption that the supplier of JSON text may fail to self-delimit but would not fail to supply the full value. It=E2=80=99s a contrive= d example, but how should an incremental JSON parser handle texts returned from a parser operating on the sequence: 1234? Would it be two values 123 and 4 or one value 1234? Why is it not be preferable to report an error here 123 instead of trying to auto-terminate it when encoding the sequence? >> >> OK, though as noted above I still don=E2=80=99t see the need for adding the >> in the encoder without removing it in the corresponding parser. > >There is no need to remove it in the sequence parser, though the >sequence parser may do it. The sequence parser need only reject >top-level number/true/false/null values whose text did not end in a >whitespace. A sequence parser could do this by insisting that the >sequence element end in an LF, and it can remove the trailing LF as well >as leaving it in, as the trailing LF's presence (or absence) does not >affect the validity of the JSON text to be parsed. Is this universally true where JSON text is incrementally packaged into a text sequence? > >Adding the LF in the sequence encoder does not hurt, since all JSON >texts can end with arbitrary amounts of ws. It merely helps delimit >sequence elements, both to ensure that top-level numbers/true/false/null >are delimited, and to help keep lines shorter for users using $PAGER and >$EDITOR to view JSON text sequences. > >Delimiting otherwise non-self- delimiting texts is an important >function. I guess we just disagree on whether the text sequence encoder is necessarily in a position to terminate data that may be incrementally supplied or incompletely supplied by a caller and whether or not this important function should be allocated to the caller instead of to the JSON text sequence encoder. One alternative would be to add a only when a non-self-delimited text is passed to a non-incremental encoder, then encode that altered value into the sequence (and terminate all sequence elements with only). > >Nico >--=20 From nobody Tue Dec 16 09:48:49 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005E11A7020; Tue, 16 Dec 2014 09:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJNJ8j3u1fIi; Tue, 16 Dec 2014 09:48:37 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9FB1A702F; Tue, 16 Dec 2014 09:48:35 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 1516B20058D84; Tue, 16 Dec 2014 09:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=Krfdi5Gck6GwvsAxfzsdGuuaWuE=; b=Uj+41RhOHrr Tj6b922wSXg+yyljT+BXqZ30SAH/TEQvYj+b1mgW+BBQYxSo1cKx+pVdH9WdR4o+ hpd5jM+27EVeyUYf0VtFycR+yc99YpnhYaKNTEqj8yzMAv+hYP33fO89LKhn3NV5 GreDBRu1Ie2lOXItI8PxKNud/nhtc1pI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id A26C420058D82; Tue, 16 Dec 2014 09:48:34 -0800 (PST) Date: Tue, 16 Dec 2014 11:48:34 -0600 From: Nico Williams To: Carl Wallace Message-ID: <20141216174829.GZ3241@localhost> References: <20141216000109.GP3241@localhost> <20141216163238.GT3241@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8hzjqa5x66_3uhgQbuicK8GRTK4 Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:48:39 -0000 On Tue, Dec 16, 2014 at 12:20:08PM -0500, Carl Wallace wrote: > On 12/16/14, 11:32 AM, "Nico Williams" wrote: > >OK, that will be section 3 (security considerations text), something > >like: > > > > Parsing and re-encoding a JSON text sequence need not produce the > > same sequence of octets. Do not rely on being able to reproduce th= e > > same inputs to a cryptographic integrity protection function. >=20 > If supporting signing is not important to anyone, OK. This seems like a > significant sacrifice, especially when positioned against the benefit o= f > adding but not removing s. Supporting validation of signed sequences by first re-encoding the sequence is absolutely not a goal. This is almost dicta for all encodings of any messages. We found out long ago that it doesn't work when the encoding does have a canonical form (and even when it does but it's just not used by the signer). > >Section 2.3 actually says "malformed" in its first sentence. It > >mentions truncation only as an example of why a JSON text might be > >malformed, in the second sentent. >=20 > I am making a distinction between failure to parse a JSON text and fail= ure > to parse a JSON text sequence. I think the text only addresses the form= er. The whole section is about JSON text parse errors not being fatal for sequence parsing. I don't understand the objection. Perhaps if you propose text I will? > >> > >> [extensive discussion of the LF elided] >=20 > How can a decoder know that 123 was what the originator > intended and not something that was terminated by the text sequence > encoder? The originator may have intended 1234. There > seems to be some assumption that the supplier of JSON text may fail to > self-delimit but would not fail to supply the full value. It=E2=80=99s = a contrived > example, but how should an incremental JSON parser handle texts returne= d > from a parser operating on the sequence: 1234? > Would it be two values 123 and 4 or one value 1234? Why is it not be > preferable to report an error here 123 instead of trying to > auto-terminate it when encoding the sequence? The assumption is that the "process" writing the sequence will properly encode the sequence elements, and will write the sequence correctly. There is no assumption about atomic completion of the write. There is an assumption that incomplete writes will be truncated from some arbitrary point in that byte sequence to the end of it (that is, bytes will not be dropped from the middle or beginning). The concerns about truncation spring from limitations of POSIX write semantics, particularly O_APPEND writes. Applications may have to use writev() or else marshall the into a buffer prior to calling write(). These details are out of scope. Applications will have to synchronize if they use write() to write the RS, then an incremental JSON text encoder that may call write() multiple times, then again a write() to write the LF. This too is out of scope. A paragraph of text about these assumptions may be warranted, but I really don't want to have any references to POSIX and so on. I think the need for a modicum of atomicity (that which POSIX write semantics provide) should be evident to implementors. > >> OK, though as noted above I still don=E2=80=99t see the need for add= ing the > >> in the encoder without removing it in the corresponding parser. > > > >There is no need to remove it in the sequence parser, though the > >sequence parser may do it. The sequence parser need only reject > >top-level number/true/false/null values whose text did not end in a > >whitespace. A sequence parser could do this by insisting that the > >sequence element end in an LF, and it can remove the trailing LF as we= ll > >as leaving it in, as the trailing LF's presence (or absence) does not > >affect the validity of the JSON text to be parsed. >=20 > Is this universally true where JSON text is incrementally packaged into= a > text sequence? See above. > > > >Adding the LF in the sequence encoder does not hurt, since all JSON > >texts can end with arbitrary amounts of ws. It merely helps delimit > >sequence elements, both to ensure that top-level numbers/true/false/nu= ll > >are delimited, and to help keep lines shorter for users using $PAGER a= nd > >$EDITOR to view JSON text sequences. > > > >Delimiting otherwise non-self- delimiting texts is an important > >function. >=20 > I guess we just disagree on whether the text sequence encoder is > necessarily in a position to terminate data that may be incrementally > supplied or incompletely supplied by a caller and whether or not this > important function should be allocated to the caller instead of to the > JSON text sequence encoder. One alternative would be to add a onl= y Of course a properly functioning encoder on a properly function system is in a position to terminate each element. How can this be in doubt? A sequence encoder might write() RS, then invoke an incremental JSON text encoder to encode and write() the JSON text, then finally when the JSON text encoder completes its task, the sequence encoder write()s the LF. The sequence encoder can also marshall the whole thing into a buffer and write() that. Part of the point of JSON text sequences is to permit online processing of large data sets without requiring a streaming JSON text parser (which is not the same as an incremental parser). That point also applies to encoding: if the sequence elements are small enough to fit into memory and be parsed non-incrementally, then they also necessarily meet similar constraints on the encoder side. The only way to screw this up is when breaking down the process of writing a sequence into a non-atomic sequence of operations that race in a multi-process/threaded writer. The details of that problem and how to avoid it are clearly out of scope for this document. > when a non-self-delimited text is passed to a non-incremental encoder, > then encode that altered value into the sequence (and terminate all > sequence elements with only). The RS/LF bracketing was the result of lengthy discussions on the JSON WG list. The RS/LF bracketing design should not be reconsidered at this time unless you have a security concern that cannot be addressed otherwise. I reject the concern about validation of signatures via the use of re-encoded sequences (see above and earlier) -- it is commonly accepted and strongly recommended practice that signatures should be validated over what is signed, then and only then (after the signature is validated successfully) should the payload be parsed. If you have any other security concerns relating to the LF, let's hear them. Nico --=20 From nobody Tue Dec 16 10:47:06 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA071ACDC0 for ; Tue, 16 Dec 2014 10:47:02 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4X9thXv8QaN for ; Tue, 16 Dec 2014 10:47:00 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682781ACDBB for ; Tue, 16 Dec 2014 10:47:00 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id r5so10648927qcx.41 for ; Tue, 16 Dec 2014 10:46:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=zdHgQM3WoeZ4pOzubuF8zVdaaJg9nXRdJC/frCaCEpg=; b=al0u310OIsacTGNhzEYGN+XBYEidolt5kmjH+ql5R3qhFpKNm8OfMcMAcJanUZDDdt PzwAlYC8HTEhvvkbOe6/vtkZpETm0ujFj35goBW5cc6OYSJhJ/PaiD2qfwa3b2sjcloA Anndn9K79VaplsQwWg6/8P9XOzX2HTn50JDEMPM3muKd1iLfxHGDgra806Ho8lwXTJQ9 kQvsAa2LLpePLIqf28VLtOETVT5fLu4mlBxHmwwqYjoq+sMJm+hF4bih1jxIm5uNzFRQ RjJGaqwLBr1JcUy8pCjq6mK2vM/KgRw4C3Ewbgz1Tc70S+llIPabB8I1zMSIwPCjorue wkZA== X-Gm-Message-State: ALoCoQkzj13leK03KXynSliun2h3Lz1j6r0PXrlg1OjNW9sV6vLXLryQPsOXCnAqt5Xsrhee6tc5 X-Received: by 10.140.85.203 with SMTP id n69mr4625364qgd.78.1418755619294; Tue, 16 Dec 2014 10:46:59 -0800 (PST) Received: from [192.168.2.39] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id a9sm1586750qgf.7.2014.12.16.10.46.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Dec 2014 10:46:58 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Tue, 16 Dec 2014 13:46:52 -0500 From: Carl Wallace To: Nico Williams Message-ID: Thread-Topic: [secdir] secdir review of draft-ietf-json-text-sequence-11 References: <20141216000109.GP3241@localhost> <20141216163238.GT3241@localhost> <20141216174829.GZ3241@localhost> In-Reply-To: <20141216174829.GZ3241@localhost> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Pze0r21jbx_LcFmzNQQiBEIxx8I Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 18:47:02 -0000 Inline... On 12/16/14, 12:48 PM, "Nico Williams" wrote: >On Tue, Dec 16, 2014 at 12:20:08PM -0500, Carl Wallace wrote: >> On 12/16/14, 11:32 AM, "Nico Williams" wrote: >> >OK, that will be section 3 (security considerations text), something >> >like: >> > >> > Parsing and re-encoding a JSON text sequence need not produce the >> > same sequence of octets. Do not rely on being able to reproduce the >> > same inputs to a cryptographic integrity protection function. >>=20 >> If supporting signing is not important to anyone, OK. This seems like a >> significant sacrifice, especially when positioned against the benefit of >> adding but not removing s. > >Supporting validation of signed sequences by first re-encoding the >sequence is absolutely not a goal. Re-encoding is not the point. The value parsed from the sequence has an extra relative to what was passed in and would thus break a signature generated on the original value. I don=E2=80=99t think there=E2=80=99s any lack of clar= ity on this point. You already noted that in your view either the entire sequence must be signed or individual elements signed with a wrapper. I should have written =E2=80=9Cif supporting detached signing is not important to anyone, OK=E2=80=9D. > >This is almost dicta for all encodings of any messages. > >We found out long ago that it doesn't work when the encoding does have a >canonical form (and even when it does but it's just not used by the >signer). > >> >Section 2.3 actually says "malformed" in its first sentence. It >> >mentions truncation only as an example of why a JSON text might be >> >malformed, in the second sentent. >>=20 >> I am making a distinction between failure to parse a JSON text and >>failure >> to parse a JSON text sequence. I think the text only addresses the >>former. > >The whole section is about JSON text parse errors not being fatal for >sequence parsing. I don't understand the objection. Perhaps if you >propose text I will? I think given the lending of s to the JSON text, there is not such thing as a JSON text sequence parsing error. You find an RS to terminate an element or you run out of bytes and terminate the element - no failures at the sequence parsing level (though there may be errors that percolate to the JSON parser). > >> >> >> >> [extensive discussion of the LF elided] >>=20 >> How can a decoder know that 123 was what the originator >> intended and not something that was terminated by the text sequence >> encoder? The originator may have intended 1234. There >> seems to be some assumption that the supplier of JSON text may fail to >> self-delimit but would not fail to supply the full value. It=E2=80=99s a >>contrived >> example, but how should an incremental JSON parser handle texts returned >> from a parser operating on the sequence: 1234? >> Would it be two values 123 and 4 or one value 1234? Why is it not be >> preferable to report an error here 123 instead of trying to >> auto-terminate it when encoding the sequence? You have avoided this question in a couple of forms now. An answer here would probably clarify things tremendously with regard to additions and how incremental parsing or detecting incomplete encoding is supposed to work. > >The assumption is that the "process" writing the sequence will properly >encode the sequence elements, My assumption was =E2=80=9Ca" process encoding a =E2=80=9Csequence" may receive an "encoded sequence element=E2=80=9D from =E2=80=9Canother=E2=80=9D process, possibly as an API= call from a different box. >and will write the >sequence correctly. The point is what if element is incomplete, either due to failure or incremental contribution to the sequence? > > This too is out of scope. Which is fine because it is not the point. > >>=20 >> I guess we just disagree on whether the text sequence encoder is >> necessarily in a position to terminate data that may be incrementally >> supplied or incompletely supplied by a caller and whether or not this >> important function should be allocated to the caller instead of to the >> JSON text sequence encoder. One alternative would be to add a only > >Of course a properly functioning encoder on a properly function system >is in a position to terminate each element. How can this be in doubt? The JSON text encoder may be on one system and the JSON text sequence encoder may be on another system (one of the examples in the draft is for logs, so this must already be assumed as possible). In the example above, if the text encoder fails after sending 123, the text sequence encoder will add an and a decoder will not detect truncation. How can this be in doubt? > >A sequence encoder might write() RS, then invoke an incremental JSON >text encoder to encode and write() the JSON text, then finally when the >JSON text encoder completes its task, the sequence encoder write()s the >LF. This may be the source of confusion. Does incremental parsing encompass a single text sequence element or multiple text sequence elements? Or can it be either way? > >The sequence encoder can also marshall the whole thing into a buffer and >write() that. > >Part of the point of JSON text sequences is to permit online processing >of large data sets without requiring a streaming JSON text parser (which >is not the same as an incremental parser). That point also applies to >encoding: if the sequence elements are small enough to fit into memory >and be parsed non-incrementally, then they also necessarily meet similar >constraints on the encoder side. > >The only way to screw this up is when breaking down the process of >writing a sequence into a non-atomic sequence of operations that race in >a multi-process/threaded writer. The details of that problem and how to >avoid it are clearly out of scope for this document. > >> when a non-self-delimited text is passed to a non-incremental encoder, >> then encode that altered value into the sequence (and terminate all >> sequence elements with only). > >The RS/LF bracketing was the result of lengthy discussions on the JSON >WG list. The RS/LF bracketing design should not be reconsidered at this >time unless you have a security concern that cannot be addressed >otherwise. I reject the concern about validation of signatures via the >use of re-encoded sequences (see above and earlier) I never associated re-encoded sequences with signature verification. I only asked about accumulation during re-encoding. >-- it is commonly >accepted and strongly recommended practice that signatures should be >validated over what is signed, then and only then (after the signature >is validated successfully) should the payload be parsed. If you have >any other security concerns relating to the LF, let's hear them. No additional security concerns relating to the LF other than what has been stated (non-support for detached signatures, potential to alter interpretation of elements in some circumstances). As noted above, re-encoding is not and has not been the point re: signature verification. > >Nico >--=20 From nobody Tue Dec 16 11:37:15 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822E71A8737; Tue, 16 Dec 2014 11:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml_GlyjwjsOZ; Tue, 16 Dec 2014 11:37:10 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CCB411A872E; Tue, 16 Dec 2014 11:37:10 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 70C7759807A; Tue, 16 Dec 2014 11:37:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=5zobZSNFivI/ETQAvkFzpmrW9Z8=; b=XWX4XOty//9 bPlXiTbPYGUnV5YebHmxFyCG/n184XTDmbQIMKpllAa8Vpj+YoHQ7E8jFAtpTyj+ VUn+xfUmcrlG0hX7UvpMbkuPAfEEnXlfl3354N9XIIbASzroEdk9nbzQ8UyqSthP QYRSK7gLQYdgfmqFuo/Hq+ifOyNsDwRQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id E3E74598065; Tue, 16 Dec 2014 11:37:09 -0800 (PST) Date: Tue, 16 Dec 2014 13:37:09 -0600 From: Nico Williams To: Carl Wallace Message-ID: <20141216193707.GE3241@localhost> References: <20141216000109.GP3241@localhost> <20141216163238.GT3241@localhost> <20141216174829.GZ3241@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/3fNJf1IHwNwMuFvBJwSHZQnLyjw Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 19:37:12 -0000 On Tue, Dec 16, 2014 at 01:46:52PM -0500, Carl Wallace wrote: > On 12/16/14, 12:48 PM, "Nico Williams" wrote: > >Supporting validation of signed sequences by first re-encoding the > >sequence is absolutely not a goal. >=20 > Re-encoding is not the point. The value parsed from the sequence has an > extra relative to what was passed in and would thus break a signat= ure > generated on the original value. I don=E2=80=99t think there=E2=80=99s = any lack of clarity > on this point. You already noted that in your view either the entire > sequence must be signed or individual elements signed with a wrapper. = I > should have written =E2=80=9Cif supporting detached signing is not impo= rtant to > anyone, OK=E2=80=9D. The answer is clear: either wrap-to-sign, or remove the LF prior to validation (since it must have been added by the encoder; if the text was truncated, then the signature should fail). Or, if you're chaining encoding, parsing, encoding, parsing, you must canonicalize (except that there is no JSON canonical form), or wrap-to-sign, or not sign, or not re-encode. These choices fall out from the fact that JSON has no canonical encoding form. If the encoder should have written 1234 but wrote 1234, then this would parse to the same two elements (123 and 4), but any signatures of the first element taken over 123 would fail to validate. That's too bad. > >The whole section is about JSON text parse errors not being fatal for > >sequence parsing. I don't understand the objection. Perhaps if you > >propose text I will? >=20 > I think given the lending of s to the JSON text, there is not such > thing as a JSON text sequence parsing error. You find an RS to terminat= e Sure there is. For example: { (the LF might have been part of the truncated JSON text). Complying encoders shouldn't produce this, but if they are writing log-style to a file, they might. Which is why the parse ABNF is more tolerant than the encode ABNF. > an element or you run out of bytes and terminate the element - [...] Pete Resnick, for example, wants the SHOULD NOT in section 2.3 to be changed to something less strong. My interpretation is that some people want to parse JSON text sequences in contexts where failure to parse a JSON text in the sequence should yield a failure to parse the sequence. Therefore there is such a thing as a JSON text sequence parsing error. > [...] - no failu= res > at the sequence parsing level (though there may be errors that percolat= e > to the JSON parser). The application is on top, the JSON text parser at the bottom. No errors percolate to the JSON text parser :) > >> >> [extensive discussion of the LF elided] > >>=20 > >> How can a decoder know that 123 was what the originator > >> intended and not something that was terminated by the text sequence > >> encoder? The originator may have intended 1234. Ther= e > >> seems to be some assumption that the supplier of JSON text may fail = to > >> self-delimit but would not fail to supply the full value. It=E2=80=99= s a > >> contrived > >> example, but how should an incremental JSON parser handle texts retu= rned > >> from a parser operating on the sequence: 1234? I think we're miscommunicating. The correct way to parse 1234 is as two octet strings containing putative JSON texts: 123 and 4 -- keeping the LF or not is irrelevant (except to your signature validation concern). Each of those then parses to the numbers 123 and 4, respectively. Therefore the JSON parser should not see 1234, it should see 123 (or 123) and then 4 (or 4). Feeding the LF, or not, to the JSON text parser is not important, since it shouldn't require it. One might feed the entire sequence to the incremental JSON text parser and rely on it complaining about , skipping past it, resetting the parser's state, and restarting it. That's a perfectly legitimate implementation design. One might also scan for , split on , and feed the resulting possible-JSON texts to the JSON text parser. > >> Would it be two values 123 and 4 or one value 1234? Why is it not be 123 and 4. > >> preferable to report an error here 123 instead of trying= to > >> auto-terminate it when encoding the sequence? I don't understand this question. > You have avoided this question in a couple of forms now. An answer here > would probably clarify things tremendously with regard to addition= s > and how incremental parsing or detecting incomplete encoding is suppose= d > to work. LF is there for several reasons, one of them being to unambiguously terminate non-self-delimiting top-level values. > >The assumption is that the "process" writing the sequence will properl= y > >encode the sequence elements, >=20 > My assumption was =E2=80=9Ca" process encoding a =E2=80=9Csequence" may= receive an > "encoded sequence element=E2=80=9D from =E2=80=9Canother=E2=80=9D proce= ss, possibly as an API call > from a different box. I answered that earlier (right?) and then lost track of this concern. A process that merely adds RS/LF bracketing without parsing the sequence elements... can produce invalid sequences, and might be encoding sequence elements that are themselves sequences (though this is easy to check for: just scan for RS in the input). Although such an encoder is not considered in the I-D, we could add some text about it. I'd rather say: don't do that, always encode the JSON texts to encode the JSON text sequence. > >and will write the > >sequence correctly. >=20 > The point is what if element is incomplete, either due to failure or > incremental contribution to the sequence? Section 2.1 says it's a possible JSON text. Section 2.3 tells you what to do if it's incomplete. Section 2.4 explains how to determinie if is complete when it's not a self-delimiting value (and, of course, if it is self-delimiting, then it is self-delimiting, but the LF is still useful for the other reasons that I gave). > > > > This too is out of scope. >=20 > Which is fine because it is not the point. If I still haven't answered your question then please propose some text. > > > >>=20 > >> I guess we just disagree on whether the text sequence encoder is > >> necessarily in a position to terminate data that may be incrementall= y > >> supplied or incompletely supplied by a caller and whether or not thi= s > >> important function should be allocated to the caller instead of to t= he > >> JSON text sequence encoder. One alternative would be to add a = only > > > >Of course a properly functioning encoder on a properly function system > >is in a position to terminate each element. How can this be in doubt? >=20 > The JSON text encoder may be on one system and the JSON text sequence > encoder may be on another system (one of the examples in the draft is f= or > logs, so this must already be assumed as possible). In the example abov= e, > if the text encoder fails after sending 123, the text sequence encoder > will add an and a decoder will not detect truncation. How can this= be > in doubt? It's not. I just don't think one should encode JSON text sequences this way. After lunch I'll propose text explicitly requiring sequence encoders to also invoke the JSON text encoder. > >A sequence encoder might write() RS, then invoke an incremental JSON > >text encoder to encode and write() the JSON text, then finally when th= e > >JSON text encoder completes its task, the sequence encoder write()s th= e > >LF. >=20 > This may be the source of confusion. Does incremental parsing encompass= a > single text sequence element or multiple text sequence elements? Or ca= n > it be either way? See above. > I never associated re-encoded sequences with signature verification. I > only asked about accumulation during re-encoding. If you parse a sequence and its elements, and re-encode, you'll get more differences than different amounts of LFs. > >-- it is commonly > >accepted and strongly recommended practice that signatures should be > >validated over what is signed, then and only then (after the signature > >is validated successfully) should the payload be parsed. If you have > >any other security concerns relating to the LF, let's hear them. >=20 > No additional security concerns relating to the LF other than what has > been stated (non-support for detached signatures, potential to alter > interpretation of elements in some circumstances). As noted above, > re-encoding is not and has not been the point re: signature verificatio= n. OK. Nico --=20 From nobody Tue Dec 16 12:44:20 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067151A87B8 for ; Tue, 16 Dec 2014 12:44:15 -0800 (PST) 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 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 9kBHPCsYoV10 for ; Tue, 16 Dec 2014 12:44:13 -0800 (PST) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE301A87A3 for ; Tue, 16 Dec 2014 12:44:13 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id e89so10628806qgf.24 for ; Tue, 16 Dec 2014 12:44:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ico8deUiK2k0TK0LwpeGBtSpTQ5qwr7AKuxiu6x/zwA=; b=M8FERo0qDihCs5+XjfffmoR5FrpcURpGSMv8Sp/8C96VIzbdaBQVoCT5rT7c6WfLIn /6LGWB3h3AhKlEOPHfNU/xNE8N9m25OfsytIKlsl1Ep8h8cwMIc+eEATmTbPr++JcBDs fVzlCa3S+LZN8XqJ4UHkJLLR2d+4wxM7EL+eE9wZEiNtwUB4eUiDnamsQ+4D1kbriva9 YKRx3o6WMBCt1FSxkMpU3g+WCV2LVl9va6ZnAAHes6SJWgrB7QTP8Wex/zolUKBtEdwC DXzHJwdjWOsphl/rlm2C9jiZ6u+29Lm1CixWJDSfOIekx9Ci2sFQSdP2MhUSOwkyXXrR wNIA== X-Gm-Message-State: ALoCoQmyNXQBk1EKbNStYHdix2/vZ0GP8zVSuWF6g2lH2jUnEQY5AdhdveVZytiwz55he64QVv92 X-Received: by 10.140.94.229 with SMTP id g92mr66700872qge.77.1418762652541; Tue, 16 Dec 2014 12:44:12 -0800 (PST) Received: from [192.168.2.39] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id t2sm1887282qae.6.2014.12.16.12.44.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Dec 2014 12:44:11 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Tue, 16 Dec 2014 15:44:05 -0500 From: Carl Wallace To: Nico Williams Message-ID: Thread-Topic: [secdir] secdir review of draft-ietf-json-text-sequence-11 References: <20141216000109.GP3241@localhost> <20141216163238.GT3241@localhost> <20141216174829.GZ3241@localhost> <20141216193707.GE3241@localhost> In-Reply-To: <20141216193707.GE3241@localhost> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/mDr1JBiTOd3gJZ6EvDPQVjNf3k0 Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 20:44:15 -0000 On 12/16/14, 2:37 PM, "Nico Williams" wrote: > >Although such an encoder is not considered in the I-D, we could add some >text about it. I'd rather say: don't do that, always encode the JSON >texts to encode the JSON text sequence. >>>Of course a properly functioning encoder on a properly function >>system >> >is in a position to terminate each element. How can this be in doubt? >>=20 >> The JSON text encoder may be on one system and the JSON text sequence >> encoder may be on another system (one of the examples in the draft is >>for >> logs, so this must already be assumed as possible). In the example >>above, >> if the text encoder fails after sending 123, the text sequence encoder >> will add an and a decoder will not detect truncation. How can this >>be >> in doubt? > >It's not. I just don't think one should encode JSON text sequences this >way. After lunch I'll propose text explicitly requiring sequence >encoders to also invoke the JSON text encoder. Most of the words in this now very long thread stem from this. I will wait to review new text. I don=E2=80=99t think there is any lack of clarify on the signature issue. Most of the remainder is related to the document=E2=80=99s recognition of 123 as a detachable truncation problem but not 123 where the truncation occurred prior to invoking the sequence encoder.=20 From nobody Tue Dec 16 13:35:45 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DF51A8756; Tue, 16 Dec 2014 13:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxkubrpPdtex; Tue, 16 Dec 2014 13:35:40 -0800 (PST) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 957291A875E; Tue, 16 Dec 2014 13:35:40 -0800 (PST) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 5E5C220058D84; Tue, 16 Dec 2014 13:35:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=tjL2mRRD3rQNYfcqj54ahQsXbeo=; b=J3S4jGmGbor Mqr9UXSPvhleirlWlSBCh2ksbLpD7eJMdX7E8QkRPO1MIISQGG8c2sZ1lpmjUGP4 XbO59MtGwHnMGiclZGiStUjQq7kodrQccCCQyoY2qh4NJjl8X5KSYQ7Fe8XNZPiY 1ArN7o9Qb8ATkqsXgz3gk4+ap2qSJ7ko= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id EE62320058D83; Tue, 16 Dec 2014 13:35:39 -0800 (PST) Date: Tue, 16 Dec 2014 15:35:39 -0600 From: Nico Williams To: Carl Wallace Message-ID: <20141216213533.GI3241@localhost> References: <20141216000109.GP3241@localhost> <20141216163238.GT3241@localhost> <20141216174829.GZ3241@localhost> <20141216193707.GE3241@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Bnn2F1CKZHiSE0UXsOOqGB2SqNQ Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 21:35:41 -0000 On Tue, Dec 16, 2014 at 03:44:05PM -0500, Carl Wallace wrote: > On 12/16/14, 2:37 PM, "Nico Williams" wrote: > >It's not. I just don't think one should encode JSON text sequences th= is > >way. After lunch I'll propose text explicitly requiring sequence > >encoders to also invoke the JSON text encoder. >=20 > Most of the words in this now very long thread stem from this. I will w= ait > to review new text. I don=E2=80=99t think there is any lack of clarify = on the > signature issue. Most of the remainder is related to the document=E2=80= =99s > recognition of 123 as a detachable truncation problem but not > 123 where the truncation occurred prior to invoking the > sequence encoder.=20 In section 2.2, add before the last paragraph: JSON text sequence encoders are expected to ensure that the sequence elements are properly formed. When the JSON text sequence encoder does the JSON text encoding, the sequence elements will naturally be properly formed. When the JSON text sequence encoder accepts already-encoded JSON texts, the JSON text sequence encoder ought to to parse them before adding them to a sequence. Nico --=20 From nobody Tue Dec 16 18:14:14 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6871A0248 for ; Tue, 16 Dec 2014 18:14:06 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwRkBV2oANb4 for ; Tue, 16 Dec 2014 18:14:04 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B71B1A0140 for ; Tue, 16 Dec 2014 18:14:04 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id r5so11197240qcx.41 for ; Tue, 16 Dec 2014 18:14:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=KZ3HyPkty8P9vWnfUHvltozK1/QFASwrp9yGkEK6glI=; b=igaGklWEIgUorPOKlxkfJDSKFRD3K7qH05lqNwoEmztvojJR0KKUdCiGZ0NV0B/nVG Ib18y0w/qSmVnZ//l7YvnqktrqLfaLEl5rE0pkXlBME616K/R7AxICSSKt/c8GRytQeF EplqnbvqGOj1m9pp39fBcpg50qjcbnLC/BMdmcnYT3Ktaj7NyTFoIgmxEjhCBQE2Zlqm pdsALVRlyjX1IRVsDQEP25k/c2EoImo9hW+vgOfJ/vSBxHKokimEWBDzJ3sDJIU1v1Hn cgL4yzRdJSjIOnLSRoswQh7txnMCquD+VICTFqb9qloGJIhV+3AUzyeEgcHNEyTsLmBw EsRA== X-Gm-Message-State: ALoCoQkIIjWV+ELedJ73bYvdyiTTLf/TCruqBa0p2LaazuXENjwKEGYcHnWfyi6VoNtSDs9EC2oz X-Received: by 10.140.109.132 with SMTP id l4mr67364341qgf.91.1418782443726; Tue, 16 Dec 2014 18:14:03 -0800 (PST) Received: from [192.168.2.58] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id t5sm2659822qad.5.2014.12.16.18.14.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Dec 2014 18:14:03 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Tue, 16 Dec 2014 21:13:55 -0500 From: Carl Wallace To: Nico Williams Message-ID: Thread-Topic: [secdir] secdir review of draft-ietf-json-text-sequence-11 References: <20141216000109.GP3241@localhost> <20141216163238.GT3241@localhost> <20141216174829.GZ3241@localhost> <20141216193707.GE3241@localhost> <20141216213533.GI3241@localhost> In-Reply-To: <20141216213533.GI3241@localhost> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0Z4iXBPd0ssOi4RyKfjwNawwneg Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 02:14:06 -0000 On 12/16/14, 4:35 PM, "Nico Williams" wrote: >On Tue, Dec 16, 2014 at 03:44:05PM -0500, Carl Wallace wrote: >> On 12/16/14, 2:37 PM, "Nico Williams" wrote: >> >It's not. I just don't think one should encode JSON text sequences >>this >> >way. After lunch I'll propose text explicitly requiring sequence >> >encoders to also invoke the JSON text encoder. >>=20 >> Most of the words in this now very long thread stem from this. I will >>wait >> to review new text. I don=E2=80=99t think there is any lack of clarify on the >> signature issue. Most of the remainder is related to the document=E2=80=99s >> recognition of 123 as a detectable truncation problem but not >> 123 where the truncation occurred prior to invoking the >> sequence encoder. > >In section 2.2, add before the last paragraph: > > JSON text sequence encoders are expected to ensure that the sequence > elements are properly formed. When the JSON text sequence encoder > does the JSON text encoding, the sequence elements will naturally be > properly formed. When the JSON text sequence encoder accepts > already-encoded JSON texts, the JSON text sequence encoder ought to > to parse them before adding them to a sequence. I don=E2=80=99t think this is quite there as parsing the already encoded texts does not necessarily detect truncation. Even where the text sequence encoder does the JSON text encoding it may do so on an incomplete value due to crash or administrative process termination depending on the how the JSON text sequence parser is situated relative to the JSON text element source. I am at a loss to supply alternate text because the text would cement an arrangement of the encoders that is probably unnecessarily rigid for a document defining a data structure. I still think the solution is to remove the delimiters added by the JSON text sequence encoder in the JSON text sequence decoder. This seems cleaner to me. It would probably require the encoder to reject inputs that have not been properly terminated or perhaps have a flag to auto-add to non-self-delimited top level values before adding the where such is safe to do. As you have noted, the existing text that has been agreed to by the WG so I will defer to you, the WG and the ADs on the point. I think you already agreed to add some text highlighting the fact that text sequence elements are poor targets for detached signatures due to the fact that encoding the element in the sequence changes it. From nobody Wed Dec 17 01:33:12 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1174B1A1EEF; Wed, 17 Dec 2014 01:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8ln_0e5bU9C; Wed, 17 Dec 2014 01:33:07 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33681A6F56; Wed, 17 Dec 2014 01:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3531; q=dns/txt; s=iport; t=1418808786; x=1420018386; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pz+QeWyVtpipi5zmFuzhXMXp69GqPGsOSwlYEbdGJC4=; b=JyOfPKc6do5J3vZViO3j7t5Ko2ac8przMpownzRfMz2VPWIoGAALmsAN rXWU4ay5hTb1JtqD0BmO5MRleH+uW4XrBD455ef7iW6OPIsiVWJADhraM UW+ixnPQISNC2nim2lNwiTYKwnxvXgDy+hc/ukMfY8iFmi3xvS/uTKWyz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHJMkVStJssW/2dsb2JhbABag1hYxgGFbgKBMAEBAQEBfYQNAQEEODoGARALGAkWDwkDAgECAUUGAQwBBwEBiCgN1B0BAQEBAQEBAQEBAQEBAQEBAQEBAQETBI8kTgeEKQEEkUWFMoV5i0Aig209MAEBAYJAAQEB X-IronPort-AV: E=Sophos;i="5.07,592,1413244800"; d="scan'208";a="277419785" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 17 Dec 2014 09:33:03 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBH9X3OH006899; Wed, 17 Dec 2014 09:33:03 GMT Message-ID: <54914DCF.6080803@cisco.com> Date: Wed, 17 Dec 2014 10:33:03 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Melinda Shore , draft-ietf-eman-applicability-statement.all@ietf.org References: <547A5E8E.1070002@gmail.com> In-Reply-To: <547A5E8E.1070002@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/RtMedJfAiknJq-lXo01rZlkOse0 Cc: IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-eman-applicability-statement-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 09:33:09 -0000 On 30/11/2014 01:02, Melinda Shore wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Summary: Security considerations section is insufficient. Otherwise > the document is in pretty good shape (with nits). > > This document is essentially a set of use cases guiding the energy > management's (eman) working group's work, as well as providing a > description of the relationship of the IETF's eman's framework to > other relevant energy monitoring standards. > > Of particular interest, perhaps, is that eman is using SNMP to convey > energy device information. > > The use cases are very clearly described, and we're grateful for > the "essential properties" breakout summaries ("target devices," > "how powered," and "reporting") at the bottom of each use case. > > All that said, I was extremely surprised to get to the "Security > considerations" section and find that it consisted of but two > generic sentences about SNMP. Note that there is some text in the framework itself. https://tools.ietf.org/html/rfc7326#section-10 Regards, Benoit > We are all aware of issues related > to the sensitivity of the electric grid, and powered devices, > to security vulnerabilities and that this is a time of heightened > scrutiny of how the grid is secured. This necessarily extends to > monitoring, and there is certainly a *lot* of information that > may be gleaned by an attacker from monitoring power consumption, > as well as manipulation of the grid by an attacker inserting > bogus monitoring messages. > > There does not appear to have been any work done within the > group on developing a threat model for energy monitoring, which > strikes me as problematic. However, even in the absence of an > interest in developing one, a quick summary of the sorts of > attacks that must be considered in the development and deployment > of energy monitoring mechanisms strikes me as far, far, far > more useful than a one-sentence rundown of generic security mechanisms > provided by SNMPv3. > > Minor comments: > > 1) This is more by way of guidance, but it should be noted that > while the information model may be portable to YANG, netconf, > and others, the security models and technologies used to secure > those protocols may be (and are) different, and security > properties need to be given serious consideration before > moving the information model to another conveyance. > > 2) the I-D nit checker found a number of problems in the references, > as well as a few other problems. > https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-eman-applicability-statement-08.txt > > Trivial nits: > > 1) In section 1.2, the document name/reference should be separated > from the document description by a colon and space > > 2) In that same section there's a stray period at the very bottom of > page 4 > > 3) Section 2, first paragraph: "This section a presents energy > management scenarios [ ... ]". That 'a' (third word) needs to be > removed. > > 4) For some reason the section header for section 2.8 does not appear > bolded, while those for other subsections do. > > > Melinda > . > From nobody Wed Dec 17 03:52:10 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBF91A8949 for ; Wed, 17 Dec 2014 03:52:02 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S9f9-MG-W7x for ; Wed, 17 Dec 2014 03:51:50 -0800 (PST) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B0D1A8942 for ; Wed, 17 Dec 2014 03:51:49 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id dc16so953362qab.37 for ; Wed, 17 Dec 2014 03:51:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=0aBt14hBwd2fn1wNJl6sOiCGfp41M9mFExjWiTib7TE=; b=KP8ltJsvyKstpYCUIGeBbRDKSbnkA/L6bdjd9DZvCTH7S+/JEKPdzVGVnKFROL/IfI B+UdZAOKQNJM6SqV58uZNETcjPfqAcunRmf4ZgjBvMwRQ3cfSEEUxNJAbTpQAz72kfmk c3v2uxWHUc13VDqPeMRFyWFd9W7Ddjyyt9sJlCrveuqVxf4liNyjvLEeRYT3jEwCqxMR 774DlKcNIo4d7c+FQ988zAbc1qq7oHUn0eBImqUWpVDkJ1aZD9viCAtOmDA+rjevvfAg xvLiPVCRv/r5XMd+GaTuIzcwNBc7OiynY1iEEFZ3Q4Bsa5SEeHSyxun8zV16RvZ5NId6 zjfQ== X-Gm-Message-State: ALoCoQmYrhY/w8esfqrcBZXhQDz5ZgsVLBktHpR5ECZ87A89tNIattZQBc1EZS8IYii8MbzRlZMT X-Received: by 10.224.72.5 with SMTP id k5mr75556607qaj.2.1418817108726; Wed, 17 Dec 2014 03:51:48 -0800 (PST) Received: from [192.168.2.58] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id l7sm3621903qai.37.2014.12.17.03.51.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 17 Dec 2014 03:51:48 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Wed, 17 Dec 2014 06:51:41 -0500 From: Carl Wallace To: Nico Williams Message-ID: Thread-Topic: [secdir] secdir review of draft-ietf-json-text-sequence-11 References: <20141216000109.GP3241@localhost> <20141216163238.GT3241@localhost> <20141216174829.GZ3241@localhost> <20141216193707.GE3241@localhost> <20141216213533.GI3241@localhost> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Vb0UHYrdXiSdtOue_DxoIC4nRXg Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 11:52:03 -0000 Sorry for the self-reply, there was also some additional text to add clarifying incremental parsing does not cut across multiple JSON text sequence elements (in addition to a note regarding fitness for detached signatures and any notes). On 12/16/14, 9:13 PM, "Carl Wallace" wrote: > > >On 12/16/14, 4:35 PM, "Nico Williams" wrote: > >>On Tue, Dec 16, 2014 at 03:44:05PM -0500, Carl Wallace wrote: >>> On 12/16/14, 2:37 PM, "Nico Williams" wrote: >>> >It's not. I just don't think one should encode JSON text sequences >>>this >>> >way. After lunch I'll propose text explicitly requiring sequence >>> >encoders to also invoke the JSON text encoder. >>>=20 >>> Most of the words in this now very long thread stem from this. I will >>>wait >>> to review new text. I don=E2=80=99t think there is any lack of clarify on the >>> signature issue. Most of the remainder is related to the document=E2=80=99s >>> recognition of 123 as a detectable truncation problem but not >>> 123 where the truncation occurred prior to invoking the >>> sequence encoder. >> >>In section 2.2, add before the last paragraph: >> >> JSON text sequence encoders are expected to ensure that the sequence >> elements are properly formed. When the JSON text sequence encoder >> does the JSON text encoding, the sequence elements will naturally be >> properly formed. When the JSON text sequence encoder accepts >> already-encoded JSON texts, the JSON text sequence encoder ought to >> to parse them before adding them to a sequence. > >I don=E2=80=99t think this is quite there as parsing the already encoded texts >does not necessarily detect truncation. Even where the text sequence >encoder does the JSON text encoding it may do so on an incomplete value >due to crash or administrative process termination depending on the how >the JSON text sequence parser is situated relative to the JSON text >element source. I am at a loss to supply alternate text because the text >would cement an arrangement of the encoders that is probably >unnecessarily=20 >rigid for a document defining a data structure. I still think the >solution=20 >is to remove the delimiters added by the JSON text sequence encoder in >the=20 >JSON text sequence decoder. This seems cleaner to me. It would probably >require the encoder to reject inputs that have not been properly >terminated or perhaps have a flag to auto-add to non-self-delimited >top level values before adding the where such is safe to do. > >As you have noted, the existing text that has been agreed to by the WG so >I will defer to you, the WG and the ADs on the point. I think you >already agreed to add some text highlighting the fact that text sequence >elements are poor targets for detached signatures due to the fact that >encoding the element in the sequence changes it. > From nobody Wed Dec 17 10:21:57 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E021A6FE1; Wed, 17 Dec 2014 10:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8a0lEz3r7VN; Wed, 17 Dec 2014 10:21:47 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB211A1BE3; Wed, 17 Dec 2014 10:21:39 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id D6B1150808C; Wed, 17 Dec 2014 10:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=S+WqEYYkPc8XaY NWJPO4HZvrclo=; b=c2qvoERwSVtrWPxrdo6d5ay0h3XEcqdFGRgoA8I7Qe3B7V deLFcRahTM8/3HywGvedQUZsaVMmHyuU2a9f7ZXfK+zfzF7JAxc/lC4GplN0LFPe j9Km7I9WGvetGcIJNBGLo9FLaaVdXMo/vLjpVMefe5YeCdv/XeksQD1Tycz8Y= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id 65A86508064; Wed, 17 Dec 2014 10:21:38 -0800 (PST) Date: Wed, 17 Dec 2014 12:21:37 -0600 From: Nico Williams To: Carl Wallace Message-ID: <20141217182132.GY3241@localhost> References: <20141216163238.GT3241@localhost> <20141216174829.GZ3241@localhost> <20141216193707.GE3241@localhost> <20141216213533.GI3241@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/w-wVjYDTB8nrnSMvN3lPxEcI6OE Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 18:21:47 -0000 On Wed, Dec 17, 2014 at 06:51:41AM -0500, Carl Wallace wrote: > Sorry for the self-reply, there was also some additional text to add > clarifying incremental parsing does not cut across multiple JSON text > sequence elements (in addition to a note regarding fitness for detached > signatures and any notes). That's strongly implied by the parsing ABNF. From nobody Wed Dec 17 10:55:40 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B413A1A6FF9; Wed, 17 Dec 2014 10:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22ZpWKTMavZt; Wed, 17 Dec 2014 10:55:30 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6081A1BBE; Wed, 17 Dec 2014 10:55:30 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id A0F1C76805C; Wed, 17 Dec 2014 10:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=IzuTY1544Pk/Ln DQHPRFYHEuuBk=; b=jHapU2vp3COnmD3Rfg+EsiySpk+yZZ+tp2PNFJQKPYy7jb pVItMYBHNeSpE3IYFL3HFTDQ73wZJQzpBlY9WAmhq2kAwt683X/UYeBOfczSE4QN ajs5yyqcAKDPoWCB5aSx5KM1wtggpgzsCQDbN0CIAIU3QbL01IYT+0B0DrU2s= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPA id 3ED0E768057; Wed, 17 Dec 2014 10:55:29 -0800 (PST) Date: Wed, 17 Dec 2014 12:55:28 -0600 From: Nico Williams To: Carl Wallace Message-ID: <20141217185523.GA3241@localhost> References: <20141216000109.GP3241@localhost> <20141216163238.GT3241@localhost> <20141216174829.GZ3241@localhost> <20141216193707.GE3241@localhost> <20141216213533.GI3241@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/-V-HrQF3lxDQIiYkNT6MWZDnToc Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 18:55:34 -0000 On Tue, Dec 16, 2014 at 09:13:55PM -0500, Carl Wallace wrote: > [...]. I still think the solution > is to remove the delimiters added by the JSON text sequence encoder in the > JSON text sequence decoder. This seems cleaner to me. It would probably > require the encoder to reject inputs that have not been properly > terminated or perhaps have a flag to auto-add to non-self-delimited > top level values before adding the where such is safe to do. Tolerating a missing LF seems like a fine thing to do if the top-level value was nonetheless valid and delimited. On the other hand it adds some ambiguity if some sequence parser implementations can tolerate it and others can't. For logging applications tolerating a missing LF seems like a desirable thing to do, actually. For non-logging applications not tolerating it seems better. Does requiring that the sequence parser strip the trailing LF complicate the sequence parser ABNF? I think the stripping of the trailing LF simply can't be expressed in ABNF, only in prose. I'll play with an implementation tonight and see what I think after I re-write some code (jq, specifically). It may well be that I like it better your way. Nico -- From nobody Wed Dec 17 15:41:23 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31351A0045; Wed, 17 Dec 2014 15:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6E_mTMA6Sma; Wed, 17 Dec 2014 15:41:19 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DF5721A001C; Wed, 17 Dec 2014 15:41:19 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id A15BF59807A; Wed, 17 Dec 2014 15:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=kFYA7eTt4r8cRI 3hTRXpiLpZ3xE=; b=NO2rAOnjiTeJdQHTrCZ1gSvGkw+UEQlJvZXkQ8ARMgItHX JDovSuNCUm8HJwtfVt+lqQ65ZBtBnOZWCjFVZymBC81YP+7xdsvupv/Mrvb0gjd9 aY+GKMa3Cg8/nj3vaQTSHXWGcxwaKz9IEOnKnWdBUYEEDVqUgdRzhXrGFJ948= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id 3D3B4598065; Wed, 17 Dec 2014 15:41:19 -0800 (PST) Date: Wed, 17 Dec 2014 17:41:18 -0600 From: Nico Williams To: Carl Wallace Message-ID: <20141217234113.GH9443@localhost> References: <20141216163238.GT3241@localhost> <20141216174829.GZ3241@localhost> <20141216193707.GE3241@localhost> <20141216213533.GI3241@localhost> <20141217185523.GA3241@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141217185523.GA3241@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/5RFuufpzqtFS2_dWLRzLQzetnnA Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 23:41:21 -0000 On Wed, Dec 17, 2014 at 12:55:23PM -0600, Nico Williams wrote: > On Tue, Dec 16, 2014 at 09:13:55PM -0500, Carl Wallace wrote: > > [...]. I still think the solution > > is to remove the delimiters added by the JSON text sequence encoder in the > > JSON text sequence decoder. This seems cleaner to me. It would probably > > require the encoder to reject inputs that have not been properly > > terminated or perhaps have a flag to auto-add to non-self-delimited > > top level values before adding the where such is safe to do. > > Tolerating a missing LF seems like a fine thing to do if the top-level > value was nonetheless valid and delimited. > > On the other hand it adds some ambiguity if some sequence parser > implementations can tolerate it and others can't. I continue to think that the best thing to do is have a recommendation as to how to handle ambiguities, and point them out. Therefore I don't think we should say that the parser MUST strip the trailing LF, but SHOULD (or MAY not strip it) would be fine, and should address the concern about alterations to JSON texts that can then affect cryptographic integrity protection. So, how about these changes to section 2.1: The ABNF [RFC5234] for the JSON text sequence parser is as given in Figure 1. - JSON-sequence = *(1*RS possible-JSON) + JSON-sequence = *(1*RS possible-JSON LF) + LF = %x0A; "line feed" (LF), see RFC20 RS = %x1E; "record separator" (RS), see RFC20 ; Also known as: Unicode Character 'INFORMATION SEPARATOR ; TWO' (U+001E) possible-JSON = 1*(not-RS); attempt to parse as UTF-8-encoded ; JSON text (see RFC7159) not-RS = %x00-1d / %x1f-ff; any octets other than RS Figure 1: JSON text sequence ABNF In prose: a series of octet strings, each containing any octet other - than a record separator (RS) (0x1E) [RFC0020], all octet strings - separated from each other by RS octets. Each octet string in the - sequence is to be parsed as a JSON text in the UTF-8 encoding - [RFC3629]. + than a record separator (RS) (0x1E) [RFC0020], and each such octet + string prefixed by an RS octet and suffixed by an LF octet. Each + octet string in the sequence is to be parsed as a JSON text in the + UTF-8 encoding [RFC3629]. If parsing of such an octet string as a UTF-8-encoded JSON text fails, the parser SHOULD nonetheless continue parsing the remainder of the sequence. The parser can report such failures to applications (which might then choose to terminate parsing of a sequence). Multiple consecutive RS octets do not denote empty sequence elements between them, and can be ignored. + JSON text sequence parsers MAY include the LF suffix (from the + sequence encoding) when parsing a JSON text sequence element, but it + is best not to when the sequence parser's output is the element JSON + texts rather than an internal representation of the parsed element + JSON texts. + There is no end of sequence indicator. ? Nico -- From nobody Wed Dec 17 19:21:20 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB7B1A0103; Wed, 17 Dec 2014 19:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7IfTxNGr1Fc; Wed, 17 Dec 2014 19:21:13 -0800 (PST) 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 2A3071A010C; Wed, 17 Dec 2014 19:21:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQE90749; Thu, 18 Dec 2014 03:21:10 +0000 (GMT) Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 18 Dec 2014 03:21:09 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.153]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.03.0158.001; Thu, 18 Dec 2014 11:21:03 +0800 From: Tina TSOU To: "Org Secdir@Ietf." , "Org Iesg@Ietf." , "draft-ietf-dnsop-dnssec-key-timing.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-dnsop-dnssec-key-timing-06 Thread-Index: AQHQGnGn+Egv1346o0inbQdvPuNZig== Date: Thu, 18 Dec 2014 03:21:03 +0000 Message-ID: <8618C668-2030-4CA9-B190-329C7FD630C6@huawei.com> References: <5491E390.1010809@si6networks.com> In-Reply-To: <5491E390.1010809@si6networks.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/zMxzzyMPGPWqiFJCgE_YaAns5Oc Subject: [secdir] Secdir review of draft-ietf-dnsop-dnssec-key-timing-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 03:21:14 -0000 Dear all, I have reviewed this document as part of the security directorate=92s ongoi= ng effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requireme= nts and considerations in IETF drafts. Comments not addressed in last call= may be included in AD reviews during the IESG review. Document editors an= d WG chairs should treat these comments just like any other last call comments. * Section 3.1: Are all these states defined in this document. If not, please state otherwise and provide a reference. * Section 3.1, page 9: > Dead The key and is associated data are present in their > respective zones, but there is no longer information > anywhere that require their presence for use in > validation. Hence they can be removed at any time. It should say "and its associated..." * Section 3.1, page 9: > There is one additional state, used where [RFC5011] considerations > are in effect (see Section 3.3.4): >=20 > Revoked The DNSKEY is published for a period with the "revoke" > bit set as a way of notifying validating resolvers that > have configured it as an [RFC5011] trust anchor that it > is about to be removed from the zone. Please phrase this one without an introduction. e.g.: Revoked The DNSKEY is published for a period with the "revoke" bit set as a way of notifying validating resolvers that have configured it as an [RFC5011] trust anchor that it is about to be removed from the zone. This state is used where [RFC5011] considerations are in effect (see Section 3.3.4) * Section 3.2.2., page 13: > At the end of this interval, key N is said to be dead. This occurs > at the dead time (Tdea) so: >=20 > Tdea(N) =3D Tact(N+1) + Iret Why not use this notation "Parameter(key_number)" for the figures? -- It would make them way clearer. * Section 3.3.5, page 23: > In the case of an > insecure parent, i.e. the initial creation of a new security apex, it > is not possible to guarantee this. Please define "security apex". Happy holidays! Thank you, Tina From nobody Thu Dec 18 03:16:57 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA141A6F53 for ; Thu, 18 Dec 2014 03:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eDPTwcvjpnN for ; Thu, 18 Dec 2014 03:16:54 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 3B6C51A07BE for ; Thu, 18 Dec 2014 03:16:54 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sBIBGqhg016911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 18 Dec 2014 13:16:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBIBGq2l013058; Thu, 18 Dec 2014 13:16:52 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21650.47012.69945.484575@fireball.kivinen.iki.fi> Date: Thu, 18 Dec 2014 13:16:52 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 2 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0KAcWxB2gbAb83184VnWMAr77Nw Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 11:16:56 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tero Kivinen is next in the rotation. For telechat 2014-12-18 Reviewer LC end Draft Klaas Wierenga T 2014-12-08 draft-ietf-mpls-tp-te-mib-10 For telechat 2015-01-08 Alan DeKok T 2015-01-01 draft-higgs-hbbtv-urn-00 Phillip Hallam-Baker T 2014-12-24 draft-ietf-pce-rfc7150bis-01 Simon Josefsson T 2014-12-25 draft-ietf-rtgwg-remote-lfa-09 Benjamin Kaduk T 2014-12-25 draft-ietf-sfc-problem-statement-10 Scott Kelly T 2014-12-26 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07 David Waltermire T 2014-12-09 draft-ietf-kitten-cammac-00 For telechat 2015-01-22 Sam Hartman T 2015-01-09 draft-farrkingel-pce-abno-architecture-14 Chris Inacio T 2015-01-20 draft-ietf-pcp-server-selection-07 Last calls and special requests: Derek Atkins 2014-12-29 draft-pechanec-pkcs11uri-16 Donald Eastlake 2014-12-24 draft-ietf-httpauth-hoba-07 Shawn Emery 2014-12-24 draft-ietf-aqm-recommendation-08 Dorothy Gellert 2014-12-22 draft-ietf-ippm-rate-problem-08 Tobias Gondrom 2014-12-18 draft-ietf-mpls-ldp-ipv6-14 Olafur Gudmundsson 2014-12-24 draft-ietf-ospf-te-metric-extensions-08 Steve Hanna 2014-12-24 draft-ietf-roll-admin-local-policy-02 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Dan Harkins 2014-12-22 draft-ietf-tsvwg-port-use-06 David Harrington 2014-12-24 draft-ietf-tsvwg-sctp-dtls-encaps-07 Paul Hoffman 2015-01-08 draft-holmberg-dispatch-iotl-03 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-07 Jeffrey Hutzelman 2015-01-07 draft-ietf-dnssd-requirements-04 Leif Johansson 2014-12-25 draft-ietf-radext-radius-fragmentation-09 Charlie Kaufman E None draft-ietf-i2rs-architecture-07 Stephen Kent E None draft-ietf-i2rs-problem-statement-04 Matt Lepinski 2014-11-18 draft-nottingham-safe-hint-05 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Sam Weiler 2014-12-08 draft-ietf-l3vpn-acceptown-community-08 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-12 Paul Wouters 2014-12-04 draft-ietf-tcpm-accecn-reqs-07 -- kivinen@iki.fi From nobody Thu Dec 18 04:12:47 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559FF1A883B for ; Thu, 18 Dec 2014 04:12:42 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-UZRHa_DuLu for ; Thu, 18 Dec 2014 04:12:40 -0800 (PST) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708C71A888B for ; Thu, 18 Dec 2014 04:12:40 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id r5so729256qcx.30 for ; Thu, 18 Dec 2014 04:12:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=2/6MHDUmDfuPOxXZHoskLiG7VZUgnvgmVEq5jULxeDw=; b=ZLKZlsAq7pVEpnjoYRNITckEWe2oC8AnV8pxwxGJwaITKdrcdbifnzDnKEJ79chz1V uvuB1HAjUIUM9eDQu4DSvzfj+RmFLemgBxuBtKTfIVAVuJJdRhQ21LwYGnAHZ0osoNDq ABb7ZJbAYStls2JWmMpbPTv8HqMgoL+nCJaUlsL33e/WM8xHHCFhwLbb4oVFFRHDJ9iw tUKu5ytY1Ii984Fl6XZ78HMTXFcmHDUwOmjYncKbdhu0tx5hxSrAyfNyuCyhmoTArxS3 WX20aoLY4UmuxqJ3N3KyUwkjBO2edIwnqRUViwgCZOrEAn06jh2gb3aqBfF7PDsb0ZcZ t70A== X-Gm-Message-State: ALoCoQlzKBfNL72BFKNUe0qhw9w0zzOTrU9J6HNzPB1UOTqoQ+npYavlRuf7q4s10GIKpiLQr5Cg X-Received: by 10.229.61.5 with SMTP id r5mr2902970qch.28.1418904759522; Thu, 18 Dec 2014 04:12:39 -0800 (PST) Received: from [192.168.2.39] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id k11sm6591031qgf.18.2014.12.18.04.12.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Dec 2014 04:12:39 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Thu, 18 Dec 2014 07:12:34 -0500 From: Carl Wallace To: Nico Williams Message-ID: Thread-Topic: [secdir] secdir review of draft-ietf-json-text-sequence-11 References: <20141216163238.GT3241@localhost> <20141216174829.GZ3241@localhost> <20141216193707.GE3241@localhost> <20141216213533.GI3241@localhost> <20141217185523.GA3241@localhost> <20141217234113.GH9443@localhost> In-Reply-To: <20141217234113.GH9443@localhost> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/1vqQp30PuzBe3NwR90U-wZi_PqQ Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 12:12:42 -0000 On 12/17/14, 6:41 PM, "Nico Williams" wrote: >On Wed, Dec 17, 2014 at 12:55:23PM -0600, Nico Williams wrote: >> On Tue, Dec 16, 2014 at 09:13:55PM -0500, Carl Wallace wrote: >> > [...]. I still think the >>solution >> > is to remove the delimiters added by the JSON text sequence encoder >>in the >> > JSON text sequence decoder. This seems cleaner to me. It would >>probably >> > require the encoder to reject inputs that have not been properly >> > terminated or perhaps have a flag to auto-add to >>non-self-delimited >> > top level values before adding the where such is safe to do. >>=20 >> Tolerating a missing LF seems like a fine thing to do if the top-level >> value was nonetheless valid and delimited. >>=20 >> On the other hand it adds some ambiguity if some sequence parser >> implementations can tolerate it and others can't. The suggestion is not to tolerate a missing but to not always add them in the text sequence encoder in the first place. The addition would essentially be an extension of the JSON text encoder (albeit implemented in the text sequence encoder). There would be no ambiguity. The parser would always leave it in. Where integrity mechanisms are used, the auto- would need to be turned off and the source responsible for properly terminating inputs to the text sequence encoder. > >I continue to think that the best thing to do is have a recommendation >as to how to handle ambiguities, and point them out. > >Therefore I don't think we should say that the parser MUST strip the >trailing LF, but SHOULD (or MAY not strip it) would be fine, and should >address the concern about alterations to JSON texts that can then affect >cryptographic integrity protection. Thinking more about stripping out the , that won=E2=80=99t always work either for the same reason you have the parser reject non-self-delimited texts that do not end with a . The text sequence encoder could terminate before the is written possibly leaving a added by the source exposed (and removed by a decoder). The parser really can=E2=80=99t know if the JSON encoder or JSON text sequence encoder added a trailing . From nobody Thu Dec 18 08:00:26 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB2C1A8A89 for ; Thu, 18 Dec 2014 08:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3sr8afBTu-N for ; Thu, 18 Dec 2014 08:00:16 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782CA1A1B2C for ; Thu, 18 Dec 2014 08:00:16 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:45587 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Y1dUV-000DiB-P6; Thu, 18 Dec 2014 10:59:51 -0500 Message-ID: <5492F9F7.1070909@bbn.com> Date: Thu, 18 Dec 2014 10:59:51 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Susan Hares , 'Tero Kivinen' , 'Kathleen Moriarty' , charliekaufman@outlook.com References: <074b01d00f31$1712da30$45388e90$@ndzh.com> <21650.47330.158595.209025@fireball.kivinen.iki.fi> <00e601d01ac4$b5b69b60$2123d220$@ndzh.com> In-Reply-To: <00e601d01ac4$b5b69b60$2123d220$@ndzh.com> Content-Type: multipart/alternative; boundary="------------080502050906050203000806" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/W9MMSovHgae0_wvvPbJYAXZo03g Cc: tnadeau@lucidvision.com, secdir , 'Alia Atlas' , wardd@cisco.com, 'Jeffrey Haas' , adrian@olddog.co.uk Subject: Re: [secdir] Security directorate X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 16:00:21 -0000 This is a multi-part message in MIME format. --------------080502050906050203000806 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit SECDIR early review of draft-ietf-i2rs-problem-statement-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 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 is a short document describing the problem being addressed by the I2RS WG, and establishing some requirements for solutions. Section 2 describes the model for I2RS. It calls for using existing transport protocols to provide security, a good statement as part of the base protocol requirements. Looking at Figure 1, it seems that the only paths that are in scope for I2RS are between an I2RS agent and client and between clients. In section 5, authentication, authorization, and integrity are explicitly cited as requirements. This is a good statement of requirements. It might be nice to state whether confidentiality is also perceived as a requirement, or if it explicitly not a requirement. The Security Considerations section is a single paragraph consisting of 2 sentences. It opens with a nice statement about the importance of security in the I2RS context. I think a back pointer to the “secure Control” text would be appropriate. The second sentence says that more investigation is needed to fully define security requirements such as authorization and authentication levels. I don’t know what this last phrase means. Authorization (aka access control) isn’t usually described as having levels per se. Do you mean granularity of access control, or something else. Also, for authentication, there are various mechanisms one can employ, and these may be described as offering varying “levels” of security, but that is an oversimplification in many cases. A clearer description of what the authors are trying to convey here would be good. I also looked briefly at draft-hares-i2rs-security-02. That document begins with a very good discussion of security terminology based on RFC 4949. It also proposes very specific security requirements for communications in the I2RS model. That document calls for confidentiality as a requirement, which further motivates some mention of this security service in the problem statement, even if the statement is equivocal. Two typos I noted: Section 2: measuresments -> measurements Section 5: Such communications must also have its integrity protected. -> Such communications must also be integrity-protected. --------------080502050906050203000806 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

SECDIR early review of draft-ietf-i2rs-problem-statement-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 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 is a short document describing the problem being addressed by the I2RS WG, and establishing some requirements for solutions.

 

Section 2 describes the model for I2RS. It calls for using existing transport protocols to provide security, a good statement as part of the base protocol requirements. Looking at Figure 1, it seems that the only paths that are in scope for I2RS are between an I2RS agent and client and between clients.

In section 5, authentication, authorization, and integrity are explicitly cited as requirements. This is a good statement of requirements. It might be nice to state whether confidentiality is also perceived as a requirement, or if it explicitly not a requirement.

 

The Security Considerations section is a single paragraph consisting of 2 sentences. It opens with a nice statement about the importance of security in the I2RS context. I think a back pointer to the “secure Control” text would be appropriate. The second sentence says that more investigation is needed to fully define security requirements such as authorization and authentication levels. I don’t know what this last phrase means. Authorization (aka access control) isn’t usually described as having levels per se. Do you mean granularity of access control, or something else. Also, for authentication, there are various mechanisms one can employ, and these may be described as offering varying “levels” of security, but that is an oversimplification in many cases. A clearer description of what the authors are trying to convey here would be good.

 

I also looked briefly at draft-hares-i2rs-security-02. That document begins with a very good discussion of security terminology based on RFC 4949. It also proposes very specific security requirements for communications in the I2RS model. That document calls for confidentiality as a requirement, which further motivates some mention of this security service in the problem statement, even if the statement is equivocal.

 

 

Two typos I noted:

 

Section 2: measuresments -> measurements

 

Section 5:

 

Such communications must also have its integrity protected. ->

 

Such communications must also be integrity-protected.

 

 

--------------080502050906050203000806-- From nobody Thu Dec 18 12:03:02 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A8F1AC3D2 for ; Thu, 18 Dec 2014 12:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MvZrsbm27E2 for ; Thu, 18 Dec 2014 12:02:58 -0800 (PST) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.170.25]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42941ABD3E for ; Thu, 18 Dec 2014 12:02:18 -0800 (PST) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 4F4909A7840DA; Thu, 18 Dec 2014 14:02:03 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 3E1AD9A78407B for ; Thu, 18 Dec 2014 14:02:03 -0600 (CST) Received: from [96.231.218.201] (port=56216 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1hGs-0007z8-AS; Thu, 18 Dec 2014 14:02:02 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <548E7FDF.80801@pi.nu> Date: Thu, 18 Dec 2014 15:01:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <02C6C7AC-9D7C-47AD-A0FB-8A116B5DD4D0@ieca.com> References: <548E7FDF.80801@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.218.201 X-Exim-ID: 1Y1hGs-0007z8-AS X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [96.231.218.201]:56216 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/lg9tRligosGQW9FV8BL82xJhJfE Cc: The IESG , draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-mpls-lsp-ping-relay-reply X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 20:03:00 -0000 Roger. I=92ll keep an eye out for a revision. =20 spt On Dec 15, 2014, at 01:29, Loa Andersson wrote: > Sean, >=20 > We had a "wrinkle" on this :( ! Two of the authors discovered (very > late) something that needs to be addressed. >=20 > I asked the AD to send the ducment back to the working group for "more > work". I hope it be a smooth process, and that we'll get the document > timely back on track again. >=20 > Anyhow, I expect that the authors takes care of your comments during = the > "more work" process. >=20 > /Loa >=20 > On 2014-12-14 03:29, Sean Turner wrote: >> Do not be alarmed. I have reviewed this document as part of the >> security directorate=92s 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 >> Version: 06 >> Summary: Ready with some non-security/non-privacy nits. >>=20 >> Ping mechanisms always give me the heebie-jeebies [1] >> because of the security concerns associated with them (i.e., DoS, >> spoofing/hijacking/etc., and unauthorized disclosure). This document >> specifies an extension to the existing ECHO mechanism in RFC 4379 >> and it does nothing to address these concerns in fact it increases = the >> concerns wrt DoS. *BUT* it rightly points this increase exposure out = in >> the security considerations section. It provides remediation = techniques >> similar to those specified in RFC 4379: rate limit and validate = source >> against access list. This draft, unlike RFC 4379, does recommend = that >> operators wishing to not disclose their nodes blank the address out = in >> the TLV. This draft also refers to RFC 4379 for additional security >> considerations. >>=20 >> WARNING - questions and nits follow: >>=20 >> s3 - 1st paragraph: Relayed Echo Reply =93replaces=94 Echo Reply - = does this >> mean you=92re deprecating the use of =93Echo Reply=94? >>=20 >> s4.1: Is the outermost label allowed to be set to 255 to support the >> =93ping=94 mode or must it always be set to 1, 2, etc. to support = =93traceroute" >> mode - as described in RFC 4379 s4.3? I know s5 is just an example >> but it really looks like this extension is just supposed to be for = fault >> isolation. >>=20 >> s4.1 - last paragraph: Does the next initiator put it=92s address in = the stack >> before or after the previous initiator? I assume it=92s after, but I = maybe >> missed that part? Would be good to state that explicitly. >>=20 >> Cheers, >> spt >>=20 >> [1] http://en.wikipedia.org/wiki/Heebie-jeebies_(idiom) >>=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Dec 18 16:43:19 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BAF1ACC72; Thu, 18 Dec 2014 16:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCelmZL39M1L; Thu, 18 Dec 2014 16:43:11 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 668221ACAD8; Thu, 18 Dec 2014 16:43:11 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id F2C0031805C; Thu, 18 Dec 2014 16:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=qZqkJNFfKapsgEGSsxAqnJMkWwM=; b=y0wSuYKxiNi z4kPocj6ffpDMugObfZuz4JQom5SAykuUdPzFPEkHAtEnBdPmzEJkdDhCi/QdwbR hGIaMXQ1m1LPglkBGhjFSO5K0yB2Yg58rwsGge3s7Ui2SSuibeFkK0/dT3y4/WzS I+d1GiSGbGjMGoXH1fibOjfUNPibLsjU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id 90264318059; Thu, 18 Dec 2014 16:43:10 -0800 (PST) Date: Thu, 18 Dec 2014 18:43:10 -0600 From: Nico Williams To: Carl Wallace Message-ID: <20141219004305.GB12662@localhost> References: <20141216174829.GZ3241@localhost> <20141216193707.GE3241@localhost> <20141216213533.GI3241@localhost> <20141217185523.GA3241@localhost> <20141217234113.GH9443@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/l264-DYhOQzlC-oaowexE0PKRWc Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 00:43:12 -0000 On Thu, Dec 18, 2014 at 07:12:34AM -0500, Carl Wallace wrote: > The suggestion is not to tolerate a missing but to not always add > them in the text sequence encoder in the first place. The addition They can be tolerated in the parser. Logging applications that encode sequences correctly might nonetheless be subject to truncation of sequence elements (including RS and trailing LF bytes) while incrementally encoding a sequence, followed by additional elements being added later (again, O_APPEND...). Aside: if we'd never considered truncation we also wouldn't have needed RS bytes, just trailing LF bytes, and optional ones at that (which is exactly what https://stedolan.github.io/jq implements and has for a long time now). The problem with truncation is that there was no way to figure out how to resync a parser, therefore no way to make it tolerate truncation, not without RS, which in turn makes RS-less sequences not so useful for logging applications. We could abandon this, but several people expressed the need for this format only when this was addressed, and I do believe using RS (or similar) is better than not. > would essentially be an extension of the JSON text encoder (albeit > implemented in the text sequence encoder). There would be no ambiguity= . No extensions of the JSON text encoder can be had here, not even notional ones. We're not updating RFC7159, not even implicitly. Off-the-shelf JSON text parsers and encoders must be sufficient to implement JSON text sequence parsers and encoders. > The parser would always leave it in. Where integrity mechanisms are use= d, Whether the parser leaves it in or not is unimportant. What's important is that the parser uses it to detect truncation of JSON texts that can be truncated and still be valid but _different_ from the original. As noted, ambiguities result from this looseness about how the trailing LFs are handled. These are noted in the security considerations section in the upcoming -12. That should suffice. > the auto- would need to be turned off and the source responsible fo= r > properly terminating inputs to the text sequence encoder. Integrity mechanisms are out of scope in this document. > Thinking more about stripping out the , that won=E2=80=99t always w= ork either > for the same reason you have the parser reject non-self-delimited texts > that do not end with a . The text sequence encoder could terminate > before the is written possibly leaving a added by the source > exposed (and removed by a decoder). The parser really can=E2=80=99t kno= w if the > JSON encoder or JSON text sequence encoder added a trailing . When the sequence parser knows that the encoder of a sequence wasn't subject to truncation, then the parser can indeed require and remove the trailing LF. In other cases it can't. As JSON texts can have arbitrary amounts of trailing whitespace, integrity mechanisms are out of scope, and JSON texts have no canonical form (and are subject to being changed when parsed then re-encoded without meaningful modification to the parsed value), there's no need to concern ourselves further with this matter. The upcoming -12 notes the ambiguities and lack of integrity mechanism support. I propose no further changes regarding how and whether to detect if a trailing LF was added by a sequence encoder or not, or whether to pass it to the JSON text parser. Nico --=20 From nobody Fri Dec 19 04:03:26 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3642C1A914C for ; Fri, 19 Dec 2014 04:03:24 -0800 (PST) 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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uU2uvUV4QqEk for ; Fri, 19 Dec 2014 04:03:23 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1EAE1A8F50 for ; Fri, 19 Dec 2014 04:03:22 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id x3so534768qcv.1 for ; Fri, 19 Dec 2014 04:03:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=zIXWKwEdqtvBAH9s6u1GH8YgJuVjansuFNDnJ77220A=; b=dmbr4s/nt5YkhEuBrwOgAgLnG0HgG+PBWYiRDKZ2lxE5JQCYGNGu1GYWL16fd+9g52 tPxTLzlpAYkhP7Wqfzzft13EOnl52cgtJYeOSMLRoBduCj8FKJa9+VdOZpT1MCNIDjZ+ XAJsCgVwo0J518b1nqDGKR9wLtpDr409u4iKwumDXEtMaNNhXTeMA4Li3abn30xq/vRN ORFZLE9Ee3bi8S8xSb0aqAQfyr6H6dYEj0P+7WGFi9Txz9BWVRo+JHeptG8M1YzFlLuU Jk/WHRjss6ThUieit93h+HxDKGU0NEwZQKA+AR0KXQqmiDge7gMJk8Lyal7B638j2aR1 lF+Q== X-Gm-Message-State: ALoCoQlzwlSWAD6/Yzu0KnUj0oY62UJbeEgdy63RFx07pYJ5fq/2GfSPPkA1UvqMs2cw7Sw8ETE+ X-Received: by 10.224.74.207 with SMTP id v15mr12670328qaj.53.1418990601840; Fri, 19 Dec 2014 04:03:21 -0800 (PST) Received: from [192.168.2.39] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id j10sm9306147qai.18.2014.12.19.04.03.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 19 Dec 2014 04:03:21 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Fri, 19 Dec 2014 07:03:18 -0500 From: Carl Wallace To: Nico Williams Message-ID: Thread-Topic: [secdir] secdir review of draft-ietf-json-text-sequence-11 References: <20141216174829.GZ3241@localhost> <20141216193707.GE3241@localhost> <20141216213533.GI3241@localhost> <20141217185523.GA3241@localhost> <20141217234113.GH9443@localhost> <20141219004305.GB12662@localhost> In-Reply-To: <20141219004305.GB12662@localhost> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MMnNblxM8cGxKU001tw0ayyMKD4 Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 12:03:24 -0000 On 12/18/14, 7:43 PM, "Nico Williams" wrote: > > >Integrity mechanisms are out of scope in this document. OK > >The upcoming -12 notes the ambiguities and lack of integrity mechanism >support. I propose no further changes regarding how and whether to >detect if a trailing LF was added by a sequence encoder or not, or >whether to pass it to the JSON text parser. OK From nobody Fri Dec 19 15:58:20 2014 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 2F8D11A90EC; Thu, 18 Dec 2014 15:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1418944289; bh=CFo+vRSujRD6BpTT+Z3fcPhHpXECnowH9+dTwTKXZbU=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=yudoaX6EMmJtcRXc3YuaaNqKb/zdKiDyiWBIol5MeBtqh8l6dpJBUdCI0DKm4pTrg s4KRCSp1ymSb7qBprfzsi6NCnuyR+JS1h77WBdBus+QRt5BiX3GTPAhmFUAFt/ml/s MGfddYmRG3SyXNASX2rvZIxdHjHi15n2QXwKE+uQ= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E718F1A87F1 for ; Thu, 18 Dec 2014 15:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRxJDAuq4lgw for ; Thu, 18 Dec 2014 15:11:08 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5B41A8825 for ; Thu, 18 Dec 2014 15:11:08 -0800 (PST) Received: from eb.bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Y1kDr-0004Bk-En; Thu, 18 Dec 2014 18:11:07 -0500 To: new-work@ietf.org Date: Fri, 19 Dec 2014 00:11:06 +0100 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/hbARvTBCjLo-Pvi14ZYZY7Vlu_o X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/laogLDMObmAvtVXOSSXuLBbwwJQ X-Mailman-Approved-At: Fri, 19 Dec 2014 15:58:17 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Application Security Working Group (until 2015-01-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: Thu, 18 Dec 2014 23:11:29 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Security Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Application Security Working Group: http://www.w3.org/2014/12/webappsec-charter-2015.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 2015-01-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 [2], 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 Wendy Seltzer, team contact and T&S Domain Lead . Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/Security/ [1] http://www.w3.org/2014/Process-20140801/#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Dec 22 00:05:11 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9A91A0178; Mon, 22 Dec 2014 00:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoO8v6-02Dv9; Mon, 22 Dec 2014 00:05:03 -0800 (PST) Received: from COL004-OMC1S8.hotmail.com (col004-omc1s8.hotmail.com [65.55.34.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1141A8A06; Mon, 22 Dec 2014 00:05:02 -0800 (PST) Received: from COL401-EAS127 ([65.55.34.7]) by COL004-OMC1S8.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 22 Dec 2014 00:05:02 -0800 X-TMN: [VRmOhHW1XBStuu8ghKGQnKUNPo2B3vTT] X-Originating-Email: [charliekaufman@outlook.com] Message-ID: From: Charlie Kaufman To: Date: Mon, 22 Dec 2014 00:05:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 thread-index: AdAdsDdxSkc3V7/1QeiWXeAzuAUWTw== Content-Language: en-us X-OriginalArrivalTime: 22 Dec 2014 08:05:02.0001 (UTC) FILETIME=[FCBCF210:01D01DBD] Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0hC3iDhBtSpOsqmh34jcTUcBer4 Cc: draft-ietf-i2rs-architecture.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Secdir review of draft-ietf-i2rs-architecture-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 08:05: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.=A0 = These comments were written primarily for the benefit of the security area directors.=A0 Document editors and WG chairs should treat these comments = just like any other last call comments. As an =93architecture=94 document, this document does not specify the = details that would allow one to review whether the security mechanisms were adequate. The Security Considerations section correctly notes that there = is a need to transport this protocol over something that provides mutual authentication, confidentiality, and integrity to the data. It also = notes that there needs to be some authorization mechanism that configures = which authenticated clients are allowed to make what requests. There is no discussion of where this authorization comes from, and in particular = whether the authorization data can be viewed or manipulated using this protocol, though my sense reading the document is that authorization data would be configured and manipulated by some other mechanism (as would the manipulation of client and server credentials). So I think we need to = wait for the successor document with more meat to judge. That said, I would ask the designers some leading questions of the form =93Have you considered=85=94. Some relate to security and some don=92t. = I=92m not the best person to judge the answers, but I=92m hoping the questions will = kick off some discussion within the working group. It's likely that some of these issues have already been adequately discussed, in which case feel free = to ignore them. This document goes out of its way *not* to specify any security = mechanisms in order to provide flexibility to implementers. That makes sense for a requirements document, but I'm not sure it makes sense for an = architecture document. You are clearly going to need some security mechanisms, and = for clients and agents to interoperate, they need to be standardized. My = guess is that you will end up using SSL with either client certificates or = with some lesser client to agent authentication mechanism inside an SSL connection with only a server certificate. The mechanism you choose will determine the formats of the identity information you get and use to do lookups in your authorization tables. But section 7.1 says the protocol = may need to run over TCP, SCTP, DCCP, and possibly other link types. Do you envision different security mechanisms for the different protocols? In the third paragraph of section 4 (and in some other places), you talk about the I2RS Client acting as a broker forwarding requests for some = other entity, and forwarding some opaque identifier of that requesting entity = to the I2RS Agent for logging. This presumes that the I2RS is configured = with (or has access to) the authorization information that says which = requestors are permitted to do which operations. A useful extension to the protocol would be to be able to forward a requestor-identity string that the = Agent not only logs but also checks for proper authorization before performing = the requested operation. The Agent would need to verify that both the Client = and the client asserted identity of the requestor be authorized to perform = the operation. This relatively simple change to the Agent and the protocol = might permit a considerably simpler client (if this brokered-request behavior = is actually common). Section 1.1 says I2RS is described as an asynchronous programmatic interface. Asynchronous usually means that you can launch operations and then check back later whether they successfully completed. If you want = to execute a second operation only if a first succeeds (or to guarantee the order in which they execute), you need to at some point wait for = operations to complete. There is also substantial overhead in supporting = asynchronous operation in that all transactions need labels so that they can be = queried? Have you done that? A conceptually simpler strategy is to say that since = a client can make multiple parallel connections to an agent that in cases where a client wants asynchronous operation he opens multiple = connections and launches one asynchronous operation on each. The cost is that is has lower performance in cases where there are large numbers of parallel operations tying up lots of connection state. Section 6.2: The restriction that this protocol injects only ephemeral = state seems surprising, especially given that the circumstances under which = the ephemeral state is lost are defined in terms of a network device reboot. Some network devices may not have a clear notion of a reboot, or might = do it so rarely as to render such functionality useless. I was confused by the discussion of agent reboots vs. device reboots. The first paragraph = seems to say that ephemeral state is lost when the device reboots, but 6.2.1 = seems to imply that state is lost when the agent reboots. The sentence =93Just as routing state will usually be removed shortly after the failure is detected=85=94 seems to imply that ephemeral state might be lost when a = client reboots. Have you considered what happens to state when a client = disappears but the agent and server stay around forever. There is an option later = in the document for some sort of timeout, but I would think there would be = some sort of mechanism to guarantee that all ephemeral state disappears eventually unless the requestor is still around implicitly renewing it. Also in 6.2.1, it appears that one piece of state is explicitly not ephemeral... the agent keeps a non-ephemeral list of clients to notify = when ephemeral state is lost. If the client is not accessible, for how long = does the agent continue to try to contact it? Forever? The protocol requires that agents be able to open connections to clients = (in addition to clients being able to open connections to agents). This will introduce lots of challenges. It means the client needs an open port to accept connections, likely an SSL certificate, and will be in trouble if = it is behind a NAT or is mobile and does not have a stable IP address. = Other parts of the spec mention that two entities might have the same client identity. In such cases, it will be tricky for the agent to connect to = "the right instance". It might be better to only allow clients to initiate connections to agents, possibly with some sort of unauthenticated notification from agent to client that initiating such a connection = would be a good idea (to reduce the overhead of the polling that would otherwise = be necessary). My first question when I started reading this document was why do we = need a new protocol. Wouldn't SNMP or NETCONF do this just fine? And there are probably lots of others. Section 3.1 says "There have been many efforts = over the years to improve the access to the information available to the = routing and forwarding system." It would be good to understand why those efforts failed before inventing some new syntax (when it is unlikely the syntax = is what killed previous efforts). Then section 7.1 says the protocol will = be "based on" NETCONF and RESTCONF. What does "based on" mean in this = context? Section 7.8 talks about "collisions", but it wasn't clear (at least to = me) whether these were collisions in the time sense where two requests are = made simultaneously by different clients vs. whether it is a case where once client tries to override the setting of another client. I also wonder whether there are cases where two changes would interact in some way = other than one of them winning, as when two clients each want to increment the bandwidth of some virtual like over which they are both tunneling = traffic (and where the correct result is to add the two increments). The last paragraph of 7.9 says "the protocol will include an explicit = reply to modification or write operations even when they fully succeed". How = does this relate to the asynchronous nature of the protocol? Good luck with this! --Charlie From nobody Mon Dec 22 05:53:15 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F661A8F41 for ; Mon, 22 Dec 2014 05:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3gvVhZgo5Ao for ; Mon, 22 Dec 2014 05:53:12 -0800 (PST) Received: from smtp66.ord1c.emailsrvr.com (smtp66.ord1c.emailsrvr.com [108.166.43.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C211A8F3A for ; Mon, 22 Dec 2014 05:53:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp17.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C0B3A1803FB; Mon, 22 Dec 2014 08:53:11 -0500 (EST) X-Virus-Scanned: OK Received: by smtp17.relay.ord1c.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id 20FC21804B3; Mon, 22 Dec 2014 08:53:10 -0500 (EST) X-Sender-Id: scott@hyperthought.com Received: from [192.168.128.24] (c-76-21-94-29.hsd1.ca.comcast.net [76.21.94.29]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.4.2); Mon, 22 Dec 2014 13:53:11 GMT From: Scott Kelly Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 22 Dec 2014 05:53:09 -0800 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/uZ3jjkZZOfEmLETfRiKs3h3hIxs Subject: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 13:53:14 -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. Here=92s the abstract: This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows reporting of post-repair loss count metrics for a range of RTP applications. Prior to this mechanism, RTCP Sender Reports (SR)/Receiver Reports (RR) = contain, among other things, the cumulative number of packets lost. That = number doesn=92t indicate the data successfully received, because the = receiver can apply repair mechanisms to recover data. This document adds = reporting for post-repair metrics. The security considerations seem complete, but I have one nit. Here=92s = the first sentence: It is believed that this RTCP XR block introduces no new security considerations beyond those described in [RFC3611].=20 Who believes this? I would simply assert this (remove =93It is believed = that=94), and if I wasn=92t comfortable with that, I=92d take that as an = indication that more analysis is required. =97Scott From nobody Mon Dec 22 11:13:06 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A471A6EE7; Mon, 22 Dec 2014 11:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKYDcdyDWAjZ; Mon, 22 Dec 2014 11:12:54 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF531A6F2B; Mon, 22 Dec 2014 11:12:54 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-1b-54981c328734 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id D4.3C.03307.23C18945; Mon, 22 Dec 2014 14:27:14 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 14:12:52 -0500 From: Joel Halpern To: Charlie Kaufman , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-i2rs-architecture-07 Thread-Index: AdAdsDdxSkc3V7/1QeiWXeAzuAUWTwAanowA Date: Mon, 22 Dec 2014 19:12:51 +0000 Message-ID: <6BCE198E4EAEFC4CAB45D75826EFB076032E0198@eusaamb101.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPuK6RzIwQgylL5S2m/T7BYvHp719m ixl/JjJbfFj4kMWBxWPJkp9MHptfv2D2+HL5M1sAcxSXTUpqTmZZapG+XQJXxrEdE1kKlgVW TNmv38C4xKmLkZNDQsBE4uS7o0wQtpjEhXvr2boYuTiEBI4wShze/JAVwlnOKLFs1j5GkCo2 AT2Jte8fg3WICIRLPHvWzQ5SxCzQwygx4eVsdpCEsICtxJwPT6CK7CSuT93GDGEbSZx5uIYV xGYRUJU4+X0/WJxXwFfiwpXDYAuEBGwkbuzpYgGxOYHmHPpxBizOCHTe91NrwGYyC4hL3Hoy H+psAYkle84zQ9iiEi8f/2OFsBUl9vVPZ4eo15O4MXUKG4StLbFs4WuovYISJ2c+YZnAKDYL ydhZSFpmIWmZhaRlASPLKkaO0uLUstx0I4NNjMAoOibBpruDcc9Ly0OMAhyMSjy8GySmhwix JpYVV+YeYpTmYFES551VOy9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+O6PzGLlsSzbt6q tujjpqvPRL/4//TR4xCcMKG60UnIPH6/Gm924sSTwlc/Gy0vmSL4Wf4tv375qwvtJTw2q9ct YUg97Vn1qveqnjBzqG7dTKuDDw1/R569t2z/05X3qqYeZbrycefJjrqT7qLxixz3WwUlTPUx 6MxPD+/f4x306eMilitTM6cosRRnJBpqMRcVJwIADl7bhoMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qLUKwQGkwIBJ0U8poXZqP5-7B-g Cc: "draft-ietf-i2rs-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-i2rs-architecture-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 19:13:01 -0000 Commenting on only two aspects of your note, as the rest require some thoug= ht, and probably some comments from the WG. With regard to the question of whether the I2RS Agent should be validating = the credentials of the original reuqestor identity, the WG discussed this, = and decided explicitly not to do that. The relationship between the origin= al requestor and the I2RS client was concluded to be the business of the cl= ient, and the agent is to accept the client's word for the validity of the = operation. A driver for this is that there may well be administrative doma= in boundaries such that the I2RS Agent does not even have access to the aut= horization information for the original requestor. With regard to the question of whetehr a new protocol is needed, the premis= e for the archtiecture is to spell out the behavioral requirements, and the= n the WG will separately examine protocols to meet the need. The working g= roup has done a first pass at that, and the tentative conclusion is that Re= stConf with YANG should be able to meet the needs. However, the details ar= e still beign worked out. The archtiecture tries not to take a stance on th= is matter, since it is up to the working group. Yours, Joel=20 > -----Original Message----- > From: Charlie Kaufman [mailto:charliekaufman@outlook.com]=20 > Sent: Monday, December 22, 2014 3:05 AM > To: secdir@ietf.org > Cc: draft-ietf-i2rs-architecture.all@tools.ietf.org; iesg@ietf.org > Subject: Secdir review of draft-ietf-i2rs-architecture-07 >=20 > I have reviewed this document as part of the security=20 > directorate's ongoing effort to review all IETF documents=20 > being processed by the IESG.=A0 These comments were written=20 > primarily for the benefit of the security area directors.=A0=20 > Document editors and WG chairs should treat these comments=20 > just like any other last call comments. >=20 > As an "architecture" document, this document does not specify=20 > the details that would allow one to review whether the=20 > security mechanisms were adequate. The Security=20 > Considerations section correctly notes that there is a need=20 > to transport this protocol over something that provides=20 > mutual authentication, confidentiality, and integrity to the=20 > data. It also notes that there needs to be some authorization=20 > mechanism that configures which authenticated clients are=20 > allowed to make what requests. There is no discussion of=20 > where this authorization comes from, and in particular=20 > whether the authorization data can be viewed or manipulated=20 > using this protocol, though my sense reading the document is=20 > that authorization data would be configured and manipulated=20 > by some other mechanism (as would the manipulation of client=20 > and server credentials). So I think we need to wait for the=20 > successor document with more meat to judge. >=20 > That said, I would ask the designers some leading questions=20 > of the form "Have you considered.". Some relate to security=20 > and some don't. I'm not the best person to judge the answers,=20 > but I'm hoping the questions will kick off some discussion=20 > within the working group. It's likely that some of these=20 > issues have already been adequately discussed, in which case=20 > feel free to ignore them. >=20 > This document goes out of its way *not* to specify any=20 > security mechanisms in order to provide flexibility to=20 > implementers. That makes sense for a requirements document,=20 > but I'm not sure it makes sense for an architecture document.=20 > You are clearly going to need some security mechanisms, and=20 > for clients and agents to interoperate, they need to be=20 > standardized. My guess is that you will end up using SSL with=20 > either client certificates or with some lesser client to=20 > agent authentication mechanism inside an SSL connection with=20 > only a server certificate. The mechanism you choose will=20 > determine the formats of the identity information you get and=20 > use to do lookups in your authorization tables. But section=20 > 7.1 says the protocol may need to run over TCP, SCTP, DCCP,=20 > and possibly other link types. Do you envision different=20 > security mechanisms for the different protocols? >=20 > In the third paragraph of section 4 (and in some other=20 > places), you talk about the I2RS Client acting as a broker=20 > forwarding requests for some other entity, and forwarding=20 > some opaque identifier of that requesting entity to the I2RS=20 > Agent for logging. This presumes that the I2RS is configured=20 > with (or has access to) the authorization information that=20 > says which requestors are permitted to do which operations. A=20 > useful extension to the protocol would be to be able to=20 > forward a requestor-identity string that the Agent not only=20 > logs but also checks for proper authorization before=20 > performing the requested operation. The Agent would need to=20 > verify that both the Client and the client asserted identity=20 > of the requestor be authorized to perform the operation. This=20 > relatively simple change to the Agent and the protocol might=20 > permit a considerably simpler client (if this=20 > brokered-request behavior is actually common). >=20 > Section 1.1 says I2RS is described as an asynchronous=20 > programmatic interface. Asynchronous usually means that you=20 > can launch operations and then check back later whether they=20 > successfully completed. If you want to execute a second=20 > operation only if a first succeeds (or to guarantee the order=20 > in which they execute), you need to at some point wait for=20 > operations to complete. There is also substantial overhead in=20 > supporting asynchronous operation in that all transactions=20 > need labels so that they can be queried? > Have you done that? A conceptually simpler strategy is to say=20 > that since a client can make multiple parallel connections to=20 > an agent that in cases where a client wants asynchronous=20 > operation he opens multiple connections and launches one=20 > asynchronous operation on each. The cost is that is has lower=20 > performance in cases where there are large numbers of=20 > parallel operations tying up lots of connection state. >=20 > Section 6.2: The restriction that this protocol injects only=20 > ephemeral state seems surprising, especially given that the=20 > circumstances under which the ephemeral state is lost are=20 > defined in terms of a network device reboot. > Some network devices may not have a clear notion of a reboot,=20 > or might do it so rarely as to render such functionality=20 > useless. I was confused by the discussion of agent reboots=20 > vs. device reboots. The first paragraph seems to say that=20 > ephemeral state is lost when the device reboots, but 6.2.1=20 > seems to imply that state is lost when the agent reboots. The=20 > sentence "Just as routing state will usually be removed=20 > shortly after the failure is detected." seems to imply that=20 > ephemeral state might be lost when a client reboots. Have you=20 > considered what happens to state when a client disappears but=20 > the agent and server stay around forever. There is an option=20 > later in the document for some sort of timeout, but I would=20 > think there would be some sort of mechanism to guarantee that=20 > all ephemeral state disappears eventually unless the=20 > requestor is still around implicitly renewing it. >=20 > Also in 6.2.1, it appears that one piece of state is=20 > explicitly not ephemeral... the agent keeps a non-ephemeral=20 > list of clients to notify when ephemeral state is lost. If=20 > the client is not accessible, for how long does the agent=20 > continue to try to contact it? Forever? >=20 > The protocol requires that agents be able to open connections=20 > to clients (in addition to clients being able to open=20 > connections to agents). This will introduce lots of=20 > challenges. It means the client needs an open port to accept=20 > connections, likely an SSL certificate, and will be in=20 > trouble if it is behind a NAT or is mobile and does not have=20 > a stable IP address. Other parts of the spec mention that two=20 > entities might have the same client identity. In such cases,=20 > it will be tricky for the agent to connect to "the right=20 > instance". It might be better to only allow clients to=20 > initiate connections to agents, possibly with some sort of=20 > unauthenticated notification from agent to client that=20 > initiating such a connection would be a good idea (to reduce=20 > the overhead of the polling that would otherwise be necessary). >=20 > My first question when I started reading this document was=20 > why do we need a new protocol. Wouldn't SNMP or NETCONF do=20 > this just fine? And there are probably lots of others.=20 > Section 3.1 says "There have been many efforts over the years=20 > to improve the access to the information available to the=20 > routing and forwarding system." It would be good to=20 > understand why those efforts failed before inventing some new=20 > syntax (when it is unlikely the syntax is what killed=20 > previous efforts). Then section 7.1 says the protocol will be=20 > "based on" NETCONF and RESTCONF. What does "based on" mean in=20 > this context? >=20 > Section 7.8 talks about "collisions", but it wasn't clear (at=20 > least to me) whether these were collisions in the time sense=20 > where two requests are made simultaneously by different=20 > clients vs. whether it is a case where once client tries to=20 > override the setting of another client. I also wonder whether=20 > there are cases where two changes would interact in some way=20 > other than one of them winning, as when two clients each want=20 > to increment the bandwidth of some virtual like over which=20 > they are both tunneling traffic (and where the correct result=20 > is to add the two increments). >=20 > The last paragraph of 7.9 says "the protocol will include an=20 > explicit reply to modification or write operations even when=20 > they fully succeed". How does this relate to the asynchronous=20 > nature of the protocol? >=20 > Good luck with this! >=20 > --Charlie > = From nobody Mon Dec 22 22:14:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525F91A00C0; Mon, 22 Dec 2014 22:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UIUPZDHDsUU; Mon, 22 Dec 2014 22:14:43 -0800 (PST) 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 552011ACD79; Mon, 22 Dec 2014 22:14:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQJ32872; Tue, 23 Dec 2014 06:14:41 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 23 Dec 2014 06:14:41 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.3]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 23 Dec 2014 14:14:37 +0800 From: "Zhangdacheng (Dacheng)" To: "Adam W. Montville" Thread-Topic: [secdir] Secdir review of draft-ietf-mile-enum-reference-format-10 Thread-Index: AQHQFCyAVFkOFbI4vE6cR42dFpdb55yLsAOAgBEW1ZA= Date: Tue, 23 Dec 2014 06:14:36 +0000 Message-ID: References: <6BAB7B9A-1A70-4957-ADC2-1836F22A4219@cisco.com> <6A8E604C-DC8C-410E-A2F4-79B401FD0515@gmail.com> In-Reply-To: <6A8E604C-DC8C-410E-A2F4-79B401FD0515@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/oDSJToIz694UPdiO9xBThfx4hc4 Cc: The IESG , "draft-ietf-mile-enum-reference-format.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mile-enum-reference-format-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 06:14:45 -0000 SGksIEFkYW06DQoNClRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXBseS4gSSBoYXZlIG5vIGFkZGl0 aW9uYWwgY29tbWVudHMgbm93Lg0KDQpDaGVlcnMNCg0KRGFjaGVuZw0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBZGFtIFcuIE1vbnR2aWxsZSBbbWFpbHRvOmFkYW0udy5t b250dmlsbGVAZ21haWwuY29tXQ0KPiBTZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMTMsIDIwMTQg MToxNiBBTQ0KPiBUbzogWmhhbmdkYWNoZW5nIChEYWNoZW5nKQ0KPiBDYzogc2VjZGlyQGlldGYu b3JnOyBUaGUgSUVTRzsNCj4gZHJhZnQtaWV0Zi1taWxlLWVudW0tcmVmZXJlbmNlLWZvcm1hdC5h bGxAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzZWNkaXJdIFNlY2RpciByZXZpZXcg b2YgZHJhZnQtaWV0Zi1taWxlLWVudW0tcmVmZXJlbmNlLWZvcm1hdC0xMA0KPiANCj4gSGkgRGFj aGVuZywNCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXfigKZyZXNwb25zZXMgaW5saW5l Lg0KPiANCj4gQWRhbQ0KPiANCj4gPiBPbiBEZWMgOSwgMjAxNCwgYXQgOTo1MCBQTSwgWmhhbmdk YWNoZW5nIChEYWNoZW5nKQ0KPiA8emhhbmdkYWNoZW5nQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+ DQo+ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJp dHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nDQo+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9j dW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UNCj4gY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEg ZGlyZWN0b3JzLg0KPiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0 IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkNCj4gb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRz Lg0KPiA+DQo+ID4gVGhpcyBkb2N1bWVudCBpcyBlc3RhYmxpc2hpbmcgYSBjb250YWluZXIgZm9y IHB1YmxpY2x5IGF2YWlsYWJsZSBlbnVtZXJhdGlvbg0KPiB2YWx1ZXMgdG8gYmUgaW5jbHVkZWQg aW4gYW4gSU9ERUYgW0lPREVGXSBkb2N1bWVudC4gU2V2ZXJhbCBxdWVzdGlvbnMgYWJvdXQNCj4g dGhlIHByb3Bvc2VkIHNvbHV0aW9uIGFyZSBsaXN0ZWQgYXMgZm9sbG93cy4NCj4gPiAxKQlJbiB0 aGlzIHNwZWNpZmljYXRpb24sIGEgZ2l2ZW4gZW51bWVyYXRpb24gaXMgdW5pcXVlbHkgaWRlbnRp ZmllZCBieSB0aGUNCj4gc3BlY0luZGV4IGF0dHJpYnV0ZS4gSG93ZXZlciB0aGUgdXNhZ2Ugb2Yg SUQgaXMgbm90IGNsZWFybHkgaW50cm9kdWNlZC4gSW4gdGhlDQo+IHNlY3VyaXR5IGNvbnNpZGVy YXRpb24gc2VjdGlvbiwgaXQgaXMgbWVudGlvbmVkIHRoYXQgdGhlIG1pc3MtbWF0Y2ggYmV0d2Vl bg0KPiB0aGUgaW5kZXggYW5kIHRoZSBJRCBtYXkgY2F1c2UgcHJvYmxlbS4gQ291bGQgeW91IHBs ZWFzZSBnaXZlIG1lIHNvbWUgY2x1ZXM/DQo+IA0KPiBUaGUgZW51bWVyYXRpb24gc3BlY2lmaWNh dGlvbiBpcyBpZGVudGlmaWVkLCBzbyB0aGF0IHRoZSBJRCBleHByZXNzZWQgaW4gYSBnaXZlbg0K PiBJT0RFRiAobm90ZSB2MiBub3QgdjEpIGlzIHVuZGVyc3Rvb2QuICBUaGUgSUQgaXMgYSByZWZl cmVuY2UgdG8gYSBzZXQgb2YgZnVydGhlcg0KPiBpbmZvcm1hdGlvbiB0byBiZSBhY3F1aXJlZCB0 aHJvdWdoIG90aGVyIG1lYW5zLiAgQXMgYW4gZXhhbXBsZSwgZGlzY292ZXJlZA0KPiB2dWxuZXJh YmlsaXRpZXMgYXJlIG9mdGVuIGdpdmVuIGEgQ29tbW9uIFZ1bG5lcmFiaWxpdHkgRW51bWVyYXRp b24gKENWRSkNCj4gaWRlbnRpZmllci4gIFRoaXMgSUQgd291bGQgYmUgaW4gdGhlIDxpb2RlZjpl bnVtOklEPiBlbGVtZW50LCBhbmQgdGhlDQo+IHNwZWNpZmljYXRpb24gZm9yIHRoYXQgSUTigJlz IGZvcm1hdCBpcyB3aGF0IGlzIHBvaW50ZWQgdG8gYnkgdGhlIElBTkEgcmVnaXN0cnkuDQo+IA0K PiANCj4gPiAyKQlXaGVyZSBpcyBzZWN0aW9uIDIuMj8NCj4gDQo+IEdvb2QgY2F0Y2gsIHRoYW5r IHlvdS4NCj4gDQo+ID4gMykJSW4gdGhlIGFic3RyYWN0LCBpdCBpcyBzdGF0ZWQgdGhhdCAiVGhp cyBtZW1vIGVzdGFibGlzaGVzIGEgc3RhbmQtYWxvbmUNCj4gZGF0YSBmb3JtYXQgdG8gaW5jbHVk ZSBib3RoIHRoZSBleHRlcm5hbCBzcGVjaWZpY2F0aW9uIGFuZCBzcGVjaWZpYyBlbnVtZXJhdGlv bg0KPiB2YWx1ZSwuIEhvd2V2ZXIsIEkgZGlkbid0IGZpbmQgdGhlIHNwZWNpZmljIGVudW1lcmF0 aW9uIHZhbHVlIGluIHRoZSBleGFtcGxlDQo+IHByb3ZpZGVkIGluIFNlY3Rpb24gMi4xOg0KPiA+ ICIgICAgICA8aW9kZWY6UmVmZXJlbmNlPg0KPiA+ICAgICAgICAgPGlvZGVmLWVudW06UmVmZXJl bmNlTmFtZSBzcGVjSW5kZXg9IjEiPg0KPiA+ICAgICAgICAgICAgPGlvZGVmLWVudW06SUQ+Q1hJ LTEyMzQtWFlaPC9pb2RlZi1lbnVtOklEPg0KPiA+ICAgICAgICAgPC9pb2RlZi1lbnVtOlJlZmVy ZW5jZU5hbWU+DQo+ID4gICAgICAgICA8aW9kZWY6VVJMPmh0dHA6Ly9jeGkuZXhhbXBsZS5jb208 L2lvZGVmOlVSTD4NCj4gPiAgICAgICAgIDxpb2RlZjpEZXNjcmlwdGlvbj5Gb288L2lvZGVmOkRl c2NyaXB0aW9uPg0KPiA+ICAgICAgPC9pb2RlZjpSZWZlcmVuY2U+DQo+ID4g4oCcDQo+IA0KPiBU aGF0IHNlbnRlbmNlIHNob3VsZCBwcm9iYWJseSByZWFkIChlbXBoYXNpcyBhZGRlZCk6IFRoaXMg bWVtbyBlc3RhYmxpc2hlcw0KPiBhIHN0YW5kLWFsb25lIGRhdGEgZm9ybWF0IHRvIGluY2x1ZGUg Ym90aCB0aGUgZXh0ZXJuYWwgc3BlY2lmaWNhdGlvbiBhbmQNCj4gc3BlY2lmaWMgZW51bWVyYXRp b24gKmlkZW50aWZpY2F0aW9uKiB2YWx1ZS4NCj4gDQo+ID4gQ2hlZXJzDQo+ID4NCj4gPiBEYWNo ZW5nDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IHNlY2RpciBtYWlsaW5nIGxpc3QNCj4gPiBzZWNkaXJAaWV0Zi5vcmcNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpcg0KPiA+IHdpa2k6IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2VjRGlyUmV2aWV3DQoNCg== From nobody Tue Dec 23 07:00:13 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B3F1ACF18; Tue, 23 Dec 2014 07:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIsssgZRgh6T; Tue, 23 Dec 2014 07:00:05 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E20F61ACF12; Tue, 23 Dec 2014 07:00:04 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Charlie Kaufman'" , References: In-Reply-To: Date: Tue, 23 Dec 2014 10:00:03 -0500 Message-ID: <007701d01ec1$21c67500$65535f00$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEpOfrZTIkE5qJcJWMsTwMBawRKtp3rDf2w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vmn-zz2Qn3VVOsByJZhiJQ4LcFA Cc: draft-ietf-i2rs-architecture.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-i2rs-architecture-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 15:00:07 -0000 Charlie Kaufman: Thank you for this timely review. I will respond after I have studied = this response a bit. =20 Sue=20 -----Original Message----- From: Charlie Kaufman [mailto:charliekaufman@outlook.com]=20 Sent: Monday, December 22, 2014 3:05 AM To: secdir@ietf.org Cc: draft-ietf-i2rs-architecture.all@tools.ietf.org; iesg@ietf.org Subject: Secdir review of draft-ietf-i2rs-architecture-07 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG.=A0 = These comments were written primarily for the benefit of the security area directors.=A0 Document editors and WG chairs should treat these comments = just like any other last call comments. As an =93architecture=94 document, this document does not specify the = details that would allow one to review whether the security mechanisms were adequate. The Security Considerations section correctly notes that there = is a need to transport this protocol over something that provides mutual authentication, confidentiality, and integrity to the data. It also = notes that there needs to be some authorization mechanism that configures = which authenticated clients are allowed to make what requests. There is no discussion of where this authorization comes from, and in particular = whether the authorization data can be viewed or manipulated using this protocol, though my sense reading the document is that authorization data would be configured and manipulated by some other mechanism (as would the manipulation of client and server credentials). So I think we need to = wait for the successor document with more meat to judge. That said, I would ask the designers some leading questions of the form =93Have you considered=85=94. Some relate to security and some don=92t. = I=92m not the best person to judge the answers, but I=92m hoping the questions will = kick off some discussion within the working group. It's likely that some of these issues have already been adequately discussed, in which case feel free = to ignore them. This document goes out of its way *not* to specify any security = mechanisms in order to provide flexibility to implementers. That makes sense for a requirements document, but I'm not sure it makes sense for an = architecture document. You are clearly going to need some security mechanisms, and = for clients and agents to interoperate, they need to be standardized. My = guess is that you will end up using SSL with either client certificates or = with some lesser client to agent authentication mechanism inside an SSL connection with only a server certificate. The mechanism you choose will determine the formats of the identity information you get and use to do lookups in your authorization tables. But section 7.1 says the protocol = may need to run over TCP, SCTP, DCCP, and possibly other link types. Do you envision different security mechanisms for the different protocols? In the third paragraph of section 4 (and in some other places), you talk about the I2RS Client acting as a broker forwarding requests for some = other entity, and forwarding some opaque identifier of that requesting entity = to the I2RS Agent for logging. This presumes that the I2RS is configured = with (or has access to) the authorization information that says which = requestors are permitted to do which operations. A useful extension to the protocol would be to be able to forward a requestor-identity string that the = Agent not only logs but also checks for proper authorization before performing = the requested operation. The Agent would need to verify that both the Client = and the client asserted identity of the requestor be authorized to perform = the operation. This relatively simple change to the Agent and the protocol = might permit a considerably simpler client (if this brokered-request behavior = is actually common). Section 1.1 says I2RS is described as an asynchronous programmatic interface. Asynchronous usually means that you can launch operations and then check back later whether they successfully completed. If you want = to execute a second operation only if a first succeeds (or to guarantee the order in which they execute), you need to at some point wait for = operations to complete. There is also substantial overhead in supporting = asynchronous operation in that all transactions need labels so that they can be = queried? Have you done that? A conceptually simpler strategy is to say that since = a client can make multiple parallel connections to an agent that in cases where a client wants asynchronous operation he opens multiple = connections and launches one asynchronous operation on each. The cost is that is has lower performance in cases where there are large numbers of parallel operations tying up lots of connection state. Section 6.2: The restriction that this protocol injects only ephemeral = state seems surprising, especially given that the circumstances under which = the ephemeral state is lost are defined in terms of a network device reboot. Some network devices may not have a clear notion of a reboot, or might = do it so rarely as to render such functionality useless. I was confused by the discussion of agent reboots vs. device reboots. The first paragraph = seems to say that ephemeral state is lost when the device reboots, but 6.2.1 = seems to imply that state is lost when the agent reboots. The sentence =93Just as routing state will usually be removed shortly after the failure is detected=85=94 seems to imply that ephemeral state might be lost when a = client reboots. Have you considered what happens to state when a client = disappears but the agent and server stay around forever. There is an option later = in the document for some sort of timeout, but I would think there would be = some sort of mechanism to guarantee that all ephemeral state disappears eventually unless the requestor is still around implicitly renewing it. Also in 6.2.1, it appears that one piece of state is explicitly not ephemeral... the agent keeps a non-ephemeral list of clients to notify = when ephemeral state is lost. If the client is not accessible, for how long = does the agent continue to try to contact it? Forever? The protocol requires that agents be able to open connections to clients = (in addition to clients being able to open connections to agents). This will introduce lots of challenges. It means the client needs an open port to accept connections, likely an SSL certificate, and will be in trouble if = it is behind a NAT or is mobile and does not have a stable IP address. = Other parts of the spec mention that two entities might have the same client identity. In such cases, it will be tricky for the agent to connect to = "the right instance". It might be better to only allow clients to initiate connections to agents, possibly with some sort of unauthenticated notification from agent to client that initiating such a connection = would be a good idea (to reduce the overhead of the polling that would otherwise = be necessary). My first question when I started reading this document was why do we = need a new protocol. Wouldn't SNMP or NETCONF do this just fine? And there are probably lots of others. Section 3.1 says "There have been many efforts = over the years to improve the access to the information available to the = routing and forwarding system." It would be good to understand why those efforts failed before inventing some new syntax (when it is unlikely the syntax = is what killed previous efforts). Then section 7.1 says the protocol will = be "based on" NETCONF and RESTCONF. What does "based on" mean in this = context? Section 7.8 talks about "collisions", but it wasn't clear (at least to = me) whether these were collisions in the time sense where two requests are = made simultaneously by different clients vs. whether it is a case where once client tries to override the setting of another client. I also wonder whether there are cases where two changes would interact in some way = other than one of them winning, as when two clients each want to increment the bandwidth of some virtual like over which they are both tunneling = traffic (and where the correct result is to add the two increments). The last paragraph of 7.9 says "the protocol will include an explicit = reply to modification or write operations even when they fully succeed". How = does this relate to the asynchronous nature of the protocol? Good luck with this! --Charlie From nobody Wed Dec 24 07:52:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E72F1A8A83 for ; Wed, 24 Dec 2014 07:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4oLh9n6aHQT for ; Wed, 24 Dec 2014 07:52:53 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CD81A8A82 for ; Wed, 24 Dec 2014 07:52:52 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id u10so7072309lbd.34 for ; Wed, 24 Dec 2014 07:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=QWAfPcpXj0NTftADcDUXPmhuQb59j9a3u+9hnz8vitI=; b=G4D+U9n5P6xFyTQ8dQW7/mYU3yVeXIzdhc/IZ32/L/T77IwK339rUdc/cBHSfNWuBC rCX8inZj+7m0WJc6SegMc+1mKmHd6oVAYzdcklmaWZLmr6v8e4ySgpYeslS+NQdvjxMY s+vcVfnnuOyZ4rFcpy1iXEHd/3GDTRliFU1OMLxQ0giAhSlJoMw0q0vXAu6EPApwVOCz V+b+km7TCZYQJt7zg4LYrt8iRmX2gConZHsCY0+e8hKkyjdZr63b5z+sVAoEWHXmTk7q qY/UyP5X6BxGoBTsN9EgaSzqRTUWniDqvPuewbHpm3hU7RiiUGPije4tgCktn4jhsHC2 QbQw== MIME-Version: 1.0 X-Received: by 10.112.162.226 with SMTP id yd2mr34719293lbb.1.1419436371061; Wed, 24 Dec 2014 07:52:51 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Wed, 24 Dec 2014 07:52:50 -0800 (PST) Date: Wed, 24 Dec 2014 15:52:50 +0000 X-Google-Sender-Auth: FY8iQ_6CmQSkUiNSWSGi9Mf1LMc Message-ID: From: Phillip Hallam-Baker To: "secdir@ietf.org" Content-Type: multipart/alternative; boundary=089e0112c86cadb2c0050af84892 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/dUEKDgN0FrJEqfWhqAiMXElCnFE Subject: [secdir] SECDIR Review of draft-ietf-pce-rfc7150bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 15:52:54 -0000 --089e0112c86cadb2c0050af84892 Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is making an essentially syntactic modification to an existing specification so that the suite of specifications applies a uniform approach to extension syntax. As such, the proposal does not raise new security concerns beyond the normal concerns raised by syntax. One concern that is raised is the risk of attack through construction of an attribute with a Tag-Length-Value such that the specified length is invalid being either negative (in signed arithmetic) or greater than the size of the enclosing construct. While both concerns can be avoided through appropriate coding techniques, a note to remind implementers that caution is required is appropriate. --089e0112c86cadb2c0050af84892 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have review= ed this document as part of the security directorate's ongoing effort t= o review all IETF documents being processed by the IESG. These comments wer= e written primarily for the benefit of the security area directors. Documen= t editors and WG chairs should treat these comments just like any other las= t call comments.


The document i= s making an essentially syntactic modification to an existing specification= so that the suite of specifications applies a uniform approach to extensio= n syntax.
As such, th= e proposal does not raise new security concerns beyond the normal concerns = raised by syntax.

One= concern that is raised is the risk of attack through construction of an at= tribute with a Tag-Length-Value such that the specified length is invalid b= eing either negative (in signed arithmetic) or greater than the size of the= enclosing construct.

While both concerns can be avoided through appropriate coding techniques, = a note to remind implementers that caution is required is appropriate.
--089e0112c86cadb2c0050af84892-- From nobody Wed Dec 24 12:43:09 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6200C1A1AA1 for ; Wed, 24 Dec 2014 12:43:08 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxaTE3Lo2Vuv for ; Wed, 24 Dec 2014 12:43:07 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8561A1A97 for ; Wed, 24 Dec 2014 12:43:06 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id c9so6063195qcz.24 for ; Wed, 24 Dec 2014 12:43:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=5vgHXLYTDb74R5JbtC68jWdgPWQtUEcfGbI2UmdNOxE=; b=YXHnPsSVJHf47WUo2xhIecr2CqcUDEte8e/mgl02bMlTzQoDZG9XVqsKrn/WnW6lFd RZJ9OOvQfuxVyO4PJ1uqbYVLHNyugtkyvrdyoArwGCSD0ob4D57qyANOCpcsEoYTZxdn olgEIcB/MhxVIY/Ya/YkaT6+xwgOTqThNlhymQDDINexrx/X5F0Yr45JW5wVeIUTkzB/ 1k3bKeduGaU5Z6zCDu8sci3CG02m/WL+h4f0eDqfvcBr1X+f7yx3Nw5WBTdNYg0CrpVQ pJR+zdx67QUshC2SvPL3+6XGmkKxnX9FaV/NTOVFLPa6jqqIty9Q2jXavSdrvo0Sy/1Q IQuA== X-Gm-Message-State: ALoCoQlKwi8aJnDQPbygK5WYICUnQfQCLI0ftW7ATIrePt4zeoxGoH1eeO2cTZ8M4ANKQM3hXtMR X-Received: by 10.224.135.193 with SMTP id o1mr57365537qat.97.1419453786199; Wed, 24 Dec 2014 12:43:06 -0800 (PST) Received: from [192.168.1.8] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id g103sm1430206qgd.41.2014.12.24.12.43.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Dec 2014 12:43:05 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.4.7.141117 Date: Wed, 24 Dec 2014 15:42:59 -0500 From: Carl Wallace To: Nico Williams Message-ID: Thread-Topic: [secdir] secdir review of draft-ietf-json-text-sequence-11 References: <20141216174829.GZ3241@localhost> <20141216193707.GE3241@localhost> <20141216213533.GI3241@localhost> <20141217185523.GA3241@localhost> <20141217234113.GH9443@localhost> <20141219004305.GB12662@localhost> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Rko934eBeaDNGookRBBfnfjAUT8 Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 20:43:08 -0000 The new text in the security considerations creates a misimpression that signature problems require =E2=80=9Crepeated parsing and re-encoding=E2=80=9D. I sugge= st the following mods to the current text to remove this misimpression: Current: Repeated parsing and re-encoding of a JSON text sequence can result in the addition (or stripping) of trailing LF bytes from (to) individual sequence element JSON texts. This can break signature validation. JSON has no canonical form for JSON texts, therefore neither does the JSON text sequence format. Suggested: Encoding a JSON text sequence will result in the addition of a trailing LF byte to individual sequence element JSON texts. This can break signature validation. JSON has no canonical form for JSON texts, therefore neither does the JSON text sequence format. On 12/19/14, 7:03 AM, "Carl Wallace" wrote: >On 12/18/14, 7:43 PM, "Nico Williams" wrote: > >> >> >>Integrity mechanisms are out of scope in this document. > >OK > >> >>The upcoming -12 notes the ambiguities and lack of integrity mechanism >>support. I propose no further changes regarding how and whether to >>detect if a trailing LF was added by a sequence encoder or not, or >>whether to pass it to the JSON text parser. > >OK From nobody Wed Dec 24 13:06:01 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E86E1A1AD2; Wed, 24 Dec 2014 13:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_iko-tem06Q; Wed, 24 Dec 2014 13:05:56 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74041A1ADC; Wed, 24 Dec 2014 13:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4028; q=dns/txt; s=iport; t=1419455155; x=1420664755; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=Dqxtfzzh+nv+IW/iZm2wn7InGswxITiLopoM5hvWJEg=; b=Y9kwtdUOeoxpCaH3c3gNRnc+r6suSVa5JLT1iSYXQy9YYB4yYz3UNa9E moaxqlS0pqf1RIJ6fOb1XwFv/eLRlSCFgn4zU1oTTZGz4APJQMmaILT7V 6xBGnAm5Z6b334sxxv1nYa5NCNQ/0fl7jlzMLf/r2jNKi0cgECa0fywM/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8KANMpm1StJV2a/2dsb2JhbABRAQmDBrVBAQEBAQEBBQF3mEUWAQEBAQF9hTl9FAEQHQSIDctyAQEBAQEBAQMBAQEBAQEBAQEZhgCJFgGDeIETBYlLjT2RUCKEDx0EgnABAQE X-IronPort-AV: E=Sophos;i="5.07,639,1413244800"; d="scan'208";a="108232843" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 24 Dec 2014 21:05:54 +0000 Received: from stealth-10-32-244-212.cisco.com (stealth-10-32-244-212.cisco.com [10.32.244.212]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBOL5raq014177; Wed, 24 Dec 2014 21:05:54 GMT From: Brian Weis Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 24 Dec 2014 13:05:11 -0800 To: The IESG , secdir@ietf.org, draft-ietf-radext-dynamic-discovery.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/uYEqi_idIGC0ojUEv9ECIWnI2rc Subject: [secdir] Secdir review of draft-ietf-radext-dynamic-discovery-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 21:05:58 -0000 I have reviewed this document as part of the security directorate=92s = 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 specifies a means to find authoritative RADIUS servers for = a given realm. This can be useful when authenticating/authorizing = devices within a roaming consortium (e.g., eduroam). An authoritative = RADIUS client trying to authenticate/authorize a host or perform = accounting for that host finds a RADIUS server by querying DNS for = service records defined in this document. Once a candidate sever has = been found in DNS, the querier initiates a RADIUS protocol to it = protected by TLS, authorizes it based on information in its certificate, = and then RADIUS happens in the usual fashion. The document is almost = ready for publication, in my opinion. There=92s not much background given, and having an overview of the = solution architecture in the Introduction would be useful. I.e., a = description and picture showing the actors and the communication flows = between them. I don=92t have complete confidence that I correctly = understood which actors are involved in the RASIUS/TLS transaction -- in = some sections it seems that RADIUS clients are initiating requests and = sometimes RADIUS servers and I thought only clients contacted servers. = An overview of the actors would probably have clarified that. If I understand correctly how roaming consortiums currently work today, = a RADIUS client within a consortium needing to make a AAA call to a = RADIUS server in another realm does not contact the server directly. = Instead, it routes the request through a hierarchy of RADIUS servers = following roots of trust. The trust model in this document seems to be = bypass the roots of trust, where the client directly contacts the = server. This seems to be discussed in the Section 6 (Privacy = Considerations) discussion of =93clearinghouses", but if the trust model = is changed, this is a bigger impact than privacy so ought to be = discussed explicitly someplace in the document. Section 2.1.1.3 discusses the use of TLS cipher suites, and makes the = point that certificate based cipher suites need to be used because there = won=92t be any pre-distributed secret key material available. That=92s = good advice. I think the section should also give advice on choosing = trust roots. This is important because the identity of the server was = gotten in an untrusted manner (from unsecured DNS), and the certificate = it presents contains information used for authorization of a server = (i.e., SubjectAltName). If a RADIUS client were to accept a certificate = signed by a wide range of trust roots (e.g, the set of roots used by = browsers, where the trustability of many CAs in the hierarchy is = unknown) then the RADIUS client would be ill advised to trust = authorization information claims in the hierarchy. On the other hand, if = the trust roots were restricted to a set of highly trusted trust roots = maintained by the consortium, then the authorization information in the = certificate would be trustable. This should be explained. Section 2.2 defines the NAIRealm name as a form of otherName. This makes = sense. But there is also a paragraph discussing sRVName, which is = confusing. I think it=92s clarifying who sRVName isn=92t applicable; it = would be good state that plainly at the beginning of the paragraph. Section 5 (first paragraph) makes the point that the information gotten = from DNS can=92t be trusted. But I would suggest a slight rewording: = s/can not be trusted/is not sufficient to identify an authorized = server/. Brian= From nobody Fri Dec 26 09:30:07 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352061A8934; Mon, 22 Dec 2014 16:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80cqockGX1Pz; Mon, 22 Dec 2014 16:44:59 -0800 (PST) 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 753181A6FE8; Mon, 22 Dec 2014 16:44:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQJ14189; Tue, 23 Dec 2014 00:44:57 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 23 Dec 2014 00:44:56 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 23 Dec 2014 08:44:51 +0800 From: "Huangyihong (Rachel)" To: Scott Kelly , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07 Thread-Index: AQHQHe67w71WGaG2g0awosmV7furIpycVtlA Date: Tue, 23 Dec 2014 00:44:50 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB862A172A@nkgeml501-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/elYMG4n1VYYtI1fZRhdbBiaXJds X-Mailman-Approved-At: Fri, 26 Dec 2014 09:30:05 -0800 Subject: Re: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 00:45:01 -0000 Hi Scott, Thanks for your suggestions. I'll remove "It is believed that" from current= draft. BR, Rachel > -----Original Message----- > From: Scott Kelly [mailto:scott@hyperthought.com] > Sent: Monday, December 22, 2014 9:53 PM > To: secdir@ietf.org; iesg@ietf.org; > draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org > Subject: secdir review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-cou= nt-07 >=20 > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area dire= ctors. > Document editors and WG chairs should treat these comments just like any > other last call comments. >=20 > Here's the abstract: >=20 > This document defines an RTP Control Protocol (RTCP) Extended Report > (XR) Block that allows reporting of post-repair loss count metrics > for a range of RTP applications. >=20 > Prior to this mechanism, RTCP Sender Reports (SR)/Receiver Reports (RR) > contain, among other things, the cumulative number of packets lost. That > number doesn't indicate the data successfully received, because the recei= ver > can apply repair mechanisms to recover data. This document adds reporting= for > post-repair metrics. >=20 > The security considerations seem complete, but I have one nit. Here's the= first > sentence: >=20 > It is believed that this RTCP XR block introduces no new security > considerations beyond those described in [RFC3611]. >=20 > Who believes this? I would simply assert this (remove "It is believed tha= t"), > and if I wasn't comfortable with that, I'd take that as an indication tha= t more > analysis is required. >=20 > -Scott >=20 >=20 From nobody Fri Dec 26 10:23:37 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF9C1A9129; Fri, 26 Dec 2014 10:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B4w823jMEgu; Fri, 26 Dec 2014 10:23:32 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352E91A9128; Fri, 26 Dec 2014 10:23:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 76090E2035; Fri, 26 Dec 2014 13:23:29 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20758-09; Fri, 26 Dec 2014 13:23:26 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 4905FE2034; Fri, 26 Dec 2014 13:23:26 -0500 (EST) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id sBQINOOE023953; Fri, 26 Dec 2014 13:23:24 -0500 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Fri, 26 Dec 2014 13:23:24 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/gRSdW0Y6y5KvVVRFC3ek1XeurJI Cc: Darren.Moffat@Oracle.COM, Jan.Pechanec@Oracle.COM Subject: [secdir] sec-dir review of draft-pechanec-pkcs11uri-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2014 18:23:33 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I believe this document has no issues. Editorial comments: In section 1: A subset of existing PKCS#11 structure members and object attributes was chosen believed to be sufficient in uniquely identifying a PKCS#11 token, storage object, or library in a configuration file, on ... This sentence is not just long but also awkward. The phrase "was chosen believed to be.." seems to be missing a conjunction and possibly a verb. Maybe this was meant to be two sentences that got smushed together? In section 3.3: PKCS#11 specification imposes various limitations on the value of attributes, be it a more restrictive character set for the "serial" ... I think you need to start this sentence with an article, i.e. "The PKCS#11 specification imposes..." (I'll note that I did not validate the ABNF). Thanks, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Sun Dec 28 12:51:30 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348361A9139; Sun, 28 Dec 2014 12:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y83jX3Ee8TdY; Sun, 28 Dec 2014 12:51:09 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8748D1A9134; Sun, 28 Dec 2014 12:51:09 -0800 (PST) Received: by mail-oi0-f48.google.com with SMTP id u20so27121913oif.7; Sun, 28 Dec 2014 12:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=vxG2+O81fBneq+4e0uvdH8/Q/1Np9h47H1IulFTJaV4=; b=M5iDv9ZBmJ6mEM6jOG0Uz3EH2pVBr6c5mqkN7oRy/5OO53RzxR8Pynowyg96tB93ul E2O16Z9lhg5O7zyIf+Q0uXQKNBNp2I6eZxfyWNLqkSvh+6EcH5GSqKwQ4+Wuu/VW2I7z jz0bvaZ5QmfKoHanV70oKmyzE7ic/DVZNmP7WvowaO56ns/hYTHx5DpLMiR8S06YQq6f +eNPIFHFyL0RjQd8daoiWNAt8/5TGTz5fGYMnRrizeXfjMwZYxA4ETnruybMR08OZSQy 9kndHZETzfjY+y0NpTMc9xpFpi5zKXZ1+ej0Zc+JFi36q1ZUQOggVgqN/AezcTrvalXF 8dYg== X-Received: by 10.202.170.74 with SMTP id t71mr28841632oie.73.1419799868774; Sun, 28 Dec 2014 12:51:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.104.104 with HTTP; Sun, 28 Dec 2014 12:50:48 -0800 (PST) From: Donald Eastlake Date: Sun, 28 Dec 2014 15:50:48 -0500 Message-ID: To: "iesg@ietf.org" , draft-ietf-httpauth-hoba.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/6q454ExkX0Pl6P9aw1YMENusuEg Cc: "secdir@ietf.org" Subject: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 20:51:11 -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. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies an Experimental protocol to use digital signatures in response to challenges for authentication to HTTP servers as a replacement for passwords. There are a lot more details than that and considerable effort has been put into making this fit into existing web authentication so as to be easily deployable. Overall, it looks like a good job. See comments below. As a heavily security oriented draft, I recommend it be looked at by the non-author Security AD :-) > Security Comments < --------------------- This draft is fairly clear about what happens when mandatory 2119 requirements are violated in strictly security contexts, such as a signature not validating. But is generally doesn't say much about what happens when mandatory formatting requirements are violated. I guess if things don't parse, then authentication will fail. But, for example, it says "The "realm" attribute MUST NOT appear more than once." Whenever I see something like that, I say to myself, OK, so what happens if the "MUST NOT" is violated? If the spec says nothing, then I would expect that with some implementations authentication would fail while others would use the first realm attribute and still others would use the last realm attribute. Could that be a problem? This draft uses "random" and "randomness" in various places without any reference/definition. Security Considerations: Perhaps there should be a reference in the Security Considerations section to Section 1.1. Can some level of confusion/denial be caused by setting max-age to a lower value than the server intended? Appendix B: It is good that an example is provided it seems like some things are missing. Shouldn't it specify the "alg" string and wouldn't it be useful if it gave the TBS blob explicitly? > Wording/Format Comments < --------------------------- Abstract: I always worry about words like "all" (or, being recursive to this sentence, "always" :-). I suggest deleting the one occurrence of "all" in the Abstract. Page 5, Section 1.2 OLD That will contain of at least one CPK and a web-origin; ^^ NEW That will contain at least one CPK and a web-origin; Page 6/7/13, Figure 1/2/3: I'm not sure that something that is entirely textural is best called a "Figure". But in any case, since the text is, or at least has, lines that are flush left, it looks like part of the preceding text and there isn't a clear demarcation of the start. I recommend that the body of the Figures be indented 3 or 4 spaces. Page 6, Section 2: - For "alg" inconsistently says it is "an ASCII character" and "ASCII numbers" where perhaps it should say "an ASCII encoded one or two digit non-negative integer" or something. - For "origin" perhaps the example should note that it would be prefixed by "28:" in the TBS blob. - Delete one of the two sequential occurrences of "reduce the amount of". Page 10, Section 5: I suggest rewording this sentence: OLD This section also covers the actions that give HOBA similar user features as today's passwords have. NEW This section also covers the actions that give HOBA user features similar to today's passwords. Page 16, Section 6.4: duplicated word "response". Page 18, Section 8.2: Is it a good idea to mention a particular on-line service name here? Page 19, IANA Considerations: It seems from draft-leiba-coton-iana-5226bis that IANA would prefer IANA Considerations to be written in the past tense as if the actions had already been accomplished, presumably to minimize IANA re-writing effort. Thus, I suggest that consideration be given to changing the initial part, between the Section 9 heading and the Section 9.1 heading, to the following and making similar changes in the remainder of the IANA Considerations Section: IANA has created the registries and made the registration specified below, placing the new registries in a new "HTTP Origin-Bound Authentication (HOBA) Parameters" category. Page 20, Section 9.3: A better way to note the restriction on potential values of Algorithm Name would be to add a third entry to the registry something like the following (there should also be a third Reference column): 2-99 Unassigned [this document] Page 20, Section 9.4: Suggest the "Meaning" for 2 be "an unformatted UTF8 string". There should probably be a Reference column. "a small positive integer" is undefined. Page 20, Section 9.5: Seems like this should say "UTF8 string" and I'm not sure it needs "at the user's/UA's whim". There should also be a "[this document]" entry in a Reference column. Maybe there should be ABNF for "kid" and "did" somewhere. Since "kid" and "did" are ordinary English words, suggest globally replacing them with "KID" and "DID" respectively. Page 24, Appendix A This is a nice appendix but there is no reference to it anywhere in the body of the draft. Suggest adding such a reference to the Introduction. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Sun Dec 28 15:37:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F68D1AC3B6; Sun, 28 Dec 2014 15:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcUkXQ4sU1V3; Sun, 28 Dec 2014 15:37:46 -0800 (PST) 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 0602A1AC3AB; Sun, 28 Dec 2014 15:37:45 -0800 (PST) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id sBSNbeFR008976 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 29 Dec 2014 00:37:43 +0100 Date: Mon, 29 Dec 2014 00:37:39 +0100 From: Simon Josefsson To: iesg@ietf.org, draft-ietf-rtgwg-remote-lfa.all@tools.ietf.org, secdir@ietf.org Message-ID: <20141229003739.60427218@latte.josefsson.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_/H4Ba_MCCLIa6HQzZo3qdrg3"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.5 at duva.sjd.se X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/uPDIm6DexHr70nr4zOLamU1rwfw Subject: [secdir] Secdir review of draft-ietf-rtgwg-remote-lfa-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 23:37:47 -0000 --Sig_/H4Ba_MCCLIa6HQzZo3qdrg3 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. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an extension to a part of RFC5286. It does not claim to update RFC 5286 (or any other document) so any security considerations introduced would only affect implementations of this document, which is a good sanity check. I did not digest the algorithm itself enough to analyse any security aspects of it. The document title is 'Remote LFA FRR' and I suggest to expand the acronyms, or consider a more descriptive title. The document is hard to read for someone not familiar with the area, but there is a decent Terminology and Introduction section to smoothen things out. I believe the document has no issues. /Simon --Sig_/H4Ba_MCCLIa6HQzZo3qdrg3 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUoJRDAAoJEIYLf7sy+BGd9ZQIAJh/YfV91WDKsbCER+lCnQgt 42RZTKZJMHtU6j6uKeHltc35HoIMt0QREW+TX6eiRZVE87JMlPwdnrCVcsTfRyow /Dq16wx/OCGNuWy1w0AzdosQsNnwZ8ZwrO0MasPyF6iSCcLvKdOunhlueUZz5o93 2DED+ty9GhmRlrcpVFDfoNXBuoCzoZpsQ9LjYV3HirzjLDkWQiwLcM/fRDdDz9rJ br4SupPP5lxdz2u2ziYGP4pmpU5tXAGp9i8oDNT4tTOtuGv0VjqN28arLIl+RwLD GeNeQEfYqCFWrFMHBCgUB+bNBPrO7D9nHJoXHXr86zLhhnsGihQfo8vfQMW1wzA= =V+Wf -----END PGP SIGNATURE----- --Sig_/H4Ba_MCCLIa6HQzZo3qdrg3-- From nobody Tue Dec 30 04:21:21 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7662C1A0406; Mon, 29 Dec 2014 21:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waZxfhTaLcmp; Mon, 29 Dec 2014 21:53:44 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEF91A0383; Mon, 29 Dec 2014 21:53:44 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sBU5re4A011282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Dec 2014 05:53:41 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sBU5rc5Q013585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2014 05:53:39 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sBU5rcSD013579; Tue, 30 Dec 2014 05:53:38 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Dec 2014 21:53:38 -0800 Date: Mon, 29 Dec 2014 21:53:37 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Derek Atkins In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-570397931-1419918818=:1509" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/o2-PR9QMGHQdRnQu_tWnf3QVeMw X-Mailman-Approved-At: Tue, 30 Dec 2014 04:21:18 -0800 Cc: Darren.Moffat@oracle.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] sec-dir review of draft-pechanec-pkcs11uri-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 05:53:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-570397931-1419918818=:1509 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 26 Dec 2014, Derek Atkins 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 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. > >I believe this document has no issues. dear Derek, thank you for your time to review the document. My comments are inline below. >Editorial comments: > >In section 1: > > A subset of existing PKCS#11 structure members and object attributes > was chosen believed to be sufficient in uniquely identifying a > PKCS#11 token, storage object, or library in a configuration file, on > ... > >This sentence is not just long but also awkward. The phrase "was I agree. I've simplified that in the following way: A subset of existing PKCS#11 structure members and object attributes was chosen to uniquely identify a PKCS#11 storage object, token, slot, or library in a configuration file, on a command line, or in a configuration property of something else. Should there be a need for a more complex information exchange on PKCS#11 entities a different means of data marshalling should be chosen accordingly. >chosen believed to be.." seems to be missing a conjunction and >possibly a verb. Maybe this was meant to be two sentences that got >smushed together? > > >In section 3.3: > > PKCS#11 specification imposes various limitations on the value of > attributes, be it a more restrictive character set for the "serial" > ... > >I think you need to start this sentence with an article, i.e. "The >PKCS#11 specification imposes..." I've fixed that, thank you. >(I'll note that I did not validate the ABNF). there was a bug there and the grammar in the latest working version of a new draft 17 was verified by: http://tools.ietf.org/tools/bap/abnf.cgi I've also attached the latest working version of draft 17. best regards, Jan. -- Jan Pechanec ---559023410-570397931-1419918818=:1509 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=draft-pechanec-pkcs11uri-17-v5.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=draft-pechanec-pkcs11uri-17-v5.txt DQoNCg0KDQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSi4gUGVjaGFuZWMNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEQuIE1vZmZhdA0KSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFy ZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgT3JhY2xlIENvcnBvcmF0 aW9uDQpFeHBpcmVzOiBKdWx5IDIsIDIwMTUgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRGVjZW1iZXIgMjksIDIwMTQNCg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZQ0KICAg ICAgICAgICAgICAgICAgICAgIGRyYWZ0LXBlY2hhbmVjLXBrY3MxMXVyaS0x Nw0KDQpBYnN0cmFjdA0KDQogICBUaGlzIG1lbW8gc3BlY2lmaWVzIGEgUEtD UyMxMSBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSkNCiAgIFNj aGVtZSBmb3IgaWRlbnRpZnlpbmcgUEtDUyMxMSBvYmplY3RzIHN0b3JlZCBp biBQS0NTIzExIHRva2VucywgYW5kDQogICBhbHNvIGZvciBpZGVudGlmeWlu ZyBQS0NTIzExIHRva2Vucywgc2xvdHMgb3IgbGlicmFyaWVzLiAgVGhlIFVS SSBpcw0KICAgYmFzZWQgb24gaG93IFBLQ1MjMTEgb2JqZWN0cywgdG9rZW5z LCBzbG90cywgYW5kIGxpYnJhcmllcyBhcmUNCiAgIGlkZW50aWZpZWQgaW4g dGhlIFBLQ1MjMTEgQ3J5cHRvZ3JhcGhpYyBUb2tlbiBJbnRlcmZhY2UgU3Rh bmRhcmQuDQoNClN0YXR1cyBvZiBUaGlzIE1lbW8NCg0KICAgVGhpcyBJbnRl cm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3 aXRoIHRoZQ0KICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4N Cg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElF VEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMu ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQ0KICAgRHJhZnRzIGlz IGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVu dC8uDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRz IHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1h eSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy IGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJp YXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBt YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBp biBwcm9ncmVzcy4iDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gSnVseSAyLCAyMDE1Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoN CiAgIENvcHlyaWdodCAoYykgMjAxNCBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4g IEFsbCByaWdodHMgcmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMg c3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwN CiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMNCiAg IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVm ZmVjdCBvbiB0aGUgZGF0ZSBvZg0KICAgcHVibGljYXRpb24gb2YgdGhpcyBk b2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQogICBj YXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJl c3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNCiAgIHRvIHRoaXMgZG9jdW1lbnQu ICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVu dCBtdXN0DQogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4 dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YNCiAgIHRoZSBUcnVz dCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3 YXJyYW50eSBhcw0KICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJT RCBMaWNlbnNlLg0KDQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBF eHBpcmVzIEp1bHkgMiwgMjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDFd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJ IFNjaGVtZSAgICAgICAgICAgIERlY2VtYmVyIDIwMTQNCg0KDQpUYWJsZSBv ZiBDb250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDINCiAg IDIuICBDb250cmlidXRvcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KICAgMy4gIFBLQ1MjMTEgVVJJ IFNjaGVtZSBEZWZpbml0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA0DQogICAgIDMuMS4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBOYW1l IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQNCiAgICAg My4yLiAgUEtDUyMxMSBVUkkgU2NoZW1lIFN0YXR1cyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KICAgICAzLjMuICBQS0NTIzExIFVS SSBTY2hlbWUgU3ludGF4IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA0DQogICAgIDMuNC4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBRdWVyeSBB dHRyaWJ1dGUgU2VtYW50aWNzICAuIC4gLiAuIC4gLiAgIDgNCiAgICAgMy41 LiAgUEtDUyMxMSBVUkkgTWF0Y2hpbmcgR3VpZGVsaW5lcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxMA0KICAgICAzLjYuICBQS0NTIzExIFVSSSBD b21wYXJpc29uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDExDQogICA0LiAgRXhhbXBsZXMgb2YgUEtDUyMxMSBVUklzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTINCiAgIDUuICBJQU5B IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxNg0KICAgNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2 DQogICA3LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTcNCiAgICAgNy4xLiAgTm9y bWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxNw0KICAgICA3LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVu Y2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE3DQog ICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTcNCg0KMS4gIEludHJvZHVjdGlv bg0KDQogICBUaGUgUEtDUyAjMTE6IENyeXB0b2dyYXBoaWMgVG9rZW4gSW50 ZXJmYWNlIFN0YW5kYXJkIFtwa2NzMTFfc3BlY10NCiAgIHNwZWNpZmllcyBh biBBUEksIGNhbGxlZCBDcnlwdG9raSwgZm9yIGRldmljZXMgd2hpY2ggaG9s ZA0KICAgY3J5cHRvZ3JhcGhpYyBpbmZvcm1hdGlvbiBhbmQgcGVyZm9ybSBj cnlwdG9ncmFwaGljIGZ1bmN0aW9ucy4NCiAgIENyeXB0b2tpLCBwcm9ub3Vu Y2VkIGNyeXB0by1rZXkgYW5kIHNob3J0IGZvciBjcnlwdG9ncmFwaGljIHRv a2VuDQogICBpbnRlcmZhY2UsIGZvbGxvd3MgYSBzaW1wbGUgb2JqZWN0LWJh c2VkIGFwcHJvYWNoLCBhZGRyZXNzaW5nIHRoZQ0KICAgZ29hbHMgb2YgdGVj aG5vbG9neSBpbmRlcGVuZGVuY2UgKGFueSBraW5kIG9mIGRldmljZSBtYXkg YmUgdXNlZCkgYW5kDQogICByZXNvdXJjZSBzaGFyaW5nIChtdWx0aXBsZSBh cHBsaWNhdGlvbnMgbWF5IGFjY2VzcyBtdWx0aXBsZSBkZXZpY2VzKSwNCiAg IHByZXNlbnRpbmcgYXBwbGljYXRpb25zIHdpdGggYSBjb21tb24sIGxvZ2lj YWwgdmlldyBvZiB0aGUgZGV2aWNlIC0gYQ0KICAgY3J5cHRvZ3JhcGhpYyB0 b2tlbi4NCg0KICAgSXQgaXMgZGVzaXJhYmxlIGZvciBhcHBsaWNhdGlvbnMg b3IgbGlicmFyaWVzIHRoYXQgd29yayB3aXRoIFBLQ1MjMTENCiAgIHRva2Vu cyB0byBhY2NlcHQgYSBjb21tb24gaWRlbnRpZmllciB0aGF0IGNvbnN1bWVy cyBjb3VsZCB1c2UgdG8NCiAgIGlkZW50aWZ5IGFuIGV4aXN0aW5nIFBLQ1Mj MTEgc3RvcmFnZSBvYmplY3QgaW4gYSBQS0NTIzExIHRva2VuLCBhbg0KICAg ZXhpc3RpbmcgdG9rZW4gaXRzZWxmLCBhIHNsb3QsIG9yIGFuIGV4aXN0aW5n IENyeXB0b2tpIGxpYnJhcnkgKGFsc28NCiAgIGNhbGxlZCBhIHByb2R1Y2Vy LCBtb2R1bGUsIG9yIHByb3ZpZGVyKS4gIFRoZSBzZXQgb2Ygc3RvcmFnZSBv YmplY3QNCiAgIHR5cGVzIHRoYXQgY2FuIGJlIHN0b3JlZCBpbiBhIFBLQ1Mj MTEgdG9rZW4gaW5jbHVkZXMgYSBjZXJ0aWZpY2F0ZSwgYQ0KICAgcHVibGlj LCBwcml2YXRlIG9yIHNlY3JldCBrZXksIGFuZCBhIGRhdGEgb2JqZWN0LiAg VGhlc2Ugb2JqZWN0cyBjYW4NCiAgIGJlIHVuaXF1ZWx5IGlkZW50aWZpYWJs ZSB2aWEgdGhlIFBLQ1MjMTEgVVJJIHNjaGVtZSBkZWZpbmVkIGluIHRoaXMN CiAgIGRvY3VtZW50LiAgVGhlIHNldCBvZiBhdHRyaWJ1dGVzIGRlc2NyaWJp bmcgYSBzdG9yYWdlIG9iamVjdCBjYW4NCiAgIGNvbnRhaW4gYW4gb2JqZWN0 IGxhYmVsLCBpdHMgdHlwZSwgYW5kIGl0cyBJRC4gIFRoZSBzZXQgb2YgYXR0 cmlidXRlcw0KICAgdGhhdCBpZGVudGlmaWVzIGEgUEtDUyMxMSB0b2tlbiBj YW4gY29udGFpbiBhIHRva2VuIGxhYmVsLA0KICAgbWFudWZhY3R1cmVyIG5h bWUsIHNlcmlhbCBudW1iZXIsIGFuZCB0b2tlbiBtb2RlbC4gIEF0dHJpYnV0 ZXMgdGhhdA0KICAgY2FuIGlkZW50aWZ5IGEgc2xvdCBhcmUgYSBzbG90IElE LCBkZXNjcmlwdGlvbiwgYW5kIG1hbnVmYWN0dXJlci4NCiAgIEF0dHJpYnV0 ZXMgdGhhdCBjYW4gaWRlbnRpZnkgYSBDcnlwdG9raSBsaWJyYXJ5IGFyZSBh IGxpYnJhcnkNCiAgIG1hbnVmYWN0dXJlciwgZGVzY3JpcHRpb24sIGFuZCB2 ZXJzaW9uLiAgTGlicmFyeSBhdHRyaWJ1dGVzIG1heSBiZQ0KICAgbmVjZXNz YXJ5IHRvIHVzZSBpZiBtb3JlIHRoYW4gb25lIENyeXB0b2tpIGxpYnJhcnkg cHJvdmlkZXMgYSB0b2tlbg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAg ICAgICAgIEV4cGlyZXMgSnVseSAyLCAyMDE1ICAgICAgICAgICAgICAgICAg W1BhZ2UgMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtD UyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoN CiAgIGFuZC9vciBQS0NTIzExIG9iamVjdHMgb2YgdGhlIHNhbWUgbmFtZS4g IEEgc2V0IG9mIHF1ZXJ5IGF0dHJpYnV0ZXMNCiAgIGlzIHByb3ZpZGVkIGFz IHdlbGwuDQoNCiAgIFRoZSBQS0NTIzExIFVSSSBjYW5ub3QgaWRlbnRpZnkg b3RoZXIgb2JqZWN0cyBkZWZpbmVkIGluIHRoZQ0KICAgc3BlY2lmaWNhdGlv biBbcGtjczExX3NwZWNdIGFzaWRlIGZyb20gc3RvcmFnZSBvYmplY3RzLiAg Rm9yIGV4YW1wbGUsDQogICBvYmplY3RzIG5vdCBpZGVudGlmaWFibGUgYnkg YSBQS0NTIzExIFVSSSBpbmNsdWRlIGEgaGFyZHdhcmUgZmVhdHVyZQ0KICAg YW5kIG1lY2hhbmlzbS4gIE5vdGUgdGhhdCBhIENyeXB0b2tpIGxpYnJhcnkg ZG9lcyBub3QgaGF2ZSB0byBwcm92aWRlDQogICBmb3Igc3RvcmFnZSBvYmpl Y3RzIGF0IGFsbC4gIFRoZSBVUkkgY2FuIHN0aWxsIGJlIHVzZWQgdG8gaWRl bnRpZnkgYQ0KICAgc3BlY2lmaWMgUEtDUyMxMSB0b2tlbiwgc2xvdCBvciBh biBBUEkgcHJvZHVjZXIgaW4gc3VjaCBhIGNhc2UuDQoNCiAgIEEgc3Vic2V0 IG9mIGV4aXN0aW5nIFBLQ1MjMTEgc3RydWN0dXJlIG1lbWJlcnMgYW5kIG9i amVjdCBhdHRyaWJ1dGVzDQogICB3YXMgY2hvc2VuIHRvIHVuaXF1ZWx5IGlk ZW50aWZ5IGEgUEtDUyMxMSBzdG9yYWdlIG9iamVjdCwgdG9rZW4sDQogICBz bG90LCBvciBsaWJyYXJ5IGluIGEgY29uZmlndXJhdGlvbiBmaWxlLCBvbiBh IGNvbW1hbmQgbGluZSwgb3IgaW4gYQ0KICAgY29uZmlndXJhdGlvbiBwcm9w ZXJ0eSBvZiBzb21ldGhpbmcgZWxzZS4gIFNob3VsZCB0aGVyZSBiZSBhIG5l ZWQgZm9yDQogICBhIG1vcmUgY29tcGxleCBpbmZvcm1hdGlvbiBleGNoYW5n ZSBvbiBQS0NTIzExIGVudGl0aWVzIGEgZGlmZmVyZW50DQogICBtZWFucyBv ZiBkYXRhIG1hcnNoYWxsaW5nIHNob3VsZCBiZSBjaG9zZW4gYWNjb3JkaW5n bHkuDQoNCiAgIEEgUEtDUyMxMSBVUkkgaXMgbm90IGludGVuZGVkIHRvIGJl IHVzZWQgdG8gY3JlYXRlIG5ldyBQS0NTIzExDQogICBvYmplY3RzIGluIHRv a2Vucywgb3IgdG8gY3JlYXRlIFBLQ1MjMTEgdG9rZW5zLiAgSXQgaXMgc29s ZWx5IHRvIGJlDQogICB1c2VkIHRvIGlkZW50aWZ5IGFuZCB3b3JrIHdpdGgg ZXhpc3Rpbmcgc3RvcmFnZSBvYmplY3RzLCB0b2tlbnMsIGFuZA0KICAgc2xv dHMgdGhyb3VnaCB0aGUgUEtDUyMxMSBBUEksIG9yIGlkZW50aWZ5IENyeXB0 b2tpIGxpYnJhcmllcw0KICAgdGhlbXNlbHZlcy4NCg0KICAgVGhlIFVSSSBz Y2hlbWUgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGlzIGRlc2lnbmVkIHNw ZWNpZmljYWxseSB3aXRoDQogICBhIG1hcHBpbmcgdG8gdGhlIFBLQ1MjMTEg QVBJIGluIG1pbmQuICBUaGUgVVJJIHVzZXMgdGhlIHNjaGVtZSwgcGF0aA0K ICAgYW5kIHF1ZXJ5IGNvbXBvbmVudHMgZGVmaW5lZCBpbiB0aGUgVW5pZm9y bSBSZXNvdXJjZSBJZGVudGlmaWVyDQogICAoVVJJKTogR2VuZXJpYyBTeW50 YXggW1JGQzM5ODZdIGRvY3VtZW50LiAgVGhlIFVSSSBkb2VzIG5vdCB1c2Ug dGhlDQogICBoaWVyYXJjaGljYWwgZWxlbWVudCBmb3IgYSBuYW1pbmcgYXV0 aG9yaXR5IGluIHRoZSBwYXRoIHNpbmNlIHRoZQ0KICAgYXV0aG9yaXR5IHBh cnQgY291bGQgbm90IGJlIG1hcHBlZCB0byBQS0NTIzExIEFQSSBlbGVtZW50 cy4gIFRoZSBVUkkNCiAgIGRvZXMgbm90IHVzZSB0aGUgZnJhZ21lbnQgY29t cG9uZW50Lg0KDQogICBJZiBhbiBhcHBsaWNhdGlvbiBoYXMgbm8gYWNjZXNz IHRvIGEgcHJvZHVjZXIgb3IgcHJvZHVjZXJzIG9mIHRoZQ0KICAgUEtDUyMx MSBBUEkgdGhlIHF1ZXJ5IGNvbXBvbmVudCBtb2R1bGUgYXR0cmlidXRlcyBj YW4gYmUgdXNlZC4NCiAgIEhvd2V2ZXIsIHRoZSBQS0NTIzExIFVSSSBjb25z dW1lciBjYW4gYWx3YXlzIGRlY2lkZSB0byBwcm92aWRlIGl0cw0KICAgb3du IGFkZXF1YXRlIHVzZXIgaW50ZXJmYWNlIHRvIGxvY2F0ZSBhbmQgbG9hZCBQ S0NTIzExIEFQSSBwcm9kdWNlcnMuDQoNCiAgIFRoZSBrZXkgd29yZHMgIk1V U1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwg Tk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRF RCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1bWVu dCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMy MTE5XS4NCg0KMi4gIENvbnRyaWJ1dG9ycw0KDQogICBTdGVmIFdhbHRlciwg Tmlrb3MgTWF2cm9naWFubm9wb3Vsb3MsIE5pY28gV2lsbGlhbXMsIERhbiBX aW5zaGlwLCBhbmQNCiAgIEphcm9zbGF2IEltcmljaCBjb250cmlidXRlZCB0 byB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhpcyBkb2N1bWVudC4NCg0KDQoNCg0K DQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkg MiwgMjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAg ICAgICAgIERlY2VtYmVyIDIwMTQNCg0KDQozLiAgUEtDUyMxMSBVUkkgU2No ZW1lIERlZmluaXRpb24NCg0KICAgSW4gYWNjb3JkYW5jZSB3aXRoIFtSRkM0 Mzk1XSwgdGhpcyBzZWN0aW9uIHByb3ZpZGVzIHRoZSBpbmZvcm1hdGlvbg0K ICAgcmVxdWlyZWQgdG8gcmVnaXN0ZXIgdGhlIFBLQ1MjMTEgVVJJIHNjaGVt ZS4NCg0KMy4xLiAgUEtDUyMxMSBVUkkgU2NoZW1lIE5hbWUNCg0KICAgcGtj czExDQoNCjMuMi4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBTdGF0dXMNCg0KICAg UGVybWFuZW50Lg0KDQozLjMuICBQS0NTIzExIFVSSSBTY2hlbWUgU3ludGF4 DQoNCiAgIFRoZSBQS0NTIzExIFVSSSBpcyBhIHNlcXVlbmNlIG9mIGF0dHJp YnV0ZSB2YWx1ZSBwYWlycyBzZXBhcmF0ZWQgYnkgYQ0KICAgc2VtaWNvbG9u IHRoYXQgZm9ybSBhIG9uZSBsZXZlbCBwYXRoIGNvbXBvbmVudCwgb3B0aW9u YWxseSBmb2xsb3dlZA0KICAgYnkgYSBxdWVyeS4gIEluIGFjY29yZGFuY2Ug d2l0aCBTZWN0aW9uIDIuNSBvZiBbUkZDMzk4Nl0sIHRoZSBkYXRhDQogICBz aG91bGQgZmlyc3QgYmUgZW5jb2RlZCBhcyBvY3RldHMgYWNjb3JkaW5nIHRv IHRoZSBVVEYtOCBjaGFyYWN0ZXINCiAgIGVuY29kaW5nIFtSRkMzNjI5XTsg dGhlbiBvbmx5IHRob3NlIG9jdGV0cyB0aGF0IGRvIG5vdCBjb3JyZXNwb25k IHRvDQogICBjaGFyYWN0ZXJzIGluIHRoZSB1bnJlc2VydmVkIHNldCBvciB0 byBwZXJtaXR0ZWQgY2hhcmFjdGVycyBmcm9tIHRoZQ0KICAgcmVzZXJ2ZWQg c2V0IHNob3VsZCBiZSBwZXJjZW50LWVuY29kZWQuICBUaGlzIHNwZWNpZmlj YXRpb24gc3VnZ2VzdHMNCiAgIG9uZSBhbGxvd2FibGUgZXhjZXB0aW9uIHRv IHRoYXQgcnVsZSBmb3IgdGhlICJpZCIgYXR0cmlidXRlLCBhcw0KICAgc3Rh dGVkIGxhdGVyIGluIHRoaXMgc2VjdGlvbi4gIEdyYW1tYXIgcnVsZXMgInVu cmVzZXJ2ZWQiIGFuZCAicGN0LQ0KICAgZW5jb2RlZCIgaW4gdGhlIFBLQ1Mj MTEgVVJJIHNwZWNpZmljYXRpb24gYmVsb3cgYXJlIGltcG9ydGVkIGZyb20N CiAgIFtSRkMzOTg2XS4gIEFzIGEgc3BlY2lhbCBjYXNlLCBub3RlIHRoYXQg YWNjb3JkaW5nIHRvIEFwcGVuZGl4IEEgb2YNCiAgIFtSRkMzOTg2XSwgYSBz cGFjZSBtdXN0IGJlIHBlcmNlbnQtZW5jb2RlZC4NCg0KICAgVGhlIFBLQ1Mj MTEgc3BlY2lmaWNhdGlvbiBpbXBvc2VzIHZhcmlvdXMgbGltaXRhdGlvbnMg b24gdGhlIHZhbHVlIG9mDQogICBhdHRyaWJ1dGVzLCBiZSBpdCBhIG1vcmUg cmVzdHJpY3RpdmUgY2hhcmFjdGVyIHNldCBmb3IgdGhlICJzZXJpYWwiDQog ICBhdHRyaWJ1dGUgb3IgZml4ZWQgc2l6ZWQgYnVmZmVycyBmb3IgYWxtb3N0 IGFsbCB0aGUgb3RoZXJzLCBpbmNsdWRpbmcNCiAgICJ0b2tlbiIsICJtYW51 ZmFjdHVyZXIiLCBhbmQgIm1vZGVsIiBhdHRyaWJ1dGVzLiAgSG93ZXZlciwg dGhlDQogICBQS0NTIzExIFVSSSBub3RhdGlvbiBkb2VzIG5vdCBpbXBvc2Ug c3VjaCBsaW1pdGF0aW9ucyBhc2lkZSBmcm9tDQogICByZW1vdmluZyBnZW5l cmljIGFuZCBQS0NTIzExIFVSSSBkZWxpbWl0ZXJzIGZyb20gYSBwZXJtaXR0 ZWQNCiAgIGNoYXJhY3RlciBzZXQuICBXZSBiZWxpZXZlIHRoYXQgYmVpbmcg dG9vIHJlc3RyaWN0aXZlIG9uIHRoZQ0KICAgYXR0cmlidXRlIHZhbHVlcyBj b3VsZCBsaW1pdCB0aGUgUEtDUyMxMSBVUkkgdXNlZnVsbmVzcy4gIFdoYXQg aXMNCiAgIG1vcmUsIHBvc3NpYmxlIGZ1dHVyZSBjaGFuZ2VzIHRvIHRoZSBQ S0NTIzExIHNwZWNpZmljYXRpb24gc2hvdWxkIG5vdA0KICAgYWZmZWN0IGV4 aXN0aW5nIGF0dHJpYnV0ZXMuDQoNCiAgIEEgUEtDUyMxMSBVUkkgdGFrZXMg dGhlIGZvcm0gKGZvciBleHBsYW5hdGlvbiBvZiBBdWdtZW50ZWQgQk5GLCBz ZWUNCiAgIFtSRkM1MjM0XSk6DQoNCg0KDQoNCg0KDQoNCg0KDQoNClBlY2hh bmVjICYgTW9mZmF0ICAgICAgICAgRXhwaXJlcyBKdWx5IDIsIDIwMTUgICAg ICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hlbWUgICAgICAgICAgICBEZWNl bWJlciAyMDE0DQoNCg0KICBwazExLVVSSSAgICAgICAgICAgICA9ICJwa2Nz MTE6IiBwazExLXBhdGggWyAiPyIgcGsxMS1xdWVyeSBdDQogIDsgUGF0aCBj b21wb25lbnQgYW5kIGl0cyBhdHRyaWJ1dGVzLiAgUGF0aCBtYXkgYmUgZW1w dHkuDQogIHBrMTEtcGF0aCAgICAgICAgICAgID0gWyBwazExLXBhdHRyICoo IjsiIHBrMTEtcGF0dHIpIF0NCiAgcGsxMS1wYXR0ciAgICAgICAgICAgPSBw azExLXRva2VuIC8gcGsxMS1tYW51ZiAvIHBrMTEtc2VyaWFsIC8NCiAgICAg ICAgICAgICAgICAgICAgICAgICBwazExLW1vZGVsIC8gcGsxMS1saWItbWFu dWYgLw0KICAgICAgICAgICAgICAgICAgICAgICAgIHBrMTEtbGliLXZlciAv IHBrMTEtbGliLWRlc2MgLw0KICAgICAgICAgICAgICAgICAgICAgICAgIHBr MTEtb2JqZWN0IC8gcGsxMS10eXBlIC8gcGsxMS1pZCAvDQogICAgICAgICAg ICAgICAgICAgICAgICAgcGsxMS1zbG90LWRlc2MgLyBwazExLXNsb3QtbWFu dWYgLw0KICAgICAgICAgICAgICAgICAgICAgICAgIHBrMTEtc2xvdC1pZCAv IHBrMTEtdi1wYXR0cg0KICA7IFF1ZXJ5IGNvbXBvbmVudCBhbmQgaXRzIGF0 dHJpYnV0ZXMuICBRdWVyeSBtYXkgYmUgZW1wdHkuDQogIHBrMTEtcWF0dHIg ICAgICAgICAgID0gcGsxMS1waW4tc291cmNlIC8gcGsxMS1waW4tdmFsdWUg Lw0KICAgICAgICAgICAgICAgICAgICAgICAgIHBrMTEtbW9kdWxlLW5hbWUg LyBwazExLW1vZHVsZS1wYXRoIC8NCiAgICAgICAgICAgICAgICAgICAgICAg ICBwazExLXYtcWF0dHINCiAgcGsxMS1xdWVyeSAgICAgICAgICAgPSBbIHBr MTEtcWF0dHIgKigiJiIgcGsxMS1xYXR0cikgXQ0KICA7IFJGQyAzOTg2IHNl Y3Rpb24gMi4yIG1hbmRhdGVzIGFsbCBwb3RlbnRpYWxseSByZXNlcnZlZCBj aGFyYWN0ZXJzDQogIDsgdGhhdCBkbyBub3QgY29uZmxpY3Qgd2l0aCBhY3R1 YWwgZGVsaW1pdGVycyBvZiB0aGUgVVJJIGRvIG5vdCBoYXZlDQogIDsgdG8g YmUgcGVyY2VudC1lbmNvZGVkLg0KICBwazExLXJlcy1hdmFpbCAgICAgICA9 ICI6IiAvICJbIiAvICJdIiAvICJAIiAvICIhIiAvICIkIiAvDQogICAgICAg ICAgICAgICAgICAgICAgICAgIiciIC8gIigiIC8gIikiIC8gIioiIC8gIisi IC8gIiwiIC8gIj0iDQogIHBrMTEtcGF0aC1yZXMtYXZhaWwgID0gcGsxMS1y ZXMtYXZhaWwgLyAiJiINCiAgOyAiLyIgYW5kICI/IiBpbiB0aGUgcXVlcnkg Y29tcG9uZW50IE1BWSBiZSB1bmVuY29kZWQgYnV0ICImIiBNVVNUDQogIDsg YmUgZW5jb2RlZCBzaW5jZSBpdCBmdW5jdGlvbnMgYXMgYSBkZWxpbWl0ZXIg d2l0aGluIHRoZSBjb21wb25lbnQuDQogIHBrMTEtcXVlcnktcmVzLWF2YWls ID0gcGsxMS1yZXMtYXZhaWwgLyAiLyIgLyAiPyIgLyAifCINCiAgcGsxMS1w Y2hhciAgICAgICAgICAgPSB1bnJlc2VydmVkIC8gcGsxMS1wYXRoLXJlcy1h dmFpbCAvIHBjdC1lbmNvZGVkDQogIHBrMTEtcWNoYXIgICAgICAgICAgID0g dW5yZXNlcnZlZCAvIHBrMTEtcXVlcnktcmVzLWF2YWlsIC8gcGN0LWVuY29k ZWQNCiAgcGsxMS10b2tlbiAgICAgICAgICAgPSAidG9rZW4iICI9IiAqcGsx MS1wY2hhcg0KICBwazExLW1hbnVmICAgICAgICAgICA9ICJtYW51ZmFjdHVy ZXIiICI9IiAqcGsxMS1wY2hhcg0KICBwazExLXNlcmlhbCAgICAgICAgICA9 ICJzZXJpYWwiICI9IiAqcGsxMS1wY2hhcg0KICBwazExLW1vZGVsICAgICAg ICAgICA9ICJtb2RlbCIgIj0iICpwazExLXBjaGFyDQogIHBrMTEtbGliLW1h bnVmICAgICAgID0gImxpYnJhcnktbWFudWZhY3R1cmVyIiAiPSIgKnBrMTEt cGNoYXINCiAgcGsxMS1saWItZGVzYyAgICAgICAgPSAibGlicmFyeS1kZXNj cmlwdGlvbiIgIj0iICpwazExLXBjaGFyDQogIHBrMTEtbGliLXZlciAgICAg ICAgID0gImxpYnJhcnktdmVyc2lvbiIgIj0iIDEqRElHSVQgWyAiLiIgMSpE SUdJVCBdDQogIHBrMTEtb2JqZWN0ICAgICAgICAgID0gIm9iamVjdCIgIj0i ICpwazExLXBjaGFyDQogIHBrMTEtdHlwZSAgICAgICAgICAgID0gInR5cGUi ICI9IiAoICJwdWJsaWMiIC8gInByaXZhdGUiIC8gImNlcnQiIC8NCiAgICAg ICAgICAgICAgICAgICAgICAgICAic2VjcmV0LWtleSIgLyAiZGF0YSIgKQ0K ICBwazExLWlkICAgICAgICAgICAgICA9ICJpZCIgIj0iICpwazExLXBjaGFy DQogIHBrMTEtc2xvdC1tYW51ZiAgICAgID0gInNsb3QtbWFudWZhY3R1cmVy IiAiPSIgKnBrMTEtcGNoYXINCiAgcGsxMS1zbG90LWRlc2MgICAgICAgPSAi c2xvdC1kZXNjcmlwdGlvbiIgIj0iICpwazExLXBjaGFyDQogIHBrMTEtc2xv dC1pZCAgICAgICAgID0gInNsb3QtaWQiICI9IiAxKkRJR0lUDQogIHBrMTEt cGluLXNvdXJjZSAgICAgID0gInBpbi1zb3VyY2UiICI9IiAqcGsxMS1xY2hh cg0KICBwazExLXBpbi12YWx1ZSAgICAgICA9ICJwaW4tdmFsdWUiICI9IiAq cGsxMS1xY2hhcg0KICBwazExLW1vZHVsZS1uYW1lICAgICA9ICJtb2R1bGUt bmFtZSIgIj0iICpwazExLXFjaGFyDQogIHBrMTEtbW9kdWxlLXBhdGggICAg ID0gIm1vZHVsZS1wYXRoIiAiPSIgKnBrMTEtcWNoYXINCiAgcGsxMS12LWF0 dHItbm0tY2hhciAgPSBBTFBIQSAvIERJR0lUIC8gIi0iIC8gIl8iDQogIDsg UGVybWl0dGVkIHZhbHVlIG9mIGEgdmVuZG9yIHNwZWNpZmljIGF0dHJpYnV0 ZSBpcyBiYXNlZCBvbg0KICA7IHdoZXRoZXIgdGhlIGF0dHJpYnV0ZSBpcyB1 c2VkIGluIHRoZSBwYXRoIG9yIGluIHRoZSBxdWVyeS4NCiAgcGsxMS12LXBh dHRyICAgICAgICAgPSAxKnBrMTEtdi1hdHRyLW5tLWNoYXIgIj0iICpwazEx LXBjaGFyDQogIHBrMTEtdi1xYXR0ciAgICAgICAgID0gMSpwazExLXYtYXR0 ci1ubS1jaGFyICI9IiAqcGsxMS1xY2hhcg0KDQoNCg0KUGVjaGFuZWMgJiBN b2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkgMiwgMjAxNSAgICAgICAgICAg ICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg VGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAgICAgICAgIERlY2VtYmVyIDIw MTQNCg0KDQogICBUaGUgVVJJIHBhdGggY29tcG9uZW50IGNvbnRhaW5zIGF0 dHJpYnV0ZXMgdGhhdCBpZGVudGlmeSBhIHJlc291cmNlDQogICBpbiBhIG9u ZSBsZXZlbCBoaWVyYXJjaHkgcHJvdmlkZWQgYnkgQ3J5cHRva2kgcHJvZHVj ZXJzLiAgVGhlIHF1ZXJ5DQogICBjb21wb25lbnQgY2FuIGNvbnRhaW4gYSBm ZXcgYXR0cmlidXRlcyB0aGF0IG1heSBiZSBuZWVkZWQgdG8gcmV0cmlldmUN CiAgIHRoZSByZXNvdXJjZSBpZGVudGlmaWVkIGJ5IHRoZSBVUkkgcGF0aC4g IEF0dHJpYnV0ZXMgaW4gdGhlIHBhdGgNCiAgIGNvbXBvbmVudCBhcmUgZGVs aW1pdGVkIGJ5ICc7JyBjaGFyYWN0ZXIsIGF0dHJpYnV0ZXMgaW4gdGhlIHF1 ZXJ5DQogICBjb21wb25lbnQgdXNlICcmJyBhcyBhIGRlbGltaXRlci4NCg0K ICAgQm90aCBwYXRoIGFuZCBxdWVyeSBjb21wb25lbnRzIG1heSBjb250YWlu IHZlbmRvciBzcGVjaWZpYw0KICAgYXR0cmlidXRlcy4gIFN1Y2ggYXR0cmli dXRlIG5hbWVzIE1VU1QgTk9UIGNsYXNoIHdpdGggZXhpc3RpbmcNCiAgIGF0 dHJpYnV0ZSBuYW1lcy4gIE5vdGUgdGhhdCBpbiBhY2NvcmRhbmNlIHdpdGgg W0JDUDE3OF0sIHByZXZpb3VzbHkNCiAgIHVzZWQgY29udmVudGlvbiBvZiBz dGFydGluZyB2ZW5kb3IgYXR0cmlidXRlcyB3aXRoIGFuICJ4LSIgcHJlZml4 IGlzDQogICBub3cgZGVwcmljYXRlZC4NCg0KICAgVGhlIGdlbmVyYWwgJy8n IGRlbGltaXRlciBNVVNUIGJlIHBlcmNlbnQtZW5jb2RlZCBpbiB0aGUgcGF0 aA0KICAgY29tcG9uZW50IHNvIHRoYXQgZ2VuZXJpYyBVUkkgcGFyc2VycyBu ZXZlciBzcGxpdCB0aGUgcGF0aCBjb21wb25lbnQNCiAgIGludG8gbXVsdGlw bGUgc2VnbWVudHMuICBJdCBNQVkgYmUgdW5lbmNvZGVkIGluIHRoZSBxdWVy eSBjb21wb25lbnQuDQogICBEZWxpbWl0ZXIgJz8nICBNVVNUIGJlIHBlcmNl bnQtZW5jb2RlZCBpbiB0aGUgcGF0aCBjb21wb25lbnQgc2luY2UNCiAgIHRo ZSBQS0NTIzExIFVSSSB1c2VzIGEgcXVlcnkgY29tcG9uZW50LiAgRGVsaW1p dGVyICcjJyBNVVNUIGJlIGFsd2F5cw0KICAgcGVyY2VudC1lbmNvZGVkIHNv IHRoYXQgZ2VuZXJpYyBVUkkgcGFyc2VycyBkbyBub3QgdHJlYXQgYSBoYXNo IGFzIGENCiAgIGJlZ2lubmluZyBvZiBhIGZyYWdtZW50IGlkZW50aWZpZXIg Y29tcG9uZW50LiAgQWxsIG90aGVyIGdlbmVyaWMNCiAgIGRlbGltaXRlcnMg TUFZIGJlIHVzZWQgdW5lbmNvZGVkICgnOicsICdbJywgJ10nLCBhbmQgJ0An KSBpbiB0aGUNCiAgIFBLQ1MjMTEgVVJJLg0KDQogICBUaGUgZm9sbG93aW5n IHRhYmxlIHByZXNlbnRzIG1hcHBpbmcgYmV0d2VlbiB0aGUgUEtDUyMxMSBV UkkgcGF0aA0KICAgY29tcG9uZW50IGF0dHJpYnV0ZXMgYW5kIHRoZSBQS0NT IzExIEFQSSBzdHJ1Y3R1cmUgbWVtYmVycyBhbmQgb2JqZWN0DQogICBhdHRy aWJ1dGVzLiAgR2l2ZW4gdGhhdCBQS0NTIzExIFVSSSB1c2VycyBtYXkgYmUg cXVpdGUgaWdub3JhbnQgYWJvdXQNCiAgIHRoZSBQS0NTIzExIHNwZWNpZmlj YXRpb24gdGhlIG1hcHBpbmcgaXMgYSBwcm9kdWN0IG9mIGEgbmVjZXNzYXJ5 DQogICBjb21wcm9taXNlIGJldHdlZW4gaG93IHByZWNpc2VseSBhcmUgdGhl IFVSSSBhdHRyaWJ1dGUgbmFtZXMgbWFwcGVkDQogICB0byB0aGUgbmFtZXMg aW4gdGhlIHNwZWNpZmljYXRpb24gYW5kIHRoZSBlYXNlIG9mIHVzZSBhbmQN CiAgIHVuZGVyc3RhbmRpbmcgb2YgdGhlIFVSSSBzY2hlbWUuDQoNCiAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCBVUkkgY29tcG9uZW50IHBh dGggICB8IEF0dHJpYnV0ZSAgICAgICAgICAgfCBBdHRyaWJ1dGUgICAgICAg ICAgICB8DQogICB8IGF0dHJpYnV0ZSBuYW1lICAgICAgIHwgcmVwcmVzZW50 cyAgICAgICAgICB8IGNvcnJlc3BvbmRzIGluIHRoZSAgIHwNCiAgIHwgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgUEtD UyMxMSAgICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgfCBzcGVjaWZpY2F0aW9uIHRvICAg ICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQogICB8IGlkICAgICAgICAgICAgICAgICAgIHwga2V5IGlkZW50aWZpZXIg Zm9yICB8ICJDS0FfSUQiIG9iamVjdCAgICAgIHwNCiAgIHwgICAgICAgICAg ICAgICAgICAgICAgfCBvYmplY3QgICAgICAgICAgICAgIHwgYXR0cmlidXRl ICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQog ICB8IGxpYnJhcnktZGVzY3JpcHRpb24gIHwgY2hhcmFjdGVyLXN0cmluZyAg ICB8ICJsaWJyYXJ5RGVzY3JpcHRpb24iIHwNCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgfCBkZXNjcmlwdGlvbiBvZiB0aGUgIHwgbWVtYmVyIG9mIENL X0lORk8gICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8IGxpYnJh cnkgICAgICAgICAgICAgfCBzdHJ1Y3R1cmUgICAgICAgICAgICB8DQogICAr LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgbGlicmFyeS1tYW51ZmFj dHVyZXIgfCBJRCBvZiB0aGUgQ3J5cHRva2kgIHwgIm1hbnVmYWN0dXJlcklE IiAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8IGxpYnJhcnkg ICAgICAgICAgICAgfCBtZW1iZXIgb2YgdGhlICAgICAgICB8DQoNCg0KDQpQ ZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSAyLCAyMDE1 ICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAg RGVjZW1iZXIgMjAxNA0KDQoNCiAgIHwgICAgICAgICAgICAgICAgICAgICAg fCBtYW51ZmFjdHVyZXIgICAgICAgIHwgQ0tfSU5GTyBzdHJ1Y3R1cmUgICAg fA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IGxpYnJhcnkt dmVyc2lvbiAgICAgIHwgQ3J5cHRva2kgbGlicmFyeSAgICB8ICJsaWJyYXJ5 VmVyc2lvbiIgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCB2 ZXJzaW9uIG51bWJlciAgICAgIHwgbWVtYmVyIG9mIENLX0lORk8gICAgfA0K ICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgfCBzdHJ1Y3R1cmUgICAgICAgICAgICB8DQogICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCiAgIHwgbWFudWZhY3R1cmVyICAgICAgICAgfCBJRCBv ZiB0aGUgdG9rZW4gICAgIHwgIm1hbnVmYWN0dXJlcklEIiAgICAgfA0KICAg fCAgICAgICAgICAgICAgICAgICAgICB8IG1hbnVmYWN0dXJlciAgICAgICAg fCBtZW1iZXIgb2YgICAgICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8IENLX1RPS0VOX0lORk8g ICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgIHwgc3RydWN0dXJlICAgICAgICAgICAgfA0KICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IG1vZGVsICAgICAgICAgICAg ICAgIHwgdG9rZW4gbW9kZWwgICAgICAgICB8ICJtb2RlbCIgbWVtYmVyIG9m ICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgIHwgQ0tfVE9LRU5fSU5GTyAgICAgICAgfA0KICAgfCAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCBzdHJ1 Y3R1cmUgICAgICAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsNCiAgIHwgb2JqZWN0ICAgICAgICAgICAgICAgfCBkZXNjcmlwdGlvbiAo bmFtZSkgIHwgIkNLQV9MQUJFTCIgb2JqZWN0ICAgfA0KICAgfCAgICAgICAg ICAgICAgICAgICAgICB8IG9mIHRoZSBvYmplY3QgICAgICAgfCBhdHRyaWJ1 dGUgICAgICAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN CiAgIHwgc2VyaWFsICAgICAgICAgICAgICAgfCBjaGFyYWN0ZXItc3RyaW5n ICAgIHwgInNlcmlhbE51bWJlciIgICAgICAgfA0KICAgfCAgICAgICAgICAg ICAgICAgICAgICB8IHNlcmlhbCBudW1iZXIgb2YgICAgfCBtZW1iZXIgb2Yg ICAgICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgdGhl IHRva2VuICAgICAgICAgICB8IENLX1RPS0VOX0lORk8gICAgICAgIHwNCiAg IHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg IHwgc3RydWN0dXJlICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rDQogICB8IHNsb3QtZGVzY3JpcHRpb24gICAgIHwgc2xvdCBk ZXNjcmlwdGlvbiAgICB8ICJzbG90RGVzY3JpcHRpb24iICAgIHwNCiAgIHwg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwg bWVtYmVyIG9mICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCBDS19TTE9UX0lORk8gICAg ICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICB8IHN0cnVjdHVyZSAgICAgICAgICAgIHwNCiAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCBzbG90LWlkICAgICAgICAgICAg ICB8IENyeXB0b2tpLWFzc2lnbmVkICAgfCBkZWNpbWFsIG51bWJlciBvZiAg ICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgdmFsdWUgdGhhdCAg ICAgICAgICB8ICJDS19TTE9UX0lEIiB0eXBlICAgIHwNCiAgIHwgICAgICAg ICAgICAgICAgICAgICAgfCBpZGVudGlmaWVzIGEgc2xvdCAgIHwgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQogICB8IHNsb3QtbWFudWZhY3R1cmVyICAgIHwgSUQgb2YgdGhlIHNsb3Qg ICAgICB8ICJtYW51ZmFjdHVyZXJJRCIgICAgIHwNCiAgIHwgICAgICAgICAg ICAgICAgICAgICAgfCBtYW51ZmFjdHVyZXIgICAgICAgIHwgbWVtYmVyIG9m ICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgfCBDS19TTE9UX0lORk8gICAgICAgICB8DQog ICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICB8IHN0cnVjdHVyZSAgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tKw0KICAgfCB0b2tlbiAgICAgICAgICAgICAgICB8IGFwcGxp Y2F0aW9uLWRlZmluZWQgfCAibGFiZWwiIG1lbWJlciBvZiAgICB8DQogICB8 ICAgICAgICAgICAgICAgICAgICAgIHwgbGFiZWwsIGFzc2lnbmVkICAgICB8 IHRoZSBDS19UT0tFTl9JTkZPICAgIHwNCiAgIHwgICAgICAgICAgICAgICAg ICAgICAgfCBkdXJpbmcgdG9rZW4gICAgICAgIHwgc3RydWN0dXJlICAgICAg ICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8IGluaXRpYWxp emF0aW9uICAgICAgfCAgICAgICAgICAgICAgICAgICAgICB8DQogICArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgdHlwZSAgICAgICAgICAgICAg ICAgfCBvYmplY3QgY2xhc3MgKHR5cGUpIHwgIkNLQV9DTEFTUyIgb2JqZWN0 ICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgfCBhdHRyaWJ1dGUgICAgICAgICAgICB8DQogICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgIFRhYmxlIDE6IE1hcHBpbmcgYmV0 d2VlbiBVUkkgcGF0aCBjb21wb25lbnQgYXR0cmlidXRlcyBhbmQgUEtDUyMx MQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNwZWNpZmljYXRpb24g bmFtZXMNCg0KDQoNClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICAgRXhwaXJl cyBKdWx5IDIsIDIwMTUgICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hl bWUgICAgICAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0KICAgVGhlIHF1ZXJ5 IGNvbXBvbmVudCBhdHRyaWJ1dGUgInBpbi1zb3VyY2UiIHNwZWNpZmllcyB3 aGVyZSB0aGUNCiAgIGFwcGxpY2F0aW9uIG9yIGxpYnJhcnkgc2hvdWxkIGZp bmQgdGhlIG5vcm1hbCB1c2VyJ3MgdG9rZW4gUElOLCB0aGUNCiAgICJwaW4t dmFsdWUiIGF0dHJpYnV0ZSBwcm92aWRlcyB0aGUgbm9ybWFsIHVzZXIncyBQ SU4gdmFsdWUgZGlyZWN0bHksDQogICBpZiBuZWVkZWQsIGFuZCB0aGUgIm1v ZHVsZS1uYW1lIiBhbmQgIm1vZHVsZS1wYXRoIiBhdHRyaWJ1dGVzIG1vZGlm eQ0KICAgZGVmYXVsdCBzZXR0aW5ncyBmb3IgYWNjZXNzaW5nIFBLQ1MjMTEg cHJvdmlkZXJzLiAgRm9yIHRoZSBkZWZpbml0aW9uDQogICBvZiBhICJub3Jt YWwgdXNlciIsIHNlZSBbcGtjczExX3NwZWNdLg0KDQogICBUaGUgQUJORiBy dWxlcyBhYm92ZSBpcyBhIGJlc3QgZWZmb3J0IGRlZmluaXRpb24gYW5kIHRo aXMgcGFyYWdyYXBoDQogICBzcGVjaWZpZXMgYWRkaXRpb25hbCBjb25zdHJh aW50cy4gIFRoZSBQS0NTIzExIFVSSSBNVVNUIE5PVCBjb250YWluDQogICBk dXBsaWNhdGUgYXR0cmlidXRlcyBvZiB0aGUgc2FtZSBuYW1lIGluIHRoZSBV UkkgcGF0aCBjb21wb25lbnQuICBJdA0KICAgbWVhbnMgdGhhdCBlYWNoIGF0 dHJpYnV0ZSBtYXkgYmUgcHJlc2VudCBhdCBtb3N0IG9uY2UgaW4gdGhlIFBL Q1MjMTENCiAgIFVSSSBwYXRoLiAgQXNpZGUgZnJvbSB0aGUgcXVlcnkgYXR0 cmlidXRlcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQsDQogICBkdXBsaWNh dGUgKHZlbmRvcikgYXR0cmlidXRlcyBNQVkgYmUgcHJlc2VudCBpbiB0aGUg VVJJIHF1ZXJ5DQogICBjb21wb25lbnQgYW5kIGl0IGlzIHVwIHRvIHRoZSBV UkkgY29uc3VtZXIgdG8gZGVjaWRlIG9uIGhvdyB0byBkZWFsDQogICB3aXRo IHN1Y2ggZHVwbGljYXRlcy4NCg0KICAgVGhlIHdob2xlIHZhbHVlIG9mIHRo ZSAiaWQiIGF0dHJpYnV0ZSBTSE9VTEQgYmUgcGVyY2VudC1lbmNvZGVkIHNp bmNlDQogICBpdCBpcyBzdXBwb3NlZCB0byBiZSBoYW5kbGVkIGFzIGFyYml0 cmFyeSBiaW5hcnkgZGF0YS4NCg0KICAgVGhlICJsaWJyYXJ5LXZlcnNpb24i IGF0dHJpYnV0ZSByZXByZXNlbnRzIHRoZSBtYWpvciBhbmQgbWlub3INCiAg IHZlcnNpb24gbnVtYmVyIG9mIHRoZSBsaWJyYXJ5IGFuZCBpdHMgZm9ybWF0 IGlzICJNLk4iLiAgQm90aCBudW1iZXJzDQogICBhcmUgb25lIGJ5dGUgaW4g c2l6ZSwgc2VlIHRoZSAibGlicmFyeVZlcnNpb24iIG1lbWJlciBvZiB0aGUg Q0tfSU5GTw0KICAgc3RydWN0dXJlIGluIFtwa2NzMTFfc3BlY10gZm9yIG1v cmUgaW5mb3JtYXRpb24uICBWYWx1ZSAiTSIgZm9yIHRoZQ0KICAgYXR0cmli dXRlIE1VU1QgYmUgaW50ZXJwcmV0ZWQgYXMgIk0iIGZvciB0aGUgbWFqb3Ig YW5kICIwIiBmb3IgdGhlDQogICBtaW5vciB2ZXJzaW9uIG9mIHRoZSBsaWJy YXJ5LiAgSWYgdGhlIGF0dHJpYnV0ZSBpcyBwcmVzZW50IHRoZSBtYWpvcg0K ICAgdmVyc2lvbiBudW1iZXIgaXMgUkVRVUlSRUQuICBCb3RoICJNIiBhbmQg Ik4iIE1VU1QgYmUgZGVjaW1hbA0KICAgbnVtYmVycy4NCg0KICAgU2xvdCBJ RCBpcyBhIENyeXB0b2tpLWFzc2lnbmVkIG51bWJlciB0aGF0IGlzIG5vdCBn dWFyYW50ZWVkIHN0YWJsZQ0KICAgYWNyb3NzIFBLQ1MjMTEgbW9kdWxlIGlu aXRpYWxpemF0aW9ucy4gIEhvd2V2ZXIsIHRoZXJlIGFyZSBjZXJ0YWluDQog ICBsaWJyYXJpZXMgYW5kIG1vZHVsZXMgd2hpY2ggcHJvdmlkZSBzdGFibGUg c2xvdCBpZGVudGlmaWVycy4gIEZvcg0KICAgdGhlc2UgY2FzZXMsIHdoZW4g dGhlIHNsb3QgZGVzY3JpcHRpb24gYW5kIG1hbnVmYWN0dXJlciBJRCBpcyBu b3QNCiAgIHN1ZmZpY2llbnQgdG8gdW5pcXVlbHkgaWRlbnRpZnkgYSBzcGVj aWZpYyByZWFkZXIsIHRoZSBzbG90IElEIE1BWSBiZQ0KICAgdXNlZCB0byBp bmNyZWFzZSB0aGUgcHJlY2lzaW9uIG9mIHRoZSB0b2tlbiBpZGVudGlmaWNh dGlvbi4gIEluIG90aGVyDQogICBzY2VuYXJpb3MsIHVzaW5nIHRoZSBzbG90 IElEcyBpcyBsaWtlbHkgdG8gY2F1c2UgdXNhYmlsaXR5IGlzc3Vlcy4NCg0K ICAgQW4gZW1wdHkgUEtDUyMxMSBVUkkgcGF0aCBhdHRyaWJ1dGUgdGhhdCBk b2VzIGFsbG93IGZvciBhbiBlbXB0eQ0KICAgdmFsdWUgbWF0Y2hlcyBhIGNv cnJlc3BvbmRpbmcgc3RydWN0dXJlIG1lbWJlciBvciBhbiBvYmplY3QgYXR0 cmlidXRlDQogICB3aXRoIGFuIGVtcHR5IHZhbHVlLiAgTm90ZSB0aGF0IGFj Y29yZGluZyB0byB0aGUgUEtDUyMxMQ0KICAgc3BlY2lmaWNhdGlvbiBbcGtj czExX3NwZWNdLCBlbXB0eSBjaGFyYWN0ZXIgdmFsdWVzIGluIGEgUEtDUyMx MSBBUEkNCiAgIHByb2R1Y2VyIG11c3QgYmUgcGFkZGVkIHdpdGggc3BhY2Vz IGFuZCBzaG91bGQgbm90IGJlIE5VTEwNCiAgIHRlcm1pbmF0ZWQuDQoNCjMu NC4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBRdWVyeSBBdHRyaWJ1dGUgU2VtYW50 aWNzDQoNCiAgIEFuIGFwcGxpY2F0aW9uIE1BWSBhbHdheXMgYXNrIGZvciBh IFBJTiBieSBhbnkgbWVhbnMgaXQgZGVjaWRlcyB0by4NCiAgIFdoYXQgaXMg bW9yZSwgaW4gb3JkZXIgbm90IHRvIGxpbWl0IFBLQ1MjMTEgVVJJIHBvcnRh YmlsaXR5IHRoZSAicGluLQ0KICAgc291cmNlIiBhdHRyaWJ1dGUgdmFsdWUg Zm9ybWF0IGFuZCBpbnRlcnByZXRhdGlvbiBpcyBsZWZ0IHRvIGJlDQoNCg0K DQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSAyLCAy MDE1ICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAgICAg ICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgIGltcGxlbWVudGF0aW9uIHNwZWNp ZmljLiAgSG93ZXZlciwgdGhlIGZvbGxvd2luZyBydWxlcyBTSE9VTEQgYmUN CiAgIGZvbGxvd2VkIGluIGRlc2NlbmRpbmcgb3JkZXIgZm9yIHRoZSB2YWx1 ZSBvZiB0aGUgInBpbi1zb3VyY2UiDQogICBhdHRyaWJ1dGU6DQoNCiAgIG8g IGlmIHRoZSB2YWx1ZSByZXByZXNlbnRzIGEgbG9jYWwgYWJzb2x1dGUgcGF0 aCB0aGUgaW1wbGVtZW50YXRpb24NCiAgICAgIFNIT1VMRCB1c2UgaXQgYXMg YSBQSU4gZmlsZSBjb250YWluaW5nIHRoZSBQSU4gdmFsdWUNCg0KICAgbyAg aWYgdGhlIHZhbHVlIGNvbnRhaW5zICJ8PGFic29sdXRlLWNvbW1hbmQtcGF0 aD4iIHRoZQ0KICAgICAgaW1wbGVtZW50YXRpb24gU0hPVUxEIHJlYWQgdGhl IFBJTiBmcm9tIHRoZSBvdXRwdXQgb2YgYW4NCiAgICAgIGFwcGxpY2F0aW9u IHNwZWNpZmllZCB3aXRoIGFic29sdXRlIHBhdGggIjxhYnNvbHV0ZS1jb21t YW5kLQ0KICAgICAgcGF0aD4iLiAgTm90ZSB0aGF0IGNoYXJhY3RlciAifCIg cmVwcmVzZW50aW5nIGEgcGlwZSBkb2VzIG5vdCBoYXZlDQogICAgICB0byBi ZSBwZXJjZW50IGVuY29kZWQgaW4gdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0 aGUgUEtDUyMxMSBVUkkuDQoNCiAgIG8gIGlmIHRoZSB2YWx1ZSByZXByZXNl bnRzIGEgVVJJIGl0IFNIT1VMRCBiZSB0cmVhdGVkIGFzIGFuIG9iamVjdA0K ICAgICAgY29udGFpbmluZyB0aGUgUElOLiAgU3VjaCBhIFVSSSBtYXkgYmUg ImZpbGU6IiwgImh0dHBzOiIsIGFub3RoZXINCiAgICAgIFBLQ1MjMTEgVVJJ LCBvciBzb21ldGhpbmcgZWxzZS4NCg0KICAgbyAgaW50ZXJwcmV0IHRoZSB2 YWx1ZSBhcyBuZWVkZWQgaW4gYW4gaW1wbGVtZW50YXRpb24gZGVwZW5kZW50 IHdheQ0KDQogICBJZiBhIFVSSSBjb250YWlucyBib3RoICJwaW4tc291cmNl IiBhbmQgInBpbi12YWx1ZSIgcXVlcnkgYXR0cmlidXRlcw0KICAgdGhlIFVS SSBTSE9VTEQgYmUgcmVmdXNlZCBhcyBpbnZhbGlkLg0KDQogICBVc2Ugb2Yg dGhlICJwaW4tdmFsdWUiIGF0dHJpYnV0ZSBtYXkgaGF2ZSBzZWN1cml0eSBy ZWxhdGVkDQogICBjb25zZXF1ZW5jZXMuICBTZWN0aW9uIDYgc2hvdWxkIGJl IGNvbnN1bHRlZCBiZWZvcmUgdGhpcyBhdHRyaWJ1dGUgaXMNCiAgIGV2ZXIg dXNlZC4gIFN0YW5kYXJkIHBlcmNlbnQgZW5jb2RpbmcgcnVsZXMgU0hPVUxE IGJlIGZvbGxvd2VkIGZvcg0KICAgdGhlIGF0dHJpYnV0ZSB2YWx1ZS4NCg0K ICAgQSBjb25zdW1lciBvZiBQS0NTIzExIFVSSXMgTUFZIG1vZGlmeSBkZWZh dWx0IHNldHRpbmdzIGZvciBhY2Nlc3NpbmcNCiAgIGEgUEtDUyMxMSBwcm92 aWRlciBvciBwcm92aWRlcnMgYnkgYWNjZXB0aW5nIHF1ZXJ5IGNvbXBvbmVu dA0KICAgYXR0cmlidXRlcyAibW9kdWxlLW5hbWUiIGFuZCAibW9kdWxlLXBh dGgiLiINCg0KICAgUHJvY2Vzc2luZyB0aGUgVVJJIHF1ZXJ5IG1vZHVsZSBh dHRyaWJ1dGVzIFNIT1VMRCBmb2xsb3cgdGhlc2UgcnVsZXM6DQoNCiAgIG8g IGF0dHJpYnV0ZSAibW9kdWxlLW5hbWUiIFNIT1VMRCBjb250YWluIGEgY2Fz ZS1pbnNlbnNpdGl2ZSBQS0NTIzExDQogICAgICBtb2R1bGUgbmFtZSAobm90 IHBhdGggbm9yIGZpbGVuYW1lKSB3aXRob3V0IHN5c3RlbSBzcGVjaWZpYw0K ICAgICAgYWZmaXhlcy4gIFN1Y2ggYWZmaXggY291bGQgYmUgYW4gIi5zbyIg b3IgIi5ETEwiIHN1ZmZpeCwgb3IgYQ0KICAgICAgImxpYiIgcHJlZml4LCBm b3IgZXhhbXBsZS4gIE5vdCB1c2luZyBzeXN0ZW0gc3BlY2lmaWMgYWZmaXhl cyBpcw0KICAgICAgZXhwZWN0ZWQgdG8gaW5jcmVhc2UgcG9ydGFiaWxpdHkg b2YgUEtDUyMxMSBVUklzIGFtb25nIGRpZmZlcmVudA0KICAgICAgc3lzdGVt cy4gIEEgVVJJIGNvbnN1bWVyIHNlYXJjaGluZyBmb3IgUEtDUyMxMSBtb2R1 bGVzIFNIT1VMRCB1c2UNCiAgICAgIGEgc3lzdGVtIG9yIGFwcGxpY2F0aW9u IHNwZWNpZmljIGxvY2F0aW9ucyB0byBmaW5kIG1vZHVsZXMgYmFzZWQNCiAg ICAgIG9uIHRoZSBuYW1lIHByb3ZpZGVkIGluIHRoZSBhdHRyaWJ1dGUuDQoN CiAgIG8gIGF0dHJpYnV0ZSAibW9kdWxlLXBhdGgiIFNIT1VMRCBjb250YWlu IGEgc3lzdGVtIHNwZWNpZmljIGFic29sdXRlDQogICAgICBwYXRoIHRvIHRo ZSBQS0NTIzExIG1vZHVsZSwgb3IgYSBzeXN0ZW0gc3BlY2lmaWMgYWJzb2x1 dGUgcGF0aCB0bw0KICAgICAgdGhlIGRpcmVjdG9yeSBvZiB3aGVyZSBQS0NT IzExIG1vZHVsZXMgYXJlIGxvY2F0ZWQuICBGb3Igc2VjdXJpdHkNCiAgICAg IHJlYXNvbnMsIGEgVVJJIHdpdGggYSByZWxhdGl2ZSBwYXRoIGluIHRoaXMg YXR0cmlidXRlIFNIT1VMRCBiZQ0KICAgICAgcmVqZWN0ZWQuDQoNCg0KDQoN ClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICAgRXhwaXJlcyBKdWx5IDIsIDIw MTUgICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hlbWUgICAgICAgICAg ICBEZWNlbWJlciAyMDE0DQoNCg0KICAgbyAgdGhlIFVSSSBjb25zdW1lciBN QVkgcmVmdXNlIHRvIGFjY2VwdCBlaXRoZXIgb2YgdGhlIGF0dHJpYnV0ZXMs IG9yDQogICAgICBib3RoLiAgSWYgdXNlIG9mIGFuIGF0dHJpYnV0ZSBwcmVz ZW50IGluIHRoZSBVUkkgc3RyaW5nIGlzIG5vdA0KICAgICAgYWNjZXB0ZWQg YSB3YXJuaW5nIG1lc3NhZ2UgU0hPVUxEIGJlIHByZXNlbnRlZCB0byB0aGUg cHJvdmlkZXIgb2YNCiAgICAgIHRoZSBVUkkuDQoNCiAgIG8gIGlmIGVpdGhl ciBvZiB0aGUgbW9kdWxlIGF0dHJpYnV0ZXMgaXMgcHJlc2VudCwgb25seSB0 aG9zZSBtb2R1bGVzDQogICAgICBmb3VuZCBtYXRjaGluZyB0aGVzZSBxdWVy eSBhdHRyaWJ1dGVzIFNIT1VMRCBiZSB1c2VkIHRvIHNlYXJjaCBmb3INCiAg ICAgIGFuIGVudGl0eSByZXByZXNlbnRlZCBieSB0aGUgVVJJLg0KDQogICBv ICB1c2Ugb2YgdGhlIG1vZHVsZSBhdHRyaWJ1dGVzIGRvZXMgbm90IHN1cHBy ZXNzIG1hdGNoaW5nIG9mIGFueQ0KICAgICAgb3RoZXIgVVJJIHBhdGggY29t cG9uZW50IGF0dHJpYnV0ZXMgcHJlc2VudCBpbiBhIFVSSS4NCg0KICAgbyAg c2VtYW50aWNzIG9mIHVzaW5nIGJvdGggYXR0cmlidXRlcyBpbiB0aGUgc2Ft ZSBVUkkgc3RyaW5nIGlzDQogICAgICBpbXBsZW1lbnRhdGlvbiBzcGVjaWZp YyBidXQgc3VjaCB1c2UgU0hPVUxEIGJlIGF2b2lkZWQuICBBdHRyaWJ1dGUN CiAgICAgICJtb2R1bGUtbmFtZSIgaXMgcHJlZmVycmVkIHRvICJtb2R1bGUt cGF0aCIgZHVlIHRvIGl0cyBzeXN0ZW0NCiAgICAgIGluZGVwZW5kZW50IG5h dHVyZSBidXQgdGhlIGxhdHRlciBtYXkgYmUgbW9yZSBzdWl0YWJsZSBmb3IN CiAgICAgIGRldmVsb3BtZW50IGFuZCBkZWJ1Z2dpbmcuDQoNCiAgIG8gIGEg VVJJIE1VU1QgTk9UIGNvbnRhaW4gbXVsdGlwbGUgbW9kdWxlIGF0dHJpYnV0 ZXMgb2YgdGhlIHNhbWUNCiAgICAgIG5hbWUuDQoNCiAgIFVzZSBvZiB0aGUg bW9kdWxlIGF0dHJpYnV0ZXMgbWF5IGhhdmUgc2VjdXJpdHkgcmVsYXRlZCBj b25zZXF1ZW5jZXMuDQogICBTZWN0aW9uIDYgc2hvdWxkIGJlIGNvbnN1bHRl ZCBiZWZvcmUgdGhlc2UgYXR0cmlidXRlcyBhcmUgZXZlciB1c2VkLg0KDQog ICBBIHdvcmQgIm1vZHVsZSIgd2FzIGNob3NlbiBvdmVyIHdvcmQgImxpYnJh cnkiIGluIHRoZXNlIHF1ZXJ5DQogICBhdHRyaWJ1dGUgbmFtZXMgdG8gYXZv aWQgY29uZnVzaW9uIHdpdGggc2VtYW50aWNhbGx5IGRpZmZlcmVudA0KICAg bGlicmFyeSBhdHRyaWJ1dGVzIHVzZWQgaW4gdGhlIFVSSSBwYXRoIGNvbXBv bmVudC4NCg0KMy41LiAgUEtDUyMxMSBVUkkgTWF0Y2hpbmcgR3VpZGVsaW5l cw0KDQogICBUaGUgUEtDUyMxMSBVUkkgY2FuIGlkZW50aWZ5IFBLQ1MjMTEg c3RvcmFnZSBvYmplY3RzLCB0b2tlbnMsIHNsb3RzLA0KICAgb3IgQ3J5cHRv a2kgbGlicmFyaWVzLiAgTm90ZSB0aGF0IHNpbmNlIGEgVVJJIG1heSBpZGVu dGlmeSBmb3VyDQogICBkaWZmZXJlbnQgdHlwZXMgb2YgZW50aXRpZXMgdGhl IGNvbnRleHQgd2l0aGluIHdoaWNoIHRoZSBVUkkgaXMgdXNlZA0KICAgbWF5 IGJlIG5lZWRlZCB0byBkZXRlcm1pbmUgdGhlIHR5cGUuICBGb3IgZXhhbXBs ZSwgYSBVUkkgd2l0aCBvbmx5DQogICBsaWJyYXJ5IGF0dHJpYnV0ZXMgbWF5 IGVpdGhlciByZXByZXNlbnQgYWxsIG9iamVjdHMgaW4gYWxsIHRva2VucyBp bg0KICAgYWxsIENyeXB0b2tpIGxpYnJhcmllcyBpZGVudGlmaWVkIGJ5IHRo ZSBVUkksIGFsbCB0b2tlbnMgaW4gdGhvc2UNCiAgIGxpYnJhcmllcywgb3Ig anVzdCB0aGUgbGlicmFyaWVzLg0KDQogICBUaGUgZm9sbG93aW5nIGd1aWRl bGluZXMgY2FuIGhlbHAgYSBQS0NTIzExIFVSSSBjb25zdW1lciAoZWcuIGFu DQogICBhcHBsaWNhdGlvbiBhY2NlcHRpbmcgUEtDUyMxMSBVUklzKSB0byBt YXRjaCB0aGUgVVJJIHdpdGggdGhlIGRlc2lyZWQNCiAgIHJlc291cmNlLg0K DQogICBvICB0aGUgY29uc3VtZXIgTVVTVCBrbm93IHdoZXRoZXIgdGhlIFVS SSBpcyB0byBpZGVudGlmeSBQS0NTIzExDQogICAgICBzdG9yYWdlIG9iamVj dChzKSwgdG9rZW4ocyksIHNsb3QocyksIG9yIENyeXB0b2tpIHByb2R1Y2Vy KHMpLg0KDQogICBvICBpZiB0aGUgY29uc3VtZXIgaXMgd2lsbGluZyB0byBh Y2NlcHQgcXVlcnkgY29tcG9uZW50IG1vZHVsZQ0KICAgICAgYXR0cmlidXRl cyBvbmx5IHRob3NlIFBLQ1MjMTEgcHJvdmlkZXJzIG1hdGNoaW5nIHRoZXNl IGF0dHJpYnV0ZXMNCiAgICAgIFNIT1VMRCBiZSB3b3JrZWQgd2l0aC4gIFNl ZSBTZWN0aW9uIDMuNCBmb3IgbW9yZSBpbmZvcm1hdGlvbi4NCg0KDQoNClBl Y2hhbmVjICYgTW9mZmF0ICAgICAgICAgRXhwaXJlcyBKdWx5IDIsIDIwMTUg ICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hlbWUgICAgICAgICAgICBE ZWNlbWJlciAyMDE0DQoNCg0KICAgbyAgYW4gdW5yZWNvZ25pemVkIGF0dHJp YnV0ZSBpbiB0aGUgVVJJIHBhdGggY29tcG9uZW50LCBpbmNsdWRpbmcgYQ0K ICAgICAgdmVuZG9yIHNwZWNpZmljIGF0dHJpYnV0ZSwgU0hPVUxEIHJlc3Vs dCBpbiBhbiBlbXB0eSBzZXQgb2YNCiAgICAgIG1hdGNoZWQgcmVzb3VyY2Vz LiAgVGhlIGNvbnN1bWVyIFNIT1VMRCBjb25zaWRlciB3aGV0aGVyIGFuIGVy cm9yDQogICAgICBtZXNzYWdlIHByZXNlbnRlZCB0byB0aGUgdXNlciBpcyBh cHByb3ByaWF0ZSBpbiBzdWNoIGEgY2FzZS4NCg0KICAgbyAgYW4gdW5yZWNv Z25pemVkIGF0dHJpYnV0ZSBpbiB0aGUgVVJJIHF1ZXJ5IFNIT1VMRCBiZSBp Z25vcmVkLiAgVGhlDQogICAgICBjb25zdW1lciBTSE9VTEQgY29uc2lkZXIg d2hldGhlciBhIHdhcm5pbmcgbWVzc2FnZSBwcmVzZW50ZWQgdG8NCiAgICAg IHRoZSB1c2VyIGlzIGFwcHJvcHJpYXRlIGluIHN1Y2ggYSBjYXNlLg0KDQog ICBvICBhbiBhdHRyaWJ1dGUgbm90IHByZXNlbnQgaW4gdGhlIFVSSSBwYXRo IGJ1dCBrbm93biB0byBhIGNvbnN1bWVyDQogICAgICBtYXRjaGVzIGV2ZXJ5 dGhpbmcuICBFYWNoIGFkZGl0aW9uYWwgYXR0cmlidXRlIHByZXNlbnQgaW4g dGhlIFVSSQ0KICAgICAgcGF0aCBmdXJ0aGVyIHJlc3RyaWN0cyB0aGUgc2Vs ZWN0aW9uLg0KDQogICBvICBhIGxvZ2ljYWwgZXh0ZW5zaW9uIG9mIHRoZSBh Ym92ZSBpcyB0aGF0IGFuIGVtcHR5IFVSSSBwYXRoIG1hdGNoZXMNCiAgICAg IGV2ZXJ5dGhpbmcuICBGb3IgZXhhbXBsZSwgaWYgdXNlZCB0byBpZGVudGlm eSBzdG9yYWdlIG9iamVjdHMgaXQNCiAgICAgIG1hdGNoZXMgYWxsIGFjY2Vz c2libGUgb2JqZWN0cyBpbiBhbGwgdG9rZW5zIHByb3ZpZGVkIGJ5IGFsbA0K ICAgICAgUEtDUyMxMSBBUEkgcHJvZHVjZXJzIGZvdW5kIGluIHRoZSBzeXN0 ZW0uDQoNCiAgIG8gIG5vdGUgdGhhdCB1c2Ugb2YgUElOIGF0dHJpYnV0ZXMg bWF5IGNoYW5nZSB0aGUgc2V0IG9mIHN0b3JhZ2UNCiAgICAgIG9iamVjdHMg dmlzaWJsZSB0byB0aGUgY29uc3VtZXIuDQoNCiAgIG8gIGluIGFkZGl0aW9u IHRvIHF1ZXJ5IGNvbXBvbmVudCBhdHRyaWJ1dGVzIGRlZmluZWQgaW4gdGhp cw0KICAgICAgZG9jdW1lbnQsIHZlbmRvciBzcGVjaWZpYyBxdWVyeSBhdHRy aWJ1dGVzIG1heSBjb250YWluIGZ1cnRoZXINCiAgICAgIGluZm9ybWF0aW9u IGFib3V0IGhvdyB0byBwZXJmb3JtIHRoZSBzZWxlY3Rpb24gb3Igb3RoZXIg cmVsYXRlZA0KICAgICAgaW5mb3JtYXRpb24uDQoNCjMuNi4gIFBLQ1MjMTEg VVJJIENvbXBhcmlzb24NCg0KICAgQ29tcGFyaXNvbiBvZiB0d28gVVJJcyBp cyBhIHdheSBvZiBkZXRlcm1pbmluZyB3aGV0aGVyIHRoZSBVUklzIGFyZQ0K ICAgZXF1aXZhbGVudCB3aXRob3V0IGNvbXBhcmluZyB0aGUgYWN0dWFsIHJl c291cmNlIHRoZSBVUklzIHBvaW50IHRvLg0KICAgVGhlIGNvbXBhcmlzb24g b2YgVVJJcyBhaW1zIHRvIG1pbmltaXplIGZhbHNlIG5lZ2F0aXZlcyB3aGls ZQ0KICAgc3RyaWN0bHkgYXZvaWRpbmcgZmFsc2UgcG9zaXRpdmVzLg0KDQog ICBUd28gUEtDUyMxMSBVUklzIGFyZSBzYWlkIHRvIGJlIGVxdWFsIGlmIFVS SXMgYXMgY2hhcmFjdGVyIHN0cmluZ3MNCiAgIGFyZSBpZGVudGljYWwgYXMg c3BlY2lmaWVkIGluIFNlY3Rpb24gNi4yLjEgb2YgW1JGQzM5ODZdLCBvciBp ZiBib3RoDQogICBmb2xsb3dpbmcgcnVsZXMgYXJlIGZ1bGZpbGxlZDoNCg0K ICAgbyAgc2V0IG9mIGF0dHJpYnV0ZXMgcHJlc2VudCBpbiB0aGUgVVJJIGlz IGVxdWFsLiAgTm90ZSB0aGF0IHRoZQ0KICAgICAgb3JkZXJpbmcgb2YgYXR0 cmlidXRlcyBpbiB0aGUgVVJJIHN0cmluZyBpcyBub3Qgc2lnbmlmaWNhbnQg Zm9yDQogICAgICB0aGUgbWVjaGFuaXNtIG9mIGNvbXBhcmlzb24uDQoNCiAg IG8gIHZhbHVlcyBvZiByZXNwZWN0aXZlIGF0dHJpYnV0ZXMgYXJlIGVxdWFs IGJhc2VkIG9uIHJ1bGVzIHNwZWNpZmllZA0KICAgICAgYmVsb3cNCg0KICAg VGhlIHJ1bGVzIGZvciBjb21wYXJpbmcgdmFsdWVzIG9mIHJlc3BlY3RpdmUg YXR0cmlidXRlcyBhcmU6DQoNCiAgIG8gIHZhbHVlcyBvZiBwYXRoIGNvbXBv bmVudCBhdHRyaWJ1dGVzICJsaWJyYXJ5LWRlc2NyaXB0aW9uIiwNCiAgICAg ICJsaWJyYXJ5LW1hbnVmYWN0dXJlciIsICJtYW51ZmFjdHVyZXIiLCAibW9k ZWwiLCAib2JqZWN0IiwNCg0KDQoNClBlY2hhbmVjICYgTW9mZmF0ICAgICAg ICAgRXhwaXJlcyBKdWx5IDIsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdl IDExXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFRoZSBQS0NTIzEx IFVSSSBTY2hlbWUgICAgICAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0KICAg ICAgInNlcmlhbCIsICJzbG90LWRlc2NyaXB0aW9uIiwgInNsb3QtbWFudWZh Y3R1cmVyIiwgInRva2VuIiwNCiAgICAgICJ0eXBlIiwgYW5kIHF1ZXJ5IGNv bXBvbmVudCBhdHRyaWJ1dGUgIm1vZHVsZS1uYW1lIiBNVVNUIGJlDQogICAg ICBjb21wYXJlZCB1c2luZyBhIHNpbXBsZSBzdHJpbmcgY29tcGFyaXNvbiBh cyBzcGVjaWZpZWQgaW4NCiAgICAgIFNlY3Rpb24gNi4yLjEgb2YgW1JGQzM5 ODZdIGFmdGVyIHRoZSBjYXNlIGFuZCB0aGUgcGVyY2VudC1lbmNvZGluZw0K ICAgICAgbm9ybWFsaXphdGlvbiBhcmUgYm90aCBhcHBsaWVkIGFzIHNwZWNp ZmllZCBpbiBTZWN0aW9uIDYuMi4yIG9mDQogICAgICBbUkZDMzk4Nl0uDQoN CiAgIG8gIHZhbHVlIG9mIGF0dHJpYnV0ZSAiaWQiIE1VU1QgYmUgY29tcGFy ZWQgdXNpbmcgdGhlIHNpbXBsZSBzdHJpbmcNCiAgICAgIGNvbXBhcmlzb24g YWZ0ZXIgYWxsIGJ5dGVzIGFyZSBwZXJjZW50LWVuY29kZWQgdXNpbmcgdXBw ZXJjYXNlDQogICAgICBsZXR0ZXJzIGZvciBkaWdpdHMgQS1GLg0KDQogICBv ICB2YWx1ZSBvZiBhdHRyaWJ1dGUgImxpYnJhcnktdmVyc2lvbiIgTVVTVCBi ZSBwcm9jZXNzZWQgYXMgYQ0KICAgICAgc3BlY2lmaWMgc2NoZW1lLWJhc2Vk IG5vcm1hbGl6YXRpb24gcGVybWl0dGVkIGJ5IFNlY3Rpb24gNi4yLjMgb2YN CiAgICAgIFtSRkMzOTg2XS4gIFRoZSB2YWx1ZSBNVVNUIGJlIHNwbGl0IGlu dG8gYSBtYWpvciBhbmQgbWlub3IgdmVyc2lvbg0KICAgICAgd2l0aCBjaGFy YWN0ZXIgJy4nIChkb3QpIHNlcnZpbmcgYXMgYSBkZWxpbWl0ZXIuICBMaWJy YXJ5IHZlcnNpb24NCiAgICAgICJNIiBNVVNUIGJlIHRyZWF0ZWQgYXMgIk0i IGZvciB0aGUgbWFqb3IgdmVyc2lvbiBhbmQgIjAiIGZvciB0aGUNCiAgICAg IG1pbm9yIHZlcnNpb24uICBSZXN1bHRpbmcgbWlub3IgYW5kIG1ham9yIHZl cnNpb24gbnVtYmVycyBNVVNUIGJlDQogICAgICB0aGVuIHNlcGFyYXRlbHkg Y29tcGFyZWQgbnVtZXJpY2FsbHkuDQoNCiAgIG8gIHZhbHVlIG9mIGF0dHJp YnV0ZSAic2xvdC1pZCIgTVVTVCBiZSBwcm9jZXNzZWQgYXMgYSBzcGVjaWZp Yw0KICAgICAgc2NoZW1lLWJhc2VkIG5vcm1hbGl6YXRpb24gcGVybWl0dGVk IGJ5IFNlY3Rpb24gNi4yLjMgb2YgW1JGQzM5ODZdDQogICAgICBhbmQgY29t cGFyZWQgbnVtZXJpY2FsbHkuDQoNCiAgIG8gIHZhbHVlIG9mICJwaW4tc291 cmNlIiwgaWYgZGVlbWVkIGNvbnRhaW5pbmcgdGhlIGZpbGVuYW1lIHdpdGgg dGhlDQogICAgICBQSU4gdmFsdWUsIE1VU1QgYmUgY29tcGFyZWQgdXNpbmcg dGhlIHNpbXBsZSBzdHJpbmcgY29tcGFyaXNvbg0KICAgICAgYWZ0ZXIgdGhl IGZ1bGwgc3ludGF4IGJhc2VkIG5vcm1hbGl6YXRpb24gYXMgc3BlY2lmaWVk IGluDQogICAgICBTZWN0aW9uIDYuMi4yIG9mIFtSRkMzOTg2XSBpcyBhcHBs aWVkLiAgSWYgdmFsdWUgb2YgdGhlICJwaW4tDQogICAgICBzb3VyY2UiIGF0 dHJpYnV0ZSBpcyBiZWxpZXZlZCB0byBiZSBvdmVybG9hZGVkIHRoZSBjYXNl IGFuZA0KICAgICAgcGVyY2VudC1lbmNvZGluZyBub3JtYWxpemF0aW9uIFNI T1VMRCBiZSBhcHBsaWVkIGJlZm9yZSB0aGUgdmFsdWVzDQogICAgICBhcmUg Y29tcGFyZWQgYnV0IHRoZSBleGFjdCBtZWNoYW5pc20gb2YgY29tcGFyaXNv biBpcyBsZWZ0IHRvIHRoZQ0KICAgICAgYXBwbGljYXRpb24uDQoNCiAgIG8g IHZhbHVlIG9mIGF0dHJpYnV0ZSAibW9kdWxlLXBhdGgiIE1VU1QgYmUgY29t cGFyZWQgdXNpbmcgdGhlIHNpbXBsZQ0KICAgICAgc3RyaW5nIGNvbXBhcmlz b24gYWZ0ZXIgdGhlIGZ1bGwgc3ludGF4IGJhc2VkIG5vcm1hbGl6YXRpb24g YXMNCiAgICAgIHNwZWNpZmllZCBpbiBTZWN0aW9uIDYuMi4yIG9mIFtSRkMz OTg2XSBpcyBhcHBsaWVkLg0KDQogICBvICB3aGVuIGNvbXBhcmluZyB2ZW5k b3Igc3BlY2lmaWMgYXR0cmlidXRlcyB0aGUgY2FzZSBhbmQgcGVyY2VudC0N CiAgICAgIGVuY29kaW5nIG5vcm1hbGl6YXRpb24gU0hPVUxEIGJlIGFwcGxp ZWQgYmVmb3JlIHRoZSB2YWx1ZXMgYXJlDQogICAgICBjb21wYXJlZCBidXQg dGhlIGV4YWN0IG1lY2hhbmlzbSBvZiBzdWNoIGEgY29tcGFyaXNvbiBpcyBs ZWZ0IHRvDQogICAgICB0aGUgYXBwbGljYXRpb24uDQoNCjQuICBFeGFtcGxl cyBvZiBQS0NTIzExIFVSSXMNCg0KICAgVGhpcyBzZWN0aW9uIGNvbnRhaW5z IHNvbWUgZXhhbXBsZXMgb2YgaG93IFBLQ1MjMTEgdG9rZW4gb2JqZWN0cywN CiAgIHRva2Vucywgc2xvdHMsIGFuZCBsaWJyYXJpZXMgY2FuIGJlIGlkZW50 aWZpZWQgdXNpbmcgdGhlIFBLQ1MjMTEgVVJJDQogICBzY2hlbWUuICBOb3Rl IHRoYXQgaW4gc29tZSBvZiB0aGUgZm9sbG93aW5nIGV4YW1wbGVzLCBuZXds aW5lcyBhbmQNCiAgIHNwYWNlcyB3ZXJlIGluc2VydGVkIGZvciBiZXR0ZXIg cmVhZGFiaWxpdHkuICBBcyBzcGVjaWZpZWQgaW4NCiAgIEFwcGVuZGl4IEMg b2YgW1JGQzM5ODZdLCB3aGl0ZXNwYWNlIFNIT1VMRCBiZSBpZ25vcmVkIHdo ZW4gZXh0cmFjdGluZw0KDQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAg ICBFeHBpcmVzIEp1bHkgMiwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2Ug MTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEg VVJJIFNjaGVtZSAgICAgICAgICAgIERlY2VtYmVyIDIwMTQNCg0KDQogICB0 aGUgVVJJLiAgQWxzbyBub3RlIHRoYXQgYWxsIHNwYWNlcyBhcyBwYXJ0IG9m IHRoZSBVUkkgYXJlIHBlcmNlbnQtDQogICBlbmNvZGVkLCBhcyBzcGVjaWZp ZWQgaW4gQXBwZW5kaXggQSBvZiBbUkZDMzk4Nl0uDQoNCiAgIEFuIGVtcHR5 IFBLQ1MjMTEgVVJJIG1pZ2h0IGJlIHVzZWZ1bCB0byBQS0NTIzExIGNvbnN1 bWVycy4gIFNlZQ0KICAgU2VjdGlvbiAzLjUgZm9yIG1vcmUgaW5mb3JtYXRp b24gb24gc2VtYW50aWNzIG9mIHN1Y2ggYSBVUkkuDQoNCiAgICAgcGtjczEx Og0KDQogICBPbmUgb2YgdGhlIHNpbXBsZXN0IGFuZCBtb3N0IHVzZWZ1bCBm b3JtcyBtaWdodCBiZSBhIFBLQ1MjMTEgVVJJIHRoYXQNCiAgIHNwZWNpZmll cyBvbmx5IGFuIG9iamVjdCBsYWJlbCBhbmQgaXRzIHR5cGUuICBUaGUgZGVm YXVsdCB0b2tlbiBpcw0KICAgdXNlZCBzbyB0aGUgVVJJIGRvZXMgbm90IHNw ZWNpZnkgaXQuICBOb3RlIHRoYXQgd2hlbiBzcGVjaWZ5aW5nDQogICBwdWJs aWMgb2JqZWN0cywgYSB0b2tlbiBQSU4gbWF5IG5vdCBiZSByZXF1aXJlZC4N Cg0KICAgICBwa2NzMTE6b2JqZWN0PW15LXB1YmtleTt0eXBlPXB1YmxpYw0K DQogICBXaGVuIGEgcHJpdmF0ZSBrZXkgaXMgc3BlY2lmaWVkIGVpdGhlciB0 aGUgInBpbi1zb3VyY2UiIGF0dHJpYnV0ZSwNCiAgICJwaW4tdmFsdWUsIG9y IGFuIGFwcGxpY2F0aW9uIHNwZWNpZmljIG1ldGhvZCB3b3VsZCBiZSB1c3Vh bGx5IHVzZWQuDQogICBOb3RlIHRoYXQgJy8nIGlzIG5vdCBwZXJjZW50LWVu Y29kZWQgaW4gdGhlICJwaW4tc291cmNlIiBhdHRyaWJ1dGUNCiAgIHZhbHVl IHNpbmNlIHRoaXMgYXR0cmlidXRlIGlzIHBhcnQgb2YgdGhlIHF1ZXJ5IGNv bXBvbmVudCwgbm90IHRoZQ0KICAgcGF0aCwgYW5kIHRodXMgaXMgc2VwYXJh dGVkIGJ5ICc/JyBmcm9tIHRoZSByZXN0IG9mIHRoZSBVUkkuDQoNCiAgICAg cGtjczExOm9iamVjdD1teS1rZXk7dHlwZT1wcml2YXRlP3Bpbi1zb3VyY2U9 L2V0Yy90b2tlbg0KDQogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgaWRlbnRp ZmllcyBhIGNlcnRpZmljYXRlIGluIHRoZSBzb2Z0d2FyZSB0b2tlbi4NCiAg IE5vdGUgYW4gZW1wdHkgdmFsdWUgZm9yIHRoZSBhdHRyaWJ1dGUgInNlcmlh bCIgd2hpY2ggbWF0Y2hlcyBvbmx5DQogICBlbXB0eSAic2VyaWFsTnVtYmVy IiBtZW1iZXIgb2YgdGhlICJDS19UT0tFTl9JTkZPIiBzdHJ1Y3R1cmUuICBB bHNvDQogICBub3RlIHRoYXQgdGhlICJpZCIgYXR0cmlidXRlIHZhbHVlIGlz IGVudGlyZWx5IHBlcmNlbnQtZW5jb2RlZCwgYXMNCiAgIHJlY29tbWVuZGVk LiAgV2hpbGUgJywnIGlzIGluIHRoZSByZXNlcnZlZCBzZXQgaXQgZG9lcyBu b3QgaGF2ZSB0byBiZQ0KICAgcGVyY2VudC1lbmNvZGVkIHNpbmNlIGl0IGRv ZXMgbm90IGNvbmZsaWN0IHdpdGggYW55IHN1Yi1kZWxpbWl0ZXJzDQogICB1 c2VkLiAgVGhlICcjJyBjaGFyYWN0ZXIgYXMgaW4gIlRoZSBTb2Z0d2FyZSBQ S0NTIzExIFNvZnR0b2tlbiIgTVVTVA0KICAgYmUgcGVyY2VudC1lbmNvZGVk Lg0KDQogICAgIHBrY3MxMTp0b2tlbj1UaGUlMjBTb2Z0d2FyZSUyMFBLQ1Ml MjMxMSUyMFNvZnR0b2tlbjsNCiAgICAgICAgICAgIG1hbnVmYWN0dXJlcj1T bmFrZSUyME9pbCwlMjBJbmMuOw0KICAgICAgICAgICAgbW9kZWw9MS4wOw0K ICAgICAgICAgICAgb2JqZWN0PW15LWNlcnRpZmljYXRlOw0KICAgICAgICAg ICAgdHlwZT1jZXJ0Ow0KICAgICAgICAgICAgaWQ9JTY5JTk1JTNFJTVDJUY0 JUJEJUVDJTkxOw0KICAgICAgICAgICAgc2VyaWFsPQ0KICAgICAgICAgICAg P3Bpbi1zb3VyY2U9L2V0Yy90b2tlbl9waW4NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSAy LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAg ICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgIFRoZSBuZXh0IGV4YW1wbGUg Y292ZXJzIGhvdyB0byB1c2UgdGhlICJtb2R1bGUtbmFtZSIgcXVlcnkgYXR0 cmlidXRlLg0KICAgQ29uc2lkZXJpbmcgdGhhdCB0aGUgbW9kdWxlIGlzIGxv Y2F0ZWQgaW4gL3Vzci9saWIvbGlibXlwa2NzMTEuc28uMQ0KICAgZmlsZSwg dGhlIGF0dHJpYnV0ZSB2YWx1ZSBpcyAibXlwa2NzMTEiLCBtZWFuaW5nIG9u bHkgdGhlIG1vZHVsZSBuYW1lDQogICB3aXRob3V0IHRoZSBmdWxsIHBhdGgs IGFuZCB3aXRob3V0IHRoZSBwbGF0Zm9ybSBzcGVjaWZpYyAibGliIiBwcmVm aXgNCiAgIGFuZCAiLnNvLjEiIHN1ZmZpeC4NCg0KICAgICBwa2NzMTE6b2Jq ZWN0PW15LXNpZ24ta2V5Ow0KICAgICAgICAgICAgdHlwZT1wcml2YXRlDQog ICAgICAgICAgICA/bW9kdWxlLW5hbWU9bXlwa2NzMTENCg0KICAgVGhlIGZv bGxvd2luZyBleGFtcGxlIGNvdmVycyBob3cgdG8gdXNlIHRoZSAibW9kdWxl LXBhdGgiIHF1ZXJ5DQogICBhdHRyaWJ1dGUuICBUaGUgYXR0cmlidXRlIG1h eSBiZSB1c2VmdWwgaWYgYSB1c2VyIG5lZWRzIHRvIHByb3ZpZGUNCiAgIHRo ZSBrZXkgdmlhIGEgUEtDUyMxMSBtb2R1bGUgc3RvcmVkIG9uIGEgcmVtb3Zh YmxlIG1lZGlhLCBmb3INCiAgIGV4YW1wbGUuICBHZXR0aW5nIHRoZSBQSU4g dG8gYWNjZXNzIHRoZSBwcml2YXRlIGtleSBoZXJlIGlzIGxlZnQgdG8NCiAg IGJlIGFwcGxpY2F0aW9uIHNwZWNpZmljLg0KDQogICAgIHBrY3MxMTpvYmpl Y3Q9bXktc2lnbi1rZXk7DQogICAgICAgICAgICB0eXBlPXByaXZhdGUNCiAg ICAgICAgICAgID9tb2R1bGUtcGF0aD0vbW50L2xpYm15cGtjczExLnNvLjEN Cg0KICAgSW4gdGhlIGNvbnRleHQgd2hlcmUgYSB0b2tlbiBpcyBleHBlY3Rl ZCB0aGUgdG9rZW4gY2FuIGJlIGlkZW50aWZpZWQNCiAgIHdpdGhvdXQgc3Bl Y2lmeWluZyBhbnkgUEtDUyMxMSBvYmplY3RzLiAgQSBQSU4gbWlnaHQgc3Rp bGwgYmUgbmVlZGVkDQogICBpbiB0aGUgY29udGV4dCBvZiBsaXN0aW5nIGFs bCBvYmplY3RzIGluIHRoZSB0b2tlbiwgZm9yIGV4YW1wbGUuDQogICBTZWN0 aW9uIDYgc2hvdWxkIGJlIGNvbnN1bHRlZCBiZWZvcmUgdGhlICJwaW4tdmFs dWUiIGF0dHJpYnV0ZSBpcw0KICAgZXZlciB1c2VkLg0KDQogICAgIHBrY3Mx MTp0b2tlbj1Tb2Z0d2FyZSUyMFBLQ1MlMjMxMSUyMHNvZnR0b2tlbjsNCiAg ICAgICAgICAgIG1hbnVmYWN0dXJlcj1TbmFrZSUyME9pbCwlMjBJbmMuDQog ICAgICAgICAgICA/cGluLXZhbHVlPXRoZS1waW4NCg0KICAgSW4gdGhlIGNv bnRleHQgd2hlcmUgYSBzbG90IGlzIGV4cGVjdGVkIHRoZSBzbG90IGNhbiBi ZSBpZGVudGlmaWVkDQogICB3aXRob3V0IHNwZWNpZnlpbmcgYW55IFBLQ1Mj MTEgb2JqZWN0cyBpbiBhbnkgdG9rZW4gaXQgbWF5IGJlDQogICBpbnNlcnRl ZCBpbiBpdC4NCg0KICAgICBwa2NzMTE6c2xvdC1kZXNjcmlwdGlvbj1TdW4l MjBNZXRhc2xvdA0KDQogICBUaGUgQ3J5cHRva2kgbGlicmFyeSBhbG9uZSBj YW4gYmUgYWxzbyBpZGVudGlmaWVkIHdpdGhvdXQgc3BlY2lmeWluZw0KICAg YSBQS0NTIzExIHRva2VuIG9yIG9iamVjdC4NCg0KICAgICBwa2NzMTE6bGli cmFyeS1tYW51ZmFjdHVyZXI9U25ha2UlMjBPaWwsJTIwSW5jLjsNCiAgICAg ICAgICAgIGxpYnJhcnktZGVzY3JpcHRpb249U29mdCUyMFRva2VuJTIwTGli cmFyeTsNCiAgICAgICAgICAgIGxpYnJhcnktdmVyc2lvbj0xLjIzDQoNCg0K DQoNCg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGly ZXMgSnVseSAyLCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2No ZW1lICAgICAgICAgICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgIFRoZSBmb2xs b3dpbmcgZXhhbXBsZSBzaG93cyBhbiBhdHRyaWJ1dGUgdmFsdWUgd2l0aCBh IHNlbWljb2xvbi4gIEluDQogICBzdWNoIGNhc2UgaXQgTVVTVCBiZSBwZXJj ZW50LWVuY29kZWQuICBUaGUgdG9rZW4gYXR0cmlidXRlIHZhbHVlIE1VU1QN CiAgIGJlIHJlYWQgYXMgIk15IHRva2VuOyBjcmVhdGVkIGJ5IEpvZSIuICBM b3dlciBjYXNlIGxldHRlcnMgTUFZIGJlDQogICB1c2VkIGluIHBlcmNlbnQt ZW5jb2RpbmcgYXMgc2hvd24gYmVsb3cgaW4gdGhlICJpZCIgYXR0cmlidXRl IHZhbHVlDQogICBidXQgbm90ZSB0aGF0IFNlY3Rpb25zIDIuMSBhbmQgNi4y LjIuMSBvZiBbUkZDMzk4Nl0gcmVhZCB0aGF0IGFsbA0KICAgcGVyY2VudC1l bmNvZGVkIGNoYXJhY3RlcnMgU0hPVUxEIHVzZSB0aGUgdXBwZXJjYXNlIGhl eGFkZWNpbWFsDQogICBkaWdpdHMuICBNb3JlIHNwZWNpZmljYWxseSwgaWYg dGhlIFVSSSBzdHJpbmcgd2FzIHRvIGJlIGNvbXBhcmVkIHRoZQ0KICAgYWxn b3JpdGhtIGRlZmluZWQgaW4gU2VjdGlvbiAzLjYgZXhwbGljaXRseSByZXF1 aXJlcyBwZXJjZW50LWVuY29kaW5nDQogICB0byB1c2UgdGhlIHVwcGVyY2Fz ZSBkaWdpdHMgQS1GIGluIHRoZSAiaWQiIGF0dHJpYnV0ZSB2YWx1ZXMuICBB bmQgYXMNCiAgIGV4cGxhaW5lZCBpbiBTZWN0aW9uIDMuMywgbGlicmFyeSB2 ZXJzaW9uICIzIiBNVVNUIGJlIGludGVycHJldGVkIGFzDQogICAiMyIgZm9y IHRoZSBtYWpvciBhbmQgIjAiIGZvciB0aGUgbWlub3IgdmVyc2lvbiBvZiB0 aGUgbGlicmFyeS4NCg0KICAgICBwa2NzMTE6dG9rZW49TXklMjB0b2tlbiUy NSUyMGNyZWF0ZWQlMjBieSUyMEpvZTsNCiAgICAgICAgICAgIGxpYnJhcnkt dmVyc2lvbj0zOw0KICAgICAgICAgICAgaWQ9JTAxJTAyJTAzJUJhJWRkJUNh JWZlJTA0JTA1JTA2DQoNCiAgIElmIHRoZXJlIGlzIGFueSBuZWVkIHRvIGlu Y2x1ZGUgbGl0ZXJhbCAiJTsiIHN1YnN0cmluZywgZm9yIGV4YW1wbGUsDQog ICBib3RoIGNoYXJhY3RlcnMgTVVTVCBiZSBlc2NhcGVkLiAgVGhlIHRva2Vu IHZhbHVlIE1VU1QgYmUgcmVhZCBhcyAiQQ0KICAgbmFtZSB3aXRoIGEgc3Vi c3RyaW5nICU7Ii4NCg0KICAgICBwa2NzMTE6dG9rZW49QSUyMG5hbWUlMjB3 aXRoJTIwYSUyMHN1YnN0cmluZyUyMCUyNSUzQjsNCiAgICAgICAgICAgIG9i amVjdD1teS1jZXJ0aWZpY2F0ZTsNCiAgICAgICAgICAgIHR5cGU9Y2VydA0K DQogICBUaGUgbmV4dCBleGFtcGxlIGluY2x1ZGVzIGEgc21hbGwgQSB3aXRo IGFjdXRlIGluIHRoZSB0b2tlbiBuYW1lLiAgSXQNCiAgIE1VU1QgYmUgZW5j b2RlZCBpbiBvY3RldHMgYWNjb3JkaW5nIHRvIHRoZSBVVEYtOCBjaGFyYWN0 ZXIgZW5jb2RpbmcNCiAgIGFuZCB0aGVuIHBlcmNlbnQtZW5jb2RlZC4gIEdp dmVuIHRoYXQgYSBzbWFsbCBBIHdpdGggYWN1dGUgaXMgVSsyMjUNCiAgIHVu aWNvZGUgY29kZSBwb2ludCwgdGhlIFVURi04IGVuY29kaW5nIGlzIDE5NSAx NjEgaW4gZGVjaW1hbCwgYW5kDQogICB0aGF0IGlzICIlQzMlQTEiIGluIHBl cmNlbnQtZW5jb2RpbmcuDQoNCiAgICAgcGtjczExOnRva2VuPU5hbWUlMjB3 aXRoJTIwYSUyMHNtYWxsJTIwQSUyMHdpdGglMjBhY3V0ZTolMjAlQzMlQTE7 DQogICAgICAgICAgICBvYmplY3Q9bXktY2VydGlmaWNhdGU7DQogICAgICAg ICAgICB0eXBlPWNlcnQNCg0KICAgQm90aCB0aGUgcGF0aCBhbmQgcXVlcnkg Y29tcG9uZW50cyBNQVkgY29udGFpbiB2ZW5kb3Igc3BlY2lmaWMNCiAgIGF0 dHJpYnV0ZXMuICBBdHRyaWJ1dGVzIGluIHRoZSBxdWVyeSBjb21wb25lbnQg TVVTVCBiZSBkZWxpbWl0ZWQgYnkNCiAgICcmJy4NCg0KICAgICBwa2NzMTE6 dG9rZW49bXktdG9rZW47DQogICAgICAgICAgICBvYmplY3Q9bXktY2VydGlm aWNhdGU7DQogICAgICAgICAgICB0eXBlPWNlcnQ7DQogICAgICAgICAgICB2 ZW5kb3ItYWFhPXZhbHVlLWENCiAgICAgICAgICAgID9waW4tc291cmNlPS9l dGMvdG9rZW5fcGluDQogICAgICAgICAgICAmdmVuZG9yLWJiYj12YWx1ZS1i DQoNCg0KDQoNCg0KDQoNClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICAgRXhw aXJlcyBKdWx5IDIsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBT Y2hlbWUgICAgICAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0KNS4gIElBTkEg Q29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBtb3ZlcyB0aGUg InBrY3MxMSIgVVJJIHNjaGVtZSBmcm9tIHRoZSBwcm92aXNpb25hbCB0bw0K ICAgcGVybWFuZW50IFVSSSBzY2hlbWUgcmVnaXN0cnkuDQoNCiAgIFRoZSBy ZWdpc3RyYXRpb24gdGVtcGxhdGUgaXMgYXMgZm9sbG93czoNCg0KICAgICAg VVJJIHNjaGVtZSBuYW1lOiBwa2NzMTENCg0KICAgICAgVVJJIHNjaGVtZSBz dGF0dXM6IHBlcm1hbmVudA0KDQogICAgICBVUkkgc2NoZW1lIHN5bnRheDog c2VlIFNlY3Rpb24gMy4zDQoNCiAgICAgIFVSSSBzY2hlbWUgc2VtYW50aWNz OiBzZWUgU2VjdGlvbiAxDQoNCiAgICAgIEVuY29kaW5nIGNvbnNpZGVyYXRp b25zOiBzZWUgU2VjdGlvbiAzLjMNCg0KICAgICAgQXBwbGljYXRpb25zL3By b3RvY29scyB0aGF0IHVzZSB0aGlzIFVSSSBzY2hlbWUgbmFtZTogZm9yIGdl bmVyYWwNCiAgICAgIGluZm9ybWF0aW9uLCBzZWUgU2VjdGlvbiAxLiAgTGlz dCBvZiBrbm93biBjb25zdW1lcnMgb2YgdGhlDQogICAgICBQS0NTIzExIFVS SSBpbmNsdWRlIEdudVRMUywgR25vbWUsIHAxMS1raXQsIFNvbGFyaXMgMTEg YW5kIGhpZ2hlciwNCiAgICAgIE9wZW5TQywgT3BlbkNvbm5lY3QsIGFuZCBG cmVlSVBBLg0KDQogICAgICBJbnRlcm9wZXJhYmlsaXR5IGNvbnNpZGVyYXRp b25zOiBOL0ENCg0KICAgICAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6IHNl ZSBTZWN0aW9uIDYNCg0KICAgICAgQ29udGFjdDogc2VlIEF1dGhvcnMnIEFk ZHJlc3NlcyBzZWN0aW9uDQoNCiAgICAgIEF1dGhvci9DaGFuZ2UgQ29udHJv bGxlcjogc2VlIEF1dGhvcnMnIEFkZHJlc3NlcyBzZWN0aW9uDQoNCiAgICAg IFJlZmVyZW5jZXM6IHNlZSBSZWZlcmVuY2VzIHNlY3Rpb24NCg0KNi4gIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZXJlIGFyZSBnZW5lcmFs IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBVUkkgc2NoZW1lcyBkaXNj dXNzZWQNCiAgIGluIFNlY3Rpb24gNyBvZiBbUkZDMzk4Nl0uDQoNCiAgIEZy b20gdGhvc2Ugc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIFNlY3Rpb24gNy4x IG9mIFtSRkMzOTg2XSBhcHBsaWVzDQogICBzaW5jZSB0aGVyZSBpcyBubyBn dWFyYW50ZWUgdGhhdCB0aGUgc2FtZSBQS0NTIzExIFVSSSB3aWxsIGFsd2F5 cw0KICAgaWRlbnRpZnkgdGhlIHNhbWUgb2JqZWN0LCB0b2tlbiwgc2xvdCwg b3IgYSBsaWJyYXJ5IGluIHRoZSBmdXR1cmUuDQoNCiAgIFNlY3Rpb24gNy4y IG9mIFtSRkMzOTg2XSBhcHBsaWVzIHNpbmNlIGJ5IGFjY2VwdGluZyBxdWVy eSBjb21wb25lbnQNCiAgIGF0dHJpYnV0ZXMgIm1vZHVsZS1uYW1lIiBvciAi bW9kdWxlLXBhdGgiIHRoZSBjb25zdW1lciBwb3RlbnRpYWxseQ0KICAgYWxs b3dzIGxvYWRpbmcgb2YgYXJiaXRyYXJ5IGNvZGUgaW50byBhIHByb2Nlc3Mu DQoNCiAgIFNlY3Rpb24gNy41IG9mIFtSRkMzOTg2XSBhcHBsaWVzIHNpbmNl IHRoZSBQS0NTIzExIFVSSSBtYXkgYmUgdXNlZCBpbg0KICAgd29ybGQgcmVh ZGFibGUgY29tbWFuZCBsaW5lIGFyZ3VtZW50cyB0byBydW4gYXBwbGljYXRp b25zLCBzdG9yZWQgaW4NCiAgIHB1YmxpYyBjb25maWd1cmF0aW9uIGZpbGVz LCBvciBvdGhlcndpc2UgdXNlZCBpbiBjbGVhciB0ZXh0LiAgRm9yDQoNCg0K DQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSAyLCAy MDE1ICAgICAgICAgICAgICAgICBbUGFnZSAxNl0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAgICAg ICAgRGVjZW1iZXIgMjAxNA0KDQoNCiAgIHRoYXQgcmVhc29uIHRoZSAicGlu LXZhbHVlIiBhdHRyaWJ1dGUgc2hvdWxkIG9ubHkgYmUgdXNlZCBpZiB0aGUg VVJJDQogICBzdHJpbmcgaXRzZWxmIGlzIHByb3RlY3RlZCB3aXRoIHRoZSBz YW1lIGxldmVsIG9mIHNlY3VyaXR5IGFzIHRoZQ0KICAgdG9rZW4gUElOIGl0 c2VsZiBvdGhlcndpc2UgaXMuDQoNCjcuICBSZWZlcmVuY2VzDQoNCjcuMS4g IE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5l ciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRl DQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIFJGQyAyMTE5 LCBTVEQgMTQsIE1hcmNoIDE5OTcuDQoNCiAgIFtSRkMzNjI5XSAgWWVyZ2Vh dSwgRi4sICJVVEYtOCwgYSB0cmFuc2Zvcm1hdGlvbiBmb3JtYXQgb2YgSVNP DQogICAgICAgICAgICAgIDEwNjQ2IiwgUkZDIDM2MjksIFNURCA2MywgTm92 ZW1iZXIgMjAwMy4NCg0KICAgW1JGQzM5ODZdICBCZXJuZXJzLUxlZSwgVC4s IEZpZWxkaW5nLCBSLiwgYW5kIEwuIE1hc2ludGVyLCAiVW5pZm9ybQ0KICAg ICAgICAgICAgICBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmlj IFN5bnRheCIsIFJGQyAzOTg2LCBTVEQNCiAgICAgICAgICAgICAgNjYsIEph bnVhcnkgMjAwNS4NCg0KICAgW1JGQzUyMzRdICBDcm9ja2VyLCBELiBhbmQg UC4gT3ZlcmVsbCwgIkF1Z21lbnRlZCBCTkYgZm9yIFN5bnRheA0KICAgICAg ICAgICAgICBTcGVjaWZpY2F0aW9uczogQUJORiIsIFJGQyA1MjM0LCBTVEQg NjgsIEphbnVhcnkgMjAwOC4NCg0KNy4yLiAgSW5mb3JtYXRpdmUgUmVmZXJl bmNlcw0KDQogICBbQkNQMTc4XSAgIFNhaW50LUFuZHJlLCBQLiwgQ3JvY2tl ciwgRC4sIGFuZCBNLiBOb3R0aW5naGFtLA0KICAgICAgICAgICAgICAiRGVw cmVjYXRpbmcgdGhlICJYLSIgUHJlZml4IGFuZCBTaW1pbGFyIENvbnN0cnVj dHMgaW4NCiAgICAgICAgICAgICAgQXBwbGljYXRpb24gUHJvdG9jb2xzIiwg UkZDIDY2NDgsIEJDUCAxNzgsIEp1bmUgMjAxMi4NCg0KICAgW1JGQzQzOTVd ICBIYW5zZW4sIFQuLCBIYXJkaWUsIFQuLCBhbmQgTC4gTWFzaW50ZXIsICJH dWlkZWxpbmVzIGFuZA0KICAgICAgICAgICAgICBSZWdpc3RyYXRpb24gUHJv Y2VkdXJlcyBmb3IgTmV3IFVSSSBTY2hlbWVzIiwgUkZDIDQzOTUsDQogICAg ICAgICAgICAgIEZlYnJ1YXJ5IDIwMDYuDQoNCiAgIFtwa2NzMTFfc3BlY10N CiAgICAgICAgICAgICAgUlNBIExhYm9yYXRvcmllcywgIlBLQ1MgIzExOiBD cnlwdG9ncmFwaGljIFRva2VuIEludGVyZmFjZQ0KICAgICAgICAgICAgICBT dGFuZGFyZCB2Mi4yMCIsIEp1bmUgMjAwNC4NCg0KQXV0aG9ycycgQWRkcmVz c2VzDQoNCiAgIEphbiBQZWNoYW5lYw0KICAgT3JhY2xlIENvcnBvcmF0aW9u DQogICA0MTgwIE5ldHdvcmsgQ2lyY2xlDQogICBTYW50YSBDbGFyYSAgQ0Eg OTUwNTQNCiAgIFVTQQ0KDQogICBFbWFpbDogSmFuLlBlY2hhbmVjQE9yYWNs ZS5DT00NCiAgIFVSSTogICBodHRwOi8vd3d3Lm9yYWNsZS5jb20NCg0KDQoN Cg0KDQoNClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICAgRXhwaXJlcyBKdWx5 IDIsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDE3XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hlbWUgICAg ICAgICAgICBEZWNlbWJlciAyMDE0DQoNCg0KICAgRGFycmVuIEouIE1vZmZh dA0KICAgT3JhY2xlIENvcnBvcmF0aW9uDQogICBPcmFjbGUgUGFya3dheQ0K ICAgVGhhbWVzIFZhbGxleSBQYXJrDQogICBSZWFkaW5nICBSRzYgMVJBDQog ICBVSw0KDQogICBFbWFpbDogRGFycmVuLk1vZmZhdEBPcmFjbGUuQ09NDQog ICBVUkk6ICAgaHR0cDovL3d3dy5vcmFjbGUuY29tDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAg ICAgICAgIEV4cGlyZXMgSnVseSAyLCAyMDE1ICAgICAgICAgICAgICAgICBb UGFnZSAxOF0NCg== ---559023410-570397931-1419918818=:1509-- From nobody Tue Dec 30 04:56:02 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4F41A0097; Tue, 30 Dec 2014 04:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9sQ1d_iqgs7; Tue, 30 Dec 2014 04:55:54 -0800 (PST) Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD51C1A0095; Tue, 30 Dec 2014 04:55:53 -0800 (PST) X-SBRS: None Received: from unknown (HELO mucxv001.muc.infineon.com) ([172.23.11.16]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Dec 2014 13:55:51 +0100 Received: from MUCSE607.infineon.com (mucltm01.eu.infineon.com [172.23.8.248]) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Tue, 30 Dec 2014 13:55:53 +0100 (CET) Received: from KLUSE610.infineon.com (172.28.156.137) by MUCSE607.infineon.com (172.23.7.108) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 30 Dec 2014 13:55:50 +0100 Received: from KLUSE610.infineon.com (172.28.156.137) by KLUSE610.infineon.com (172.28.156.137) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 30 Dec 2014 13:55:49 +0100 Received: from KLUSE610.infineon.com ([172.28.148.8]) by KLUSE610.infineon.com ([172.28.148.8]) with mapi id 15.00.0995.032; Tue, 30 Dec 2014 13:55:49 +0100 From: To: , , Thread-Topic: secdir review of draft-ietf-roll-admin-local-policy-02 Thread-Index: AdAff2eol7wcDrkvTNS1G9OE6YCkGQ== Date: Tue, 30 Dec 2014 12:55:48 +0000 Message-ID: <7e9a24ab8a294586bc19f23673551c24@KLUSE610.infineon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.23.8.247] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0991_01D02406.03E075F0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/rKZR76ePNvuGD7Mo5pHYvXnixQw Subject: [secdir] secdir review of draft-ietf-roll-admin-local-policy-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 12:55:57 -0000 ------=_NextPart_000_0991_01D02406.03E075F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0992_01D02406.03E075F0" ------=_NextPart_001_0992_01D02406.03E075F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a technique for automatically managing the boundaries of the admin-local multicast scope in a border router, using MPL (Multicast Protocol for Low power and Lossy Networks). In my view, this document is Not Ready. The document is hard to understand. For example, the acronyms MPL and MPL4 are used throughout the document but they are not defined. After reading the document several times, I have concluded that section 3.2 contains the most important part of the document: an algorithm for automatically defining the boundaries of the admin-local multicast scope using MPL. This section basically says that a border router should periodically send an MPL message on all interfaces to the ALL_MPL_FORWARDERS multicast address with admin-local scope. It should also listen for such messages on all interfaces. If it receives such a message, that interface should be marked as part of the admin-local scope. This algorithm seems problematic from a security standpoint. Because any device on a network can send an MPL message to the ALL_MPL_FORWARDERS multicast address with admin-local scope, the boundaries of the admin-local multicast scope can be expanded by attackers fairly easily. Such manipulation may permit nodes that should be outside a particular administrative domain to join that domain and participate in receiving and sending multicast traffic within that domain. The implications of such an attack are not clear to me because I am not familiar with the protocols and devices that use admin-local multicast scope. However, it seems likely that expanding the admin-local multicast scope will permit external attackers to more easily monitor multicast traffic that should be private and to inject multicast messages into a relatively trusted domain. In addition to this fundamental concern, I have a few minor concerns about the readability of the document. However, I seem to have mislaid my notes during the holidays. Because this review is already late and I'm on vacation, I will send the review now and follow up with the minor concerns at a later date if I can find them when I return to the office. Thanks, Steve ------=_NextPart_001_0992_01D02406.03E075F0 Content-Type: text/html; 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 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 a technique for automatically managing the boundaries = of the admin-local multicast scope in a border router, using MPL = (Multicast Protocol for Low power and Lossy Networks).

 

In my view, = this document is Not Ready.

 

The document = is hard to understand. For example, the acronyms MPL and MPL4 are used = throughout the document but they are not defined.

 

After = reading the document several times, I have concluded that section 3.2 = contains the most important part of the document: an algorithm for = automatically defining the boundaries of the admin-local multicast scope = using MPL. This section basically says that a border router should = periodically send an MPL message on all interfaces to the = ALL_MPL_FORWARDERS multicast address with admin-local scope. It should = also listen for such messages on all interfaces. If it receives such a = message, that interface should be marked as part of the admin-local = scope.

 

This algorithm seems problematic from a security = standpoint. Because any device on a network can send an MPL message to = the ALL_MPL_FORWARDERS multicast address with admin-local scope, the = boundaries of the admin-local multicast scope can be expanded by = attackers fairly easily. Such manipulation may permit nodes that should = be outside a particular administrative domain to join that domain and = participate in receiving and sending multicast traffic within that = domain. The implications of such an attack are not clear to me because I = am not familiar with the protocols and devices that use admin-local = multicast scope. However, it seems likely that expanding the admin-local = multicast scope will permit external attackers to more easily monitor = multicast traffic that should be private and to inject multicast = messages into a relatively trusted domain.

 

In addition = to this fundamental concern, I have a few minor concerns about the = readability of the document. However, I seem to have mislaid my notes = during the holidays. Because this review is already late and I’m = on vacation, I will send the review now and follow up with the minor = concerns at a later date if I can find them when I return to the = office.

 

Thanks,

 

Steve

 

------=_NextPart_001_0992_01D02406.03E075F0-- ------=_NextPart_000_0991_01D02406.03E075F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM7jCCA+4w ggLWoAMCAQICEGsk517Bqmu0TbjoYC/BbAIwDQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCZGUx ITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVj aG5vbG9naWVzIEFHIFJvb3QgQ0EgMjAeFw0xMTA3MjYxMzEyMjBaFw0zNjA3MjYxMzIyMjBaMF0x CzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMT IkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDMQpw2+wMM1Zu9gvlmBJSMi0GGkpvNL+RUfdNatlMGrliwyaCEB+HZzZP9CLys cLIglTKWeANzKozlAjE4ubdO/Y1IBmnuJMDW2lI73bZOwR2Y0shwmO1esRd2EyGCtVa9RgKa7HD3 pEHJAXlu9+IejoYv94lF80E/5jsNMeczlwUV7cF3NwXQKMoRd1BHGtFnwwOqIVELmDC/coQM6UXe MlUzYpfVJyqdCiNHU0wPzFNyeDObgDOLNIH222OuRR5wsDvmDiP/6j8QPTBJ71uGWlFE6B7cVvAO QXVDCZYLpfQLkNFnG8BElOH7gSzuAiBvQtoERRC1QyZZC2MEValdAgMBAAGjgakwgaYwDgYDVR0P AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFDhv1fR35slaIStRFWrWIKsC DacVMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9v dGNhMi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEB BQUAA4IBAQCsiCetpToA0t9yFxPkiw1pekvEPPEeOqsMEGa/Xf6JyqZCC0lSAyu9Uo6l6YSCAb73 f0TjNH0JDNApW2q6556qloVM0almOTirDaM+R8bJzeRg7xHeZriif9QWfA9czBfK6MSDTDULatcH mJwNznVQWuRBefTg/txo0OuPvvmbuGVT8hhdEf1fu0rcX7fE1X7zP27opZ3DjMk+ocu9MRk3L+Cw ISxiCfo2af0hWLZBTuQPqODjx73waxOAK317QwRC4m84BwUEZ3IR3CfvK3ukk6UQ8Pgl6SmDdzNw KGVNo+tNELKtgW125xQ5znatvPJQjYJjhB0XikvWjdKJL48PMIIEIzCCAwugAwIBAgIKYR4k+gAA AAAAAjANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGEwJkZTEhMB8GA1UEChMYSW5maW5lb24gVGVj aG5vbG9naWVzIEFHMSswKQYDVQQDEyJJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcgUm9vdCBDQSAy MB4XDTExMDcyNzEyMzIwNVoXDTI2MDcyNzEyNDIwNVowXTELMAkGA1UEBhMCZGUxITAfBgNVBAoT GEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVz IEFHIFVzZXIgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKBHZyb03ScBt//g 4A4cOg5bRHXlpCBOyzJo/X4sMpuxu+47KFkVAIWhUlyhVk4f22+EDos6Ley7/10Pl7VNBuTj0i07 P5vjTbT/CgshA3mcRb4xqyXZx4Eh/rnMicAlXQ8OUhbg+uBMjBOuvQrhXg2epP6+etKdg6LlXDrD edZflpmIGvn8sgGyfbAiH0Wy/HGJngg6dncHacL6hPzGTrhR4bJwTnogxhN7NaDmuU1OxzKjsPc7 cidAmTtIlGpEfXj162C8GZ6vQjmBjH+ZqEdnz86IPGnUHb4Ifoa/GVzSlH0hPtMmybczi/BAcAQO obiKhfCbpNU8/nXhuiQ3kbcCAwEAAaOB5DCB4TALBgNVHQ8EBAMCAYYwHQYDVR0OBBYEFBoYmNi4 E/3bHsoMirMTA3B3wxeWMB8GA1UdIwQYMBaAFDhv1fR35slaIStRFWrWIKsCDacVMDwGA1UdHwQ1 MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9vdGNhMi5jcmwwEgYD VR0TAQH/BAgwBgEB/wIBADBABgNVHSAEOTA3MDUGCyqCFABEChQBAQEBMCYwJAYIKwYBBQUHAgEW GGh0dHBzOi8vY3BzLmluZmluZW9uLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAbOjg2haQMCPP0ZcS 1+hd0teYaBpi2LpwADGVyFAUO2UuPKGxAfYxWf3/v0FNW2IOhNKj8w3f076sKkeSlb6WiZZIe+ao kG2H6AimMIlhvv4GGAFHzQLVclXIz9jM7H4fH/wA/gHE4wDE1dvsGVjeM2fEjwTOtNrPzGF9SF1s NyJy8a2AZ83b6J6WIN72Jg2KXXQuVsa61/q2C5AAMfXLL4shuWN1JnYO03PBUjYWxqNdcETppKhc swaIZJ0MjKDttzuT9IntFeoOYMJx27KGowOqMDbmRoXRGWZahO4m4UkjIo9uzMX7U5EQymoMiVJc Ndp3qT5b48QXhmDe7Cmd4DCCBNEwggO5oAMCAQICAn7aMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNV BAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMTIkluZmlu ZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDIwHhcNMTQwNTA4MDYzMDI0WhcNMTkwNTA4MDYz MDI0WjCBgjELMAkGA1UEBhMCVVMxMjAwBgNVBAoTKUluZmluZW9uIFRlY2hub2xvZ2llcyBOb3J0 aCBBbWVyaWNhIENvcnAuMRYwFAYDVQQDEw1TdGVwaGVuIEhhbm5hMScwJQYJKoZIhvcNAQkBFhhT dGV2ZS5IYW5uYUBpbmZpbmVvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCA FtObO7F+pUxS4qh2dVM0xI9zDZquunmkxtfb7TG3IXsd7NaqDYBXI67jA3WfxI/DHp3ub0ZuQ3qv JLzsdCr5FQgDDh7MBvesFRoYa6RHT/dUWE9SGjexFquQRHP75ZYxNBw3zOYpr87XFE1rsjXIQp7s 2ehfZLiIEr3NkyzjeAqBw6EfT65Dy598EWFon2Ky/QfJsDmBAfTc4+Ews2suhvS8x2pqSwHtOLNF PK2zD+zFsBdZJyv+ZawWaLO/B8aAwavVBDYBd3S5/4FJKEG8ednZpetkNQ2aMMg3Lnay8/t9UvcY jS810qTNVOEfiyZBzlJi53I4Nhw35UC6o1P5AgMBAAGjggFzMIIBbzA/BgNVHREEODA2gRhTdGV2 ZS5IYW5uYUBpbmZpbmVvbi5jb22BGlN0ZXBoZW4uSGFubmFAaW5maW5lb24uY29tMEAGA1UdIAQ5 MDcwNQYLKoIUAEQKFAEBAQEwJjAkBggrBgEFBQcCARYYaHR0cHM6Ly9jcHMuaW5maW5lb24uY29t MDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3VzZXJjYTIvdXNlcmNh Mi5jcmwwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMEcGCCsGAQUFBwEBBDsw OTA3BggrBgEFBQcwAoYraHR0cDovL2NybC5pbmZpbmVvbi5jb20vdXNlcmNhMi91c2VyY2EyLmNy dDAfBgNVHSMEGDAWgBQaGJjYuBP92x7KDIqzEwNwd8MXljAdBgNVHQ4EFgQUhs576DHwRkp1mWLi fTZ7b4yVe+UwDQYJKoZIhvcNAQEFBQADggEBADKEDQXoKMcxN3zhhg3gfoVJII4Y8BWdjTzs5q2D bivs+8Ic8v/7KT3a61Gmz+BJx/8kWTe8LbJtk3GM0ui1MLUo8110r7qnvNtTtM8hYAuQGXYDGhkh H2PmZG7VSgB6G6DFNLA/017Uqvz6UiRLTUJcge7VJvk40cxJ1Mzs240+JVW9nLb/Fn+zI5KJj573 tXv7LTNVK2whVD7fJ3s07JGh75QYw5NusaHT9/4Zh/7idDdE/ailMY9pPvEtbVWcBnQxcXSoFEiM LKZFJ3o8nN7XFscSUqGRNNVYrAxpcktrnbz+assus7SbIYDpkOAOToBIWkdcxTXOWkv0Me9tVGcx ggODMIIDfwIBATBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMAkG BSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0 MTIzMDEyNTU0NFowIwYJKoZIhvcNAQkEMRYEFNN3u/Stpd+flNfsPjWHzrjn/0reMHIGCSsGAQQB gjcQBDFlMGMwXTELMAkGA1UEBhMCZGUxITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBB RzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVzIEFHIFVzZXIgQ0EgMgICftowdAYLKoZI hvcNAQkQAgsxZaBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMIGr BgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzAL BglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAAvHygvNT90tCh4fWAQMl1ZT9TcfjdWESddqtU1MDzP3ZTQyF3ZG j5/fmnaxmLSlZPEaJKkNIKSxtCp//9mqTCxiJ9DDawmkuszuIOoLFyZVc8K9FmjBc9IHPbdTBGgi m0zOnMp7lQwNx90mcdjZ6kQAFpGJ/KwvX8OjW4xdpAXS1sJlRDLbdMTsriIouOtOPzlmQQ1A4gUp 9zUGIeTzwqEau42uk/1Xce5yrWAUYZZ831XbDSNwiByrXJnWjbl3xl7d0IkID/+oGUTuwFiwjLIc pxGL4TOAuJcJNwW88M1JeO8fiZbxFmMT2dg7NAU9TKcc6yvex4zCi4tHnNHH36IAAAAAAAA= ------=_NextPart_000_0991_01D02406.03E075F0-- From nobody Tue Dec 30 09:52:23 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEE71A03A2; Tue, 30 Dec 2014 09:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZpCk93G4XDQ; Tue, 30 Dec 2014 09:52:15 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE571A039B; Tue, 30 Dec 2014 09:52:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1C092BEC6; Tue, 30 Dec 2014 17:52:13 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Idy-Syw0W_bO; Tue, 30 Dec 2014 17:52:11 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.41.60.190]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7389DBEC4; Tue, 30 Dec 2014 17:52:10 +0000 (GMT) Message-ID: <54A2E649.9060705@cs.tcd.ie> Date: Tue, 30 Dec 2014 17:52:09 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Donald Eastlake , "iesg@ietf.org" , draft-ietf-httpauth-hoba.all@tools.ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Th71dLj4wqExxahoOYRrtBLthpk Cc: "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 17:52:18 -0000 Hi Donald, Thanks for the review. On 28/12/14 20:50, Donald Eastlake 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. Document editors and WG chairs should treat these comments just > like any other last call comments. > > This draft specifies an Experimental protocol to use digital > signatures in response to challenges for authentication to HTTP > servers as a replacement for passwords. There are a lot more details > than that and considerable effort has been put into making this fit > into existing web authentication so as to be easily deployable. > Overall, it looks like a good job. See comments below. > > As a heavily security oriented draft, I recommend it be looked at by > the non-author Security AD :-) Reasonable plan:-) I'm sure Kathleen has it in hand. > > >> Security Comments < > --------------------- > > This draft is fairly clear about what happens when mandatory 2119 > requirements are violated in strictly security contexts, such as a > signature not validating. But is generally doesn't say much about > what happens when mandatory formatting requirements are violated. I > guess if things don't parse, then authentication will fail. But, for > example, it says "The "realm" attribute MUST NOT appear more than > once." Whenever I see something like that, I say to myself, OK, so > what happens if the "MUST NOT" is violated? If the spec says nothing, > then I would expect that with some implementations authentication > would fail while others would use the first realm attribute and still > others would use the last realm attribute. Could that be a problem? Well, we could add a generic sentence saying "if formatting is bad in any way then servers MUST fail authentication" but I think that'd just be repetition really. > > This draft uses "random" and "randomness" in various places without > any reference/definition. True. I'd argue that that's ok, but I suppose a reference to rfc4086 might be useful. If pressed, I'd not object to adding one. > > Security Considerations: > > Perhaps there should be a reference in the Security Considerations > section to Section 1.1. I think that'd just be repetitive though, the point is made in 1.1. > > Can some level of confusion/denial be caused by setting max-age to a > lower value than the server intended? I don't believe so. > > Appendix B: It is good that an example is provided it seems like some > things are missing. Shouldn't it specify the "alg" string and wouldn't > it be useful if it gave the TBS blob explicitly? Yep - you're right that we ought say its rsa-sha256, though to be fair the consumer of the example only has two values from which to guess;-) But if there's any change made (almost inevitable:-) then I'll make sure to include that in a -09. > >> Wording/Format Comments < > --------------------------- > > Abstract: I always worry about words like "all" (or, being recursive > to this sentence, "always" :-). I suggest deleting the one occurrence > of "all" in the Abstract. > > Page 5, Section 1.2 > OLD > That will contain of at least one CPK and a web-origin; > ^^ > NEW > That will contain at least one CPK and a web-origin; Ah crap - so I defo do need a -09, ah well, I'll make the chages above as well so:-) > > Page 6/7/13, Figure 1/2/3: I'm not sure that something that is > entirely textural is best called a "Figure". But in any case, since > the text is, or at least has, lines that are flush left, it looks like > part of the preceding text and there isn't a clear demarcation of the > start. I recommend that the body of the Figures be indented 3 or 4 > spaces. I'd prefer let the RFC editor fix those if needed. > > Page 6, Section 2: > - For "alg" inconsistently says it is "an ASCII character" and "ASCII > numbers" where perhaps it should say "an ASCII encoded one or two digit > non-negative integer" or something. Tweaked to remove a bit of repetition. > - For "origin" perhaps the example should note that it would be > prefixed by "28:" in the TBS blob. That's the len all right, but that's just a per the abnf. I don't think saying so would make it easier to code. > - Delete one of the two sequential occurrences of "reduce the amount > of". Did that. > > Page 10, Section 5: > I suggest rewording this sentence: > OLD > This section also > covers the actions that give HOBA similar user features as today's > passwords have. > NEW > This section also > covers the actions that give HOBA user features similar to today's > passwords. Almost > > Page 16, Section 6.4: duplicated word "response". Sigh, why do I keep doing that:-) > > Page 18, Section 8.2: Is it a good idea to mention a particular > on-line service name here? I think its fair. > > Page 19, IANA Considerations: It seems from > draft-leiba-coton-iana-5226bis that IANA would prefer IANA > Considerations to be written in the past tense as if the actions had > already been accomplished, presumably to minimize IANA re-writing > effort. Thus, I suggest that consideration be given to changing the > initial part, between the Section 9 heading and the Section 9.1 > heading, to the following and making similar changes in the remainder > of the IANA Considerations Section: > > IANA has created the registries and made the registration specified > below, placing the new registries in a new "HTTP Origin-Bound > Authentication (HOBA) Parameters" category. I'd rather not go there. I've also seen the opposite request made so would prefer to not be involved in such bureaucratic battles:-) > > Page 20, Section 9.3: A better way to note the restriction on > potential values of Algorithm Name would be to add a third entry to > the registry something like the following (there should also be a > third Reference column): > > 2-99 Unassigned [this document] I'm not convinced that's better tbh and as-is its fine so no change there. > > Page 20, Section 9.4: Suggest the "Meaning" for 2 be "an unformatted > UTF8 string". There should probably be a Reference column. "a small > positive integer" is undefined. Oh come on. Small positive integer utterly clear as is unformatted string in this context. UTF8 isn't needed here as this is not meant to be seen by a user. > > Page 20, Section 9.5: Seems like this should say "UTF8 string" and I'm > not sure it needs "at the user's/UA's whim". There should also be a > "[this document]" entry in a Reference column. I added UTF8 since this could be presented to a user. (Good catch that.) I didn't make the other changes. > > Maybe there should be ABNF for "kid" and "did" somewhere. Since "kid" > and "did" are ordinary English words, suggest globally replacing them > with "KID" and "DID" respectively. No thanks - it's clear enough and upper case wouldn't make it better I think. > > Page 24, Appendix A > This is a nice appendix but there is no reference to it anywhere in the > body of the draft. Suggest adding such a reference to the > Introduction. I think we had it earlier and were asked to take it out. And I think that's fine as-is. Thanks for the good catches. I've a working copy of a -09 at [1], with the diff vs. -08 at [2]. I'll wait for Kathleen to say if she wants that posted now or not, as almost all the changes are nit-fixes. Cheers, S. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-09.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-08.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-09.txt > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > From nobody Tue Dec 30 10:19:39 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580B61A1A15; Tue, 30 Dec 2014 10:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Irb6vU5fLO9U; Tue, 30 Dec 2014 10:19:27 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352811A0371; Tue, 30 Dec 2014 10:19:27 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id dc16so10424485qab.36; Tue, 30 Dec 2014 10:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pg0VmZ0oNG20wCqR+/dSlfRLMoUg0YtTp3yjK9EXbKY=; b=U8Ei1vS+2m2T5ok02I3ZpL65HszKO2nkXibeA0+bPO323fAbYN1EF8waOcszgUCWcq UP21TK3PqYkWWVAr39wZcJrQREvlt++R9OCinTGGLeKr38LUxceTK+qGWWN0xuQ23cQL aTTge+gUEYQqpNnpjUYhGOIM7Ffb/do947KtuEuMgXVH8emy7cFPWkOYiZGkvJtHqb4N E0Ge/DPQqCv866wE49fzvzcOy/vI1Iu1NEMl/ChtZ/hrPx0IrA4glBB9tbRzUqPgBMzG RfueNGz1+aD4wFGE3v09iPz/jSdUTgXukGixAVtr8QS/SkLdAULlNvgRRItqCYHHNlqv mOkg== X-Received: by 10.224.25.139 with SMTP id z11mr68139699qab.17.1419963566007; Tue, 30 Dec 2014 10:19:26 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id j21sm1005683qgd.36.2014.12.30.10.19.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Dec 2014 10:19:24 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <54A2E649.9060705@cs.tcd.ie> Date: Tue, 30 Dec 2014 13:19:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <95B2FD3B-4776-4DCA-8D26-F80C8C8C4A51@gmail.com> References: <54A2E649.9060705@cs.tcd.ie> To: Stephen Farrell Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ipVKKQsIRMogdaiv9alp0VpDW4U Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 18:19:31 -0000 Thanks for the review, Donald and the quick response, Stephen. Too posting,= sorry. Yes, please do go ahead and post the -09 version to correct the mostly edito= rial changes in case it helps any of the IESG reviews. I'll add the ballot a= fter that. Thanks, Kathleen Sent from my iPhone > On Dec 30, 2014, at 12:52 PM, Stephen Farrell w= rote: >=20 >=20 > Hi Donald, >=20 > Thanks for the review. >=20 >> On 28/12/14 20:50, Donald Eastlake 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. Document editors and WG chairs should treat these comments just >> like any other last call comments. >>=20 >> This draft specifies an Experimental protocol to use digital >> signatures in response to challenges for authentication to HTTP >> servers as a replacement for passwords. There are a lot more details >> than that and considerable effort has been put into making this fit >> into existing web authentication so as to be easily deployable. >> Overall, it looks like a good job. See comments below. >>=20 >> As a heavily security oriented draft, I recommend it be looked at by >> the non-author Security AD :-) >=20 > Reasonable plan:-) I'm sure Kathleen has it in hand. >=20 >>=20 >>=20 >>> Security Comments < >> --------------------- >>=20 >> This draft is fairly clear about what happens when mandatory 2119 >> requirements are violated in strictly security contexts, such as a >> signature not validating. But is generally doesn't say much about >> what happens when mandatory formatting requirements are violated. I >> guess if things don't parse, then authentication will fail. But, for >> example, it says "The "realm" attribute MUST NOT appear more than >> once." Whenever I see something like that, I say to myself, OK, so >> what happens if the "MUST NOT" is violated? If the spec says nothing, >> then I would expect that with some implementations authentication >> would fail while others would use the first realm attribute and still >> others would use the last realm attribute. Could that be a problem? >=20 > Well, we could add a generic sentence saying "if formatting is bad in > any way then servers MUST fail authentication" but I think that'd > just be repetition really. >=20 >>=20 >> This draft uses "random" and "randomness" in various places without >> any reference/definition. >=20 > True. I'd argue that that's ok, but I suppose a reference to rfc4086 > might be useful. If pressed, I'd not object to adding one. >=20 >>=20 >> Security Considerations: >>=20 >> Perhaps there should be a reference in the Security Considerations >> section to Section 1.1. >=20 > I think that'd just be repetitive though, the point is made in 1.1. >=20 >>=20 >> Can some level of confusion/denial be caused by setting max-age to a >> lower value than the server intended? >=20 > I don't believe so. >=20 >>=20 >> Appendix B: It is good that an example is provided it seems like some >> things are missing. Shouldn't it specify the "alg" string and wouldn't >> it be useful if it gave the TBS blob explicitly? >=20 > Yep - you're right that we ought say its rsa-sha256, though to be fair > the consumer of the example only has two values from which to guess;-) > But if there's any change made (almost inevitable:-) then I'll make > sure to include that in a -09. >>=20 >>> Wording/Format Comments < >> --------------------------- >>=20 >> Abstract: I always worry about words like "all" (or, being recursive >> to this sentence, "always" :-). I suggest deleting the one occurrence >> of "all" in the Abstract. >>=20 >> Page 5, Section 1.2 >> OLD >> That will contain of at least one CPK and a web-origin; >> ^^ >> NEW >> That will contain at least one CPK and a web-origin; >=20 > Ah crap - so I defo do need a -09, ah well, I'll make the chages > above as well so:-) >=20 >>=20 >> Page 6/7/13, Figure 1/2/3: I'm not sure that something that is >> entirely textural is best called a "Figure". But in any case, since >> the text is, or at least has, lines that are flush left, it looks like >> part of the preceding text and there isn't a clear demarcation of the >> start. I recommend that the body of the Figures be indented 3 or 4 >> spaces. >=20 > I'd prefer let the RFC editor fix those if needed. >=20 >>=20 >> Page 6, Section 2: >> - For "alg" inconsistently says it is "an ASCII character" and "ASCII >> numbers" where perhaps it should say "an ASCII encoded one or two digit >> non-negative integer" or something. >=20 > Tweaked to remove a bit of repetition. >=20 >> - For "origin" perhaps the example should note that it would be >> prefixed by "28:" in the TBS blob. >=20 > That's the len all right, but that's just a per the abnf. I don't > think saying so would make it easier to code. >=20 >> - Delete one of the two sequential occurrences of "reduce the amount >> of". >=20 > Did that. >=20 >>=20 >> Page 10, Section 5: >> I suggest rewording this sentence: >> OLD >> This section also >> covers the actions that give HOBA similar user features as today's >> passwords have. >> NEW >> This section also >> covers the actions that give HOBA user features similar to today's >> passwords. >=20 > Almost >=20 >>=20 >> Page 16, Section 6.4: duplicated word "response". >=20 > Sigh, why do I keep doing that:-) >=20 >>=20 >> Page 18, Section 8.2: Is it a good idea to mention a particular >> on-line service name here? >=20 > I think its fair. >=20 >>=20 >> Page 19, IANA Considerations: It seems from >> draft-leiba-coton-iana-5226bis that IANA would prefer IANA >> Considerations to be written in the past tense as if the actions had >> already been accomplished, presumably to minimize IANA re-writing >> effort. Thus, I suggest that consideration be given to changing the >> initial part, between the Section 9 heading and the Section 9.1 >> heading, to the following and making similar changes in the remainder >> of the IANA Considerations Section: >>=20 >> IANA has created the registries and made the registration specified >> below, placing the new registries in a new "HTTP Origin-Bound >> Authentication (HOBA) Parameters" category. >=20 > I'd rather not go there. I've also seen the opposite request > made so would prefer to not be involved in such bureaucratic > battles:-) >=20 >>=20 >> Page 20, Section 9.3: A better way to note the restriction on >> potential values of Algorithm Name would be to add a third entry to >> the registry something like the following (there should also be a >> third Reference column): >>=20 >> 2-99 Unassigned [this document] >=20 > I'm not convinced that's better tbh and as-is its fine so no > change there. >=20 >>=20 >> Page 20, Section 9.4: Suggest the "Meaning" for 2 be "an unformatted >> UTF8 string". There should probably be a Reference column. "a small >> positive integer" is undefined. >=20 > Oh come on. Small positive integer utterly clear as is unformatted > string in this context. UTF8 isn't needed here as this is not meant > to be seen by a user. >=20 >>=20 >> Page 20, Section 9.5: Seems like this should say "UTF8 string" and I'm >> not sure it needs "at the user's/UA's whim". There should also be a >> "[this document]" entry in a Reference column. >=20 > I added UTF8 since this could be presented to a user. (Good catch > that.) I didn't make the other changes. >=20 >>=20 >> Maybe there should be ABNF for "kid" and "did" somewhere. Since "kid" >> and "did" are ordinary English words, suggest globally replacing them >> with "KID" and "DID" respectively. >=20 > No thanks - it's clear enough and upper case wouldn't make it better > I think. >=20 >>=20 >> Page 24, Appendix A >> This is a nice appendix but there is no reference to it anywhere in the >> body of the draft. Suggest adding such a reference to the >> Introduction. >=20 > I think we had it earlier and were asked to take it out. And > I think that's fine as-is. >=20 > Thanks for the good catches. >=20 > I've a working copy of a -09 at [1], with the diff vs. -08 > at [2]. I'll wait for Kathleen to say if she wants that posted > now or not, as almost all the changes are nit-fixes. >=20 > Cheers, > S. >=20 > [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-09.txt > [2] > https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-httpauth-hoba-08.txt&url2= =3Dhttps://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-09.txt >=20 >>=20 >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >=20 From nobody Tue Dec 30 11:48:31 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9248B1A1B44; Tue, 30 Dec 2014 11:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fh7dvlPqUjVJ; Tue, 30 Dec 2014 11:48:24 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E0D1A1B37; Tue, 30 Dec 2014 11:48:24 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ms9so12977315lab.10; Tue, 30 Dec 2014 11:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/uOaUyuYr8Slay8z+8vm0XBCu1Nt6ZOoYRY1F3BS8qk=; b=JGlH1vdZbhpcaSNuNKCWV4BakTAnedBZ1Jn4hn7awRmeUMjDb7eiX3kq0/mgqm9P+J /tc5gGzOX5EWlNHWweKgZWGXoDtTkRXRXQQX7WL/Tp8H55D8IgBWOZu4WnSS4a8b0dtL zsC5ofWTY1wEf/o+GhVaMHgSfbQf17SSsKRKsdmjIOYiLFld91UJyCS0UBT5bnNbnoLS L1XE2n/L4rlSZhItwd+xQ+Gy0IssaJIAehr76TBfVjAUyZ9YiztwtnglqgLvP40Ql98+ stnQjAgg+dTF/WnLVZShEk+xgBLEkhliyoo2KZ3Oo5Awire5dzx5HgGIA0PuT4DF+Amg K6jQ== MIME-Version: 1.0 X-Received: by 10.112.12.65 with SMTP id w1mr63290708lbb.68.1419968902631; Tue, 30 Dec 2014 11:48:22 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Tue, 30 Dec 2014 11:48:22 -0800 (PST) In-Reply-To: <54A2E649.9060705@cs.tcd.ie> References: <54A2E649.9060705@cs.tcd.ie> Date: Tue, 30 Dec 2014 14:48:22 -0500 X-Google-Sender-Auth: OX_LzL9K6tPFqoL1RNnXZUxzDcM Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/D9hQ6hUgBTmzkfw-8mUfPbmUEqo Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 19:48:25 -0000 On just a couple of points... >> Page 6/7/13, Figure 1/2/3: I'm not sure that something that is >> entirely textural is best called a "Figure". But in any case, since >> the text is, or at least has, lines that are flush left, it looks like >> part of the preceding text and there isn't a clear demarcation of the >> start. I recommend that the body of the Figures be indented 3 or 4 >> spaces. > > I'd prefer let the RFC editor fix those if needed. I think that if we think a change in the formatting would make things clearer, we should do that ourselves, and not defer it to the RFC Editor. *We* should be happy with the document before we send it over. >> Page 19, IANA Considerations: It seems from >> draft-leiba-coton-iana-5226bis that IANA would prefer IANA >> Considerations to be written in the past tense as if the actions had >> already been accomplished, presumably to minimize IANA re-writing >> effort. Thus, I suggest that consideration be given to changing the >> initial part, between the Section 9 heading and the Section 9.1 >> heading, to the following and making similar changes in the remainder >> of the IANA Considerations Section: I'm with Stephen here: please leave this alone. At this point, the document is making a request, and that's a fine way to put it. >> Page 20, Section 9.4: Suggest the "Meaning" for 2 be "an unformatted >> UTF8 string". There should probably be a Reference column. "a small >> positive integer" is undefined. > > Oh come on. Small positive integer utterly clear as is unformatted > string in this context. UTF8 isn't needed here as this is not meant > to be seen by a user. With this and all other strings, the question isn't whether users are going to see it or not, but how implementors are supposed to know what a "string" is and how to create it. If it's an arbitrary sequence of bytes, then it should say that, rather than "string". If it's really a string and is meant to represent characters in some encoding system, then it needs to say either what encoding system that is (UTF-8, US-ASCII, or whatever) or that it doesn't matter and that any encoding can be used. The latter only works if the string is never consumed by an entity other than the one that created it. Barry From nobody Tue Dec 30 13:46:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FABA1A1BB5; Tue, 30 Dec 2014 13:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gj3L8KdYPW1t; Tue, 30 Dec 2014 13:46:01 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656FA1A8777; Tue, 30 Dec 2014 13:46:01 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id z11so12566696lbi.24; Tue, 30 Dec 2014 13:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ATvBwkJZpSw19PU/5uvlOYlKSqfLnLMIcOyweCrsEx8=; b=mW1z4p9bp9mH389bYx9KMfDeJ6n3YOc+xH7yBv1D7684Gb/HS52tjdX9tMwUcDAFlA xJeUgyfM+f5vd6abrEid1d6CICVFZzD3+Eu75Qskd2qkfzMqVUt0eZsRN27P3MDUI98U xjMhqpFrbxbBO6W96puCPcTCbSMXoiki1P35JEGQSUhDvcybLlWMbFkNEaA8g7gCV6cc x6MCPeqvP0OSrqdRyo+YzzVBNEddKlHDWF65RrQd2x+5UIBYmDpFJySdxc1znBtoTwHA 4kFuIBshlBU61QJOouNsUoqUfdynUN+ArFqGgDmpJSDMqQTnWaQ8cpDEAz9CpjNIaqIY +NXA== MIME-Version: 1.0 X-Received: by 10.112.125.202 with SMTP id ms10mr26285122lbb.33.1419975959590; Tue, 30 Dec 2014 13:45:59 -0800 (PST) Received: by 10.112.49.52 with HTTP; Tue, 30 Dec 2014 13:45:59 -0800 (PST) In-Reply-To: References: <54A2E649.9060705@cs.tcd.ie> Date: Tue, 30 Dec 2014 16:45:59 -0500 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Rt4V2VXJaODWU_KqrZbFXNZB0W4 Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, "secdir@ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 21:46:06 -0000 Hi Stephen, On Tue, Dec 30, 2014 at 2:48 PM, Barry Leiba wrote: > On just a couple of points... > >>> Page 6/7/13, Figure 1/2/3: I'm not sure that something that is >>> entirely textural is best called a "Figure". But in any case, since >>> the text is, or at least has, lines that are flush left, it looks like >>> part of the preceding text and there isn't a clear demarcation of the >>> start. I recommend that the body of the Figures be indented 3 or 4 >>> spaces. >> >> I'd prefer let the RFC editor fix those if needed. > > I think that if we think a change in the formatting would make things > clearer, we should do that ourselves, and not defer it to the RFC > Editor. *We* should be happy with the document before we send it > over. I agree with Barry here, especially since you are providing an -09 soon. > >>> Page 19, IANA Considerations: It seems from >>> draft-leiba-coton-iana-5226bis that IANA would prefer IANA >>> Considerations to be written in the past tense as if the actions had >>> already been accomplished, presumably to minimize IANA re-writing >>> effort. Thus, I suggest that consideration be given to changing the >>> initial part, between the Section 9 heading and the Section 9.1 >>> heading, to the following and making similar changes in the remainder >>> of the IANA Considerations Section: > > I'm with Stephen here: please leave this alone. At this point, the > document is making a request, and that's a fine way to put it. I'm fine with leaving this as well. > >>> Page 20, Section 9.4: Suggest the "Meaning" for 2 be "an unformatted >>> UTF8 string". There should probably be a Reference column. "a small >>> positive integer" is undefined. >> >> Oh come on. Small positive integer utterly clear as is unformatted >> string in this context. UTF8 isn't needed here as this is not meant >> to be seen by a user. > > With this and all other strings, the question isn't whether users are > going to see it or not, but how implementors are supposed to know what > a "string" is and how to create it. If it's an arbitrary sequence of > bytes, then it should say that, rather than "string". If it's really > a string and is meant to represent characters in some encoding system, > then it needs to say either what encoding system that is (UTF-8, > US-ASCII, or whatever) or that it doesn't matter and that any encoding > can be used. The latter only works if the string is never consumed by > an entity other than the one that created it. Thanks Donald & Barry. Best regards, Kathleen > > Barry > -- Best regards, Kathleen From nobody Tue Dec 30 14:09:12 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDF01A8777; Tue, 30 Dec 2014 14:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VL4lPbW4ZFRA; Tue, 30 Dec 2014 14:09:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB051A8776; Tue, 30 Dec 2014 14:09:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 02F09BEC4; Tue, 30 Dec 2014 22:09:04 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCd-9Okupa7i; Tue, 30 Dec 2014 22:09:02 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.41.60.190]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 89E5ABEC3; Tue, 30 Dec 2014 22:09:02 +0000 (GMT) Message-ID: <54A3227E.7000209@cs.tcd.ie> Date: Tue, 30 Dec 2014 22:09:02 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Barry Leiba References: <54A2E649.9060705@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Ws4DSFixpYOSN9Ou6W-oB1EyTio Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 22:09:09 -0000 Hiya, On 30/12/14 19:48, Barry Leiba wrote: > On just a couple of points... > >>> Page 6/7/13, Figure 1/2/3: I'm not sure that something that is >>> entirely textural is best called a "Figure". But in any case, since >>> the text is, or at least has, lines that are flush left, it looks like >>> part of the preceding text and there isn't a clear demarcation of the >>> start. I recommend that the body of the Figures be indented 3 or 4 >>> spaces. >> >> I'd prefer let the RFC editor fix those if needed. > > I think that if we think a change in the formatting would make things > clearer, we should do that ourselves, and not defer it to the RFC > Editor. *We* should be happy with the document before we send it > over. I figure this is such a minor change that we are actually happy, even if we might also like to nitpick ourselves unhappy from time to time;-) > >>> Page 19, IANA Considerations: It seems from >>> draft-leiba-coton-iana-5226bis that IANA would prefer IANA >>> Considerations to be written in the past tense as if the actions had >>> already been accomplished, presumably to minimize IANA re-writing >>> effort. Thus, I suggest that consideration be given to changing the >>> initial part, between the Section 9 heading and the Section 9.1 >>> heading, to the following and making similar changes in the remainder >>> of the IANA Considerations Section: > > I'm with Stephen here: please leave this alone. At this point, the > document is making a request, and that's a fine way to put it. > >>> Page 20, Section 9.4: Suggest the "Meaning" for 2 be "an unformatted >>> UTF8 string". There should probably be a Reference column. "a small >>> positive integer" is undefined. >> >> Oh come on. Small positive integer utterly clear as is unformatted >> string in this context. UTF8 isn't needed here as this is not meant >> to be seen by a user. > > With this and all other strings, the question isn't whether users are > going to see it or not, but how implementors are supposed to know what > a "string" is and how to create it. In these cases coders look @ the IANA registry to find the string in question. If IANA, and some expert, manage to muck up that badly then I suspect we have worse problems. I only agreed with the UTF8 addition in the did case as I could see that being presented to a user as a "you last logged in from a &^%SS device on Tuesday" so there's a chance that a non ASCII string might be worthwhile there. For a kid type (not kid, but a kid type) that's just not worth even these electrons, even if it appears to bear all the markings of a good i18n bunfight:-) Neither string is ever sent in the HOBA protocol itself. S. > If it's an arbitrary sequence of > bytes, then it should say that, rather than "string". If it's really > a string and is meant to represent characters in some encoding system, > then it needs to say either what encoding system that is (UTF-8, > US-ASCII, or whatever) or that it doesn't matter and that any encoding > can be used. The latter only works if the string is never consumed by > an entity other than the one that created it. > > Barry > From nobody Tue Dec 30 14:13:09 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314A01A877D; Tue, 30 Dec 2014 14:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYvrVwSTwkum; Tue, 30 Dec 2014 14:13:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9831A8777; Tue, 30 Dec 2014 14:13:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8FDF0BEC4; Tue, 30 Dec 2014 22:13:04 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph4RljVnaIyr; Tue, 30 Dec 2014 22:13:03 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.41.60.190]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5AB35BEC3; Tue, 30 Dec 2014 22:13:03 +0000 (GMT) Message-ID: <54A3236F.7090005@cs.tcd.ie> Date: Tue, 30 Dec 2014 22:13:03 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Kathleen Moriarty , Barry Leiba References: <54A2E649.9060705@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/_01Xu9TnmaPH7oNT81xsy-hx41w Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 22:13:07 -0000 On 30/12/14 21:45, Kathleen Moriarty wrote: >> > I think that if we think a change in the formatting would make things >> > clearer, we should do that ourselves, and not defer it to the RFC >> > Editor. *We* should be happy with the document before we send it >> > over. > I agree with Barry here, especially since you are providing an -09 soon. > It would not make things clearer IMO. It would shuffle the characters to the right, and in a few cases off the rhs of the text area and thereby be an editorial pain that is purely worthless. Are we really saying that the figures in question (which are anbf) are really hard to distinguish from the other text? If you tell me they really really are then I'll move it to the right but whilst also grinding my teeth at the crapology that we force authors to endure at process-end and wishing that the IESG and others were wiser about that. (Myself included from time to time no doubt;-) S. From nobody Tue Dec 30 14:32:19 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBA71A8859; Tue, 30 Dec 2014 14:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkbvv9rv00S5; Tue, 30 Dec 2014 14:32:17 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE091A1A34; Tue, 30 Dec 2014 14:32:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D3059BEC4; Tue, 30 Dec 2014 22:32:15 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6nNzZheNhAl; Tue, 30 Dec 2014 22:32:14 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.41.60.190]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BCA7BBEC3; Tue, 30 Dec 2014 22:32:14 +0000 (GMT) Message-ID: <54A327EE.7080306@cs.tcd.ie> Date: Tue, 30 Dec 2014 22:32:14 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Kathleen Moriarty , Barry Leiba References: <54A2E649.9060705@cs.tcd.ie> <54A3236F.7090005@cs.tcd.ie> In-Reply-To: <54A3236F.7090005@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2c6T_hAP1q_AJxO-QJL4ymsLags Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 22:32:18 -0000 Sadly, it was probably quicker to take the pointless pain (of arm wrestling xml2rfc's ideas of abnf and alignment) rather than argue more against this pointless change. So I moved the figure-text precisely 3 characters to the right. (It was not hard though, but only because I got lucky in discovering that a line of whitespace before the text worked somehow.) Anyway -09 is posted with that pointless change. But also with the other all very worthwhile changes Donald suggested. S. PS: Yes, I really do think we ought not foist this kind of nonsense on authors. From nobody Tue Dec 30 16:49:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB801A885B; Tue, 30 Dec 2014 16:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qcPvPZrxNQx; Tue, 30 Dec 2014 16:49:09 -0800 (PST) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC4D1A00CF; Tue, 30 Dec 2014 16:49:09 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id k15so8403316qaq.21; Tue, 30 Dec 2014 16:49:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EVVYlj8ELife/Ao2gqqHxwqjwyzR+p8ARE7tO+csiS0=; b=TWwQaG1Z0td2hxihpmUd2oY4aq3G/0hrPTxuWNM/usumtIet6K8D8aPyvs766nvCbr 6KgXKqEZsTQoN9K1mBkK9fTaua6YGKEw9Xi5dmzfgj8Soui3eU6g08RGwRVXjCSDYwtK H2zbR1kXkpLMga+XKEtcC0e7lNmanPeFes60JdlUFTC52I/i1eg8m2KcBgd79DVQNyNQ xnZWydS5/gzD1Ktp469K2lAyuG5mwsR5XJRiYkIGIgC565rRbWyVX6m1O7kGl+7Qr4Bs 9c4s7KZIforaE88D+uS4Wdaw8IAVzl1WZRkCRoS13JOgPHFjwj/ilmgUCt+fJPKo5F2E j4IQ== X-Received: by 10.224.20.1 with SMTP id d1mr26259430qab.58.1419986948438; Tue, 30 Dec 2014 16:49:08 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id f77sm37197200qgd.49.2014.12.30.16.49.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Dec 2014 16:49:06 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <54A327EE.7080306@cs.tcd.ie> Date: Tue, 30 Dec 2014 19:49:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <958418FB-C1CC-4A22-B568-0EED8E129998@gmail.com> References: <54A2E649.9060705@cs.tcd.ie> <54A3236F.7090005@cs.tcd.ie> <54A327EE.7080306@cs.tcd.ie> To: Stephen Farrell Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/z-2XDSzu8ZC8gvZ0IGNcqmbr3Zs Cc: "draft-ietf-httpauth-hoba.all@tools.ietf.org" , Barry Leiba , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 00:49:10 -0000 Thanks, Stephen. I guess you caught the gap of time when I was out at dinne= r. =20 Kathleen=20 Sent from my iPhone > On Dec 30, 2014, at 5:32 PM, Stephen Farrell w= rote: >=20 >=20 > Sadly, it was probably quicker to take the pointless pain (of > arm wrestling xml2rfc's ideas of abnf and alignment) rather > than argue more against this pointless change. So I moved the > figure-text precisely 3 characters to the right. (It was not > hard though, but only because I got lucky in discovering that > a line of whitespace before the text worked somehow.) >=20 > Anyway -09 is posted with that pointless change. But also > with the other all very worthwhile changes Donald suggested. >=20 > S. >=20 > PS: Yes, I really do think we ought not foist this kind of > nonsense on authors.