From nobody Mon Jul 2 17:29:49 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02F9130EBF for ; Mon, 2 Jul 2018 17:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fYvjlb0_l_6 for ; Mon, 2 Jul 2018 17:29:38 -0700 (PDT) Received: from smtp114.iad3a.emailsrvr.com (smtp114.iad3a.emailsrvr.com [173.203.187.114]) (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 8D1EE130E99 for ; Mon, 2 Jul 2018 17:29:38 -0700 (PDT) Received: from smtp39.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp39.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C67865C9B; Mon, 2 Jul 2018 20:29:33 -0400 (EDT) Received: from app51.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp39.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B76795C8B; Mon, 2 Jul 2018 20:29:33 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app51.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Mon, 02 Jul 2018 20:29:33 -0400 Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app51.wa-webapps.iad3a (Postfix) with ESMTP id A683B400A5; Mon, 2 Jul 2018 20:29:33 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Mon, 2 Jul 2018 17:29:33 -0700 (PDT) X-Auth-ID: scott@hyperthought.com Date: Mon, 2 Jul 2018 17:29:33 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-acme-acme.all@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1530577773.679428211@apps.rackspace.com> X-Mailer: webmail/15.2.1-RC Archived-At: Subject: [secdir] secdir review of draft-ietf-acme-acme-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 00:29: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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments.=0A=0AThe summary of the review is ready.=0A=0AT= his document describes an online certificate enrollment protocol that autom= ates the certificate issuance and verification process. The document curren= tly focuses on the web server use case where the identifier is a domain nam= e. The security considerations section is well-written and detailed. I don'= t see any issues with this document.=0A From nobody Tue Jul 3 11:32:49 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBA4130DC0; Tue, 3 Jul 2018 11:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gR0_z4zF4ONQ; Tue, 3 Jul 2018 11:32:37 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 476CA130DC7; Tue, 3 Jul 2018 11:32:37 -0700 (PDT) Received: from trixy.bergandi.net ([76.93.146.89]) by wwwlocal.goatley.com (PMDF V6.7-x02 #1001) with ESMTP id <0PBA00L92ZIC2G@wwwlocal.goatley.com>; Tue, 03 Jul 2018 13:32:37 -0500 (CDT) Received: from thinny.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PBA0037TZI8QX@trixy.bergandi.net>; Tue, 03 Jul 2018 11:32:33 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO thinny.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Tue, 03 Jul 2018 11:32:33 -0700 Date: Tue, 03 Jul 2018 11:32:35 -0700 From: Daniel Harkins To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-netconf-nmda-restconf.all@ietf.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Vq2ZudmecUZTRRyovh5VHw)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO thinny.local) X-PMAS-Software: PreciseMail V3.3 [180702a] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: [secdir] review of draft-ietf-netconf-nmda-restconf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 18:32:40 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Vq2ZudmecUZTRRyovh5VHw) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT   Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is "Ready with nits". This draft defines two new capability identifier URNs for use in the RESTCONF protocol and also some new behavioral requirements on servers implementing it. My nit is on that last bit. In sections 3.2.1 and 3.2.2 present the new query parameters and say that they are "optional to support" and then go on saying what behavior is needed if it is supported. I think those need to be changed to be RFC 2119 words, either SHOULD or MAY depending on the reasons that might exist for not implementing them (basically conform to what the words mean in RFC 2119). Other than that, the draft is pretty simple and straightforward. The security considerations are basically a punt but given the nature of this draft that's probably fine. regards, Dan. --Boundary_(ID_Vq2ZudmecUZTRRyovh5VHw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT  
  Hello,

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

  The summary of the review is "Ready with nits".

  This draft defines two new capability identifier URNs for use in
the RESTCONF protocol and also some new behavioral requirements on
servers implementing it. My nit is on that last bit. In sections
3.2.1 and 3.2.2 present the new query parameters and say that they
are "optional to support" and then go on saying what behavior is
needed if it is supported. I think those need to be changed to be
RFC 2119 words, either SHOULD or MAY depending on the reasons that
might exist for not implementing them (basically conform to what
the words mean in RFC 2119). 

  Other than that, the draft is pretty simple and straightforward.
The security considerations are basically a punt but given the
nature of this draft that's probably fine.

  regards,

  Dan.
--Boundary_(ID_Vq2ZudmecUZTRRyovh5VHw)-- From nobody Wed Jul 4 05:41:45 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCA0130E89; Wed, 4 Jul 2018 05:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWG9BykyR1na; Wed, 4 Jul 2018 05:41:31 -0700 (PDT) Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id 1537F130E5C; Wed, 4 Jul 2018 05:41:31 -0700 (PDT) Received: by anna.localdomain (Postfix, from userid 501) id AAD9022DC540; Wed, 4 Jul 2018 14:41:28 +0200 (CEST) Date: Wed, 4 Jul 2018 14:41:28 +0200 From: Juergen Schoenwaelder To: Daniel Harkins Cc: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-netconf-nmda-restconf.all@ietf.org Message-ID: <20180704124128.qpr7tunjw5quiex6@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Daniel Harkins , "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-netconf-nmda-restconf.all@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180622 Archived-At: Subject: Re: [secdir] review of draft-ietf-netconf-nmda-restconf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 12:41:37 -0000 On Tue, Jul 03, 2018 at 11:32:35AM -0700, Daniel Harkins wrote: > > Hello, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is "Ready with nits". > > This draft defines two new capability identifier URNs for use in > the RESTCONF protocol and also some new behavioral requirements on > servers implementing it. My nit is on that last bit. In sections > 3.2.1 and 3.2.2 present the new query parameters and say that they > are "optional to support" and then go on saying what behavior is > needed if it is supported. I think those need to be changed to be > RFC 2119 words, either SHOULD or MAY depending on the reasons that > might exist for not implementing them (basically conform to what > the words mean in RFC 2119). > I am not sure where exactly we are asked to use SHOULD and MAY and why that would be necessary. Note that we follow the wordings in RFC 8040 (search for optional), which this document updates. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jul 4 11:08:28 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55E113109A; Wed, 4 Jul 2018 11:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNXg1oqXu3jQ; Wed, 4 Jul 2018 11:08:13 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 625E1131073; Wed, 4 Jul 2018 11:08:13 -0700 (PDT) Received: from trixy.bergandi.net ([76.93.146.89]) by wwwlocal.goatley.com (PMDF V6.7-x02 #1001) with ESMTP id <0PBC00138T1ONK@wwwlocal.goatley.com>; Wed, 04 Jul 2018 13:08:12 -0500 (CDT) Received: from thinny.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PBC00M92T1FBU@trixy.bergandi.net>; Wed, 04 Jul 2018 11:08:04 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO thinny.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Wed, 04 Jul 2018 11:08:04 -0700 Date: Wed, 04 Jul 2018 11:08:10 -0700 From: Daniel Harkins In-reply-to: <20180704124128.qpr7tunjw5quiex6@anna.jacobs.jacobs-university.de> To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-netconf-nmda-restconf.all@ietf.org Message-id: <9b2f8091-9ead-e188-ee34-1acfead2dcd2@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_EZOpY0P203gMlU7RSpGVtw)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO thinny.local) References: <20180704124128.qpr7tunjw5quiex6@anna.jacobs.jacobs-university.de> X-PMAS-Software: PreciseMail V3.3 [180703] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [secdir] review of draft-ietf-netconf-nmda-restconf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 18:08:27 -0000 This is a multi-part message in MIME format. --Boundary_(ID_EZOpY0P203gMlU7RSpGVtw) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT On 7/4/18 5:41 AM, Juergen Schoenwaelder wrote: > On Tue, Jul 03, 2018 at 11:32:35AM -0700, Daniel Harkins wrote: >>   Hello, >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> The summary of the review is "Ready with nits". >> >> This draft defines two new capability identifier URNs for use in >> the RESTCONF protocol and also some new behavioral requirements on >> servers implementing it. My nit is on that last bit. In sections >> 3.2.1 and 3.2.2 present the new query parameters and say that they >> are "optional to support" and then go on saying what behavior is >> needed if it is supported. I think those need to be changed to be >> RFC 2119 words, either SHOULD or MAY depending on the reasons that >> might exist for not implementing them (basically conform to what >> the words mean in RFC 2119). >> > I am not sure where exactly we are asked to use SHOULD and MAY and why > that would be necessary. Note that we follow the wordings in RFC 8040 > (search for optional), which this document updates.   I'm suggesting SHOULD _or_ MAY and I thought where would be obvious. It is the places that say "optional to support" in 3.2.1. and 3.2.2 as I indicated. For example, 3.2.1 says, The "with-defaults" query parameter ([RFC8040], Section 4.8.9 ) is optional to support when interacting with {+restconf}/ds/ietf- datastores:operational. 3.2.2 has similar text. As to why, it is for consistency and clarity in expressing what you want.   Dan. --Boundary_(ID_EZOpY0P203gMlU7RSpGVtw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT
On 7/4/18 5:41 AM, Juergen Schoenwaelder wrote:
On Tue, Jul 03, 2018 at 11:32:35AM -0700, Daniel Harkins wrote:

  Hello,

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

  The summary of the review is "Ready with nits".

  This draft defines two new capability identifier URNs for use in
the RESTCONF protocol and also some new behavioral requirements on
servers implementing it. My nit is on that last bit. In sections
3.2.1 and 3.2.2 present the new query parameters and say that they
are "optional to support" and then go on saying what behavior is
needed if it is supported. I think those need to be changed to be
RFC 2119 words, either SHOULD or MAY depending on the reasons that
might exist for not implementing them (basically conform to what
the words mean in RFC 2119).


I am not sure where exactly we are asked to use SHOULD and MAY and why
that would be necessary. Note that we follow the wordings in RFC 8040
(search for optional), which this document updates.

  I'm suggesting SHOULD _or_ MAY and I thought where would be obvious.
It is the places that say "optional to support" in 3.2.1. and 3.2.2 as
I indicated. For example, 3.2.1 says,
   The "with-defaults" query parameter ([RFC8040], Section 4.8.9) is
   optional to support when interacting with {+restconf}/ds/ietf-
   datastores:operational.
3.2.2 has similar text. As to why, it is for consistency and clarity in
expressing what you want.

  Dan.

  
 


--Boundary_(ID_EZOpY0P203gMlU7RSpGVtw)-- From nobody Wed Jul 4 11:34:48 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3757130E30; Wed, 4 Jul 2018 11:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e62NeTCETLSy; Wed, 4 Jul 2018 11:34:39 -0700 (PDT) Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id 5087B130E01; Wed, 4 Jul 2018 11:34:38 -0700 (PDT) Received: by anna.localdomain (Postfix, from userid 501) id 0D04E22DCC4F; Wed, 4 Jul 2018 20:34:36 +0200 (CEST) Date: Wed, 4 Jul 2018 20:34:36 +0200 From: Juergen Schoenwaelder To: Daniel Harkins Cc: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-netconf-nmda-restconf.all@ietf.org Message-ID: <20180704183436.zjzwz4vowqi5phz7@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Daniel Harkins , "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-netconf-nmda-restconf.all@ietf.org References: <20180704124128.qpr7tunjw5quiex6@anna.jacobs.jacobs-university.de> <9b2f8091-9ead-e188-ee34-1acfead2dcd2@lounge.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9b2f8091-9ead-e188-ee34-1acfead2dcd2@lounge.org> User-Agent: NeoMutt/20180622 Archived-At: Subject: Re: [secdir] review of draft-ietf-netconf-nmda-restconf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 18:34:42 -0000 On Wed, Jul 04, 2018 at 11:08:10AM -0700, Daniel Harkins wrote: > > > I'm suggesting SHOULD _or_ MAY and I thought where would be obvious. > It is the places that say "optional to support" in 3.2.1. and 3.2.2 as > I indicated. For example, 3.2.1 says, > > The "with-defaults" query parameter ([RFC8040], Section4.8.9 ) is > optional to support when interacting with {+restconf}/ds/ietf- > datastores:operational. > > 3.2.2 has similar text. As to why, it is for consistency and clarity in > expressing what you want. > What is unclear about 'optional to support'? RFC 8040 uses similar language and I do not recall that anyone had a problem with this so far. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jul 4 12:46:23 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC5F13108F; Wed, 4 Jul 2018 12:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKqHiwU9hHWl; Wed, 4 Jul 2018 12:46:14 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 9F86013108C; Wed, 4 Jul 2018 12:46:14 -0700 (PDT) Received: from trixy.bergandi.net ([76.93.146.89]) by wwwlocal.goatley.com (PMDF V6.7-x02 #1001) with ESMTP id <0PBC0050FXL11V@wwwlocal.goatley.com>; Wed, 04 Jul 2018 14:46:13 -0500 (CDT) Received: from thinny.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PBC0075XXKR7M@trixy.bergandi.net>; Wed, 04 Jul 2018 12:46:04 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO thinny.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Wed, 04 Jul 2018 12:46:04 -0700 Date: Wed, 04 Jul 2018 12:46:10 -0700 From: Daniel Harkins In-reply-to: <20180704183436.zjzwz4vowqi5phz7@anna.jacobs.jacobs-university.de> To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-netconf-nmda-restconf.all@ietf.org Message-id: <14e7ae2d-90ae-32c5-c814-a2d31e9f1a4e@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO thinny.local) References: <20180704124128.qpr7tunjw5quiex6@anna.jacobs.jacobs-university.de> <9b2f8091-9ead-e188-ee34-1acfead2dcd2@lounge.org> <20180704183436.zjzwz4vowqi5phz7@anna.jacobs.jacobs-university.de> X-PMAS-Software: PreciseMail V3.3 [180703] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [secdir] review of draft-ietf-netconf-nmda-restconf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 19:46:17 -0000 On 7/4/18 11:34 AM, Juergen Schoenwaelder wrote: > On Wed, Jul 04, 2018 at 11:08:10AM -0700, Daniel Harkins wrote: >> >>   I'm suggesting SHOULD _or_ MAY and I thought where would be obvious. >> It is the places that say "optional to support" in 3.2.1. and 3.2.2 as >> I indicated. For example, 3.2.1 says, >> >> The "with-defaults" query parameter ([RFC8040], Section 4.8.9 ) is >> optional to support when interacting with {+restconf}/ds/ietf- >> datastores:operational. >> >> 3.2.2 has similar text. As to why, it is for consistency and clarity in >> expressing what you want. >> > What is unclear about 'optional to support'? RFC 8040 uses similar > language and I do not recall that anyone had a problem with this so > far.   If you want to reject my comment then just reject my comment. It was made in the spirit of improving your draft which apparently you take issue with for some bizarre reason. If someone outside the RFC 8040 bubble you seem to be living in found the wording lacking in clarity then it would seem logical to infer that maybe others might too. Just a thought.   Dan. From nobody Thu Jul 5 06:14:46 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC59130DC2 for ; Thu, 5 Jul 2018 06:14:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <153079648519.11472.17703326492047317330.idtracker@ietfa.amsl.com> Date: Thu, 05 Jul 2018 06:14:45 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 13:14:46 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-07-05 Reviewer LC end Draft John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-09 Tobias Gondrom 2018-06-25 draft-ietf-6man-rfc6434-bis-08 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Dacheng Zhang 2018-06-19 draft-ietf-mpls-spring-entropy-label-11 For telechat 2018-08-02 Reviewer LC end Draft Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-11 Tina Tsou 2018-05-21 draft-ietf-v6ops-conditional-ras-05 Last calls: Reviewer LC end Draft Daniel Franke 2018-06-28 draft-ietf-netconf-rfc7895bis-06 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Phillip Hallam-Baker 2018-07-10 draft-ietf-codec-ambisonics-07 Christian Huitema 2018-07-09 draft-ietf-netconf-nmda-netconf-06 Leif Johansson 2018-07-10 draft-ietf-insipid-logme-marking-11 Barry Leiba 2018-07-30 draft-sahib-451-new-protocol-elements-01 Chris Lonvick 2018-07-13 draft-ietf-extra-imap-objectid-03 David Mandelberg None draft-ietf-netconf-zerotouch-22 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2018-04-24 draft-ietf-mmusic-sdp-simulcast-13 Taylor Yu 2018-06-19 draft-ietf-regext-rdap-object-tag-03 Early review requests: Reviewer Due Draft Donald Eastlake 2018-06-30 draft-ietf-mptcp-rfc6824bis-11 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Barry Leiba Chris Lonvick David Mandelberg Catherine Meadows Alexey Melnikov Daniel Migault Matthew Miller Adam Montville Kathleen Moriarty Russ Mundy From nobody Thu Jul 5 07:46:24 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9969130E7F; Thu, 5 Jul 2018 07:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ojCqtTALhCu; Thu, 5 Jul 2018 07:46:13 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 68FD4130E7B; Thu, 5 Jul 2018 07:46:12 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w65EhTD4012224; Thu, 5 Jul 2018 07:46:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=R7QkIXmwaYaqqA4Npa64pP3seZ0M0VvkZw9pVedAVWM=; b=niX3IDY1IV+JhtiBGNxcHzzTZjr3rIcYe3c4jNF8JAVLzNc4M2zI7p0NbTGf5OjcrqA9 ZqKlM94gjUs/ZzM2vn1/mYMnTjweEQI2/7wG0aMRwqeN9FYK6szV/QeaVX/cZgNUp8s4 UuXcU5yUVHtw1LP9V4BZ38HPd7e/Jg97jY5I1KWjbzqAXxJroMJ1G3XThupijAQM/DU5 M2VFHnuaLCGiY/KL4OHKpS+Ja0JWfLWWjUQUvuRELrgX5Ru8GbEhoYqviHryH/FdIthJ uMOCjUEirmPaPMHHsUMr+wefAt0sqy5rIXHAq8frf5HQ83maZS+j1DAEmWKJTy4tbpcS jA== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp0054.outbound.protection.outlook.com [216.32.181.54]) by mx0b-00273201.pphosted.com with ESMTP id 2k1j6g8e77-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Jul 2018 07:46:11 -0700 Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4615.namprd05.prod.outlook.com (52.135.233.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.7; Thu, 5 Jul 2018 14:46:09 +0000 Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc%4]) with mapi id 15.20.0930.016; Thu, 5 Jul 2018 14:46:09 +0000 From: Kent Watsen To: Daniel Harkins , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-netconf-nmda-restconf.all@ietf.org" Thread-Topic: review of draft-ietf-netconf-nmda-restconf-04 Thread-Index: AQHUEvw7xz8IkgWC60ughtUiyRctB6R/Aq4AgABbSACAAAdiAIAAE/8AgAD7cwA= Date: Thu, 5 Jul 2018 14:46:09 +0000 Message-ID: References: <20180704124128.qpr7tunjw5quiex6@anna.jacobs.jacobs-university.de> <9b2f8091-9ead-e188-ee34-1acfead2dcd2@lounge.org> <20180704183436.zjzwz4vowqi5phz7@anna.jacobs.jacobs-university.de> <14e7ae2d-90ae-32c5-c814-a2d31e9f1a4e@lounge.org> In-Reply-To: <14e7ae2d-90ae-32c5-c814-a2d31e9f1a4e@lounge.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4615; 7:Hea0jFsCXXvINYXuPxAWeQJgixe8TG8MMwUGkKABGE4U08ZEwlsdhfKswiwsNW7wn22E1fbX23Tee27g5u5f0fWW4p0yh2/yfFszJ/nxvSLWq7kBbCPhsONQiBecD6lvwvWMjrWAzBIZbuekbgmdgOcXoBA1en7HuA/mk9GvA+vDOSyBsnV0XrTB7H7iIGCjzjclYAHhVTW+fMskjwtR+ui59tAZoNmnPI54nI4tBEIV/QYz0sATklunHheKs29g x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 1f098925-088c-478a-1618-08d5e2860bb1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4615; x-ms-traffictypediagnostic: BYAPR05MB4615: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231280)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4615; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4615; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(136003)(366004)(39860400002)(199004)(189003)(51444003)(76094002)(102836004)(3846002)(6116002)(99286004)(7736002)(105586002)(106356001)(305945005)(316002)(58126008)(11346002)(476003)(229853002)(33656002)(2900100001)(53546011)(6506007)(110136005)(76176011)(68736007)(486006)(2616005)(26005)(6486002)(2906002)(36756003)(446003)(8936002)(14454004)(66066001)(5660300001)(478600001)(25786009)(256004)(86362001)(6246003)(2201001)(82746002)(93886005)(53936002)(8676002)(186003)(97736004)(83716003)(2501003)(6306002)(6436002)(81156014)(81166006)(5250100002)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4615; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: UQphDbFN7v9bHBcqDcmy/6Mjx+q+pVD61Vp87DMlSWOO+iM+9X+Xvy+pDT3k25Lt/zeoiRZLfFJvGFqZyLW+3L5ewmdS8fhiQ0kyJPsS1e930v+FIAfP1TdzKAlMULiySwF1P1CkGKGZgRpV+qpcUnplv1ifmb7MLCXvBZGXscBSZAGKApmicNFB3yi2yyEXfRJ6TRDRUdWtC8fW0pvNTNxQD5fMPFn7D90p/yUD8XEAaDqaSA9SIzcqlVKi3FcXbCw37t6pmk/3ViTuX25gU3SVUxKbNqHlzdskgkTf847iJnTeAazpwTu8QpkrhtIm3n0OQ2H19ELNW8ZElnsvS2oFd7Sa7dlGQq+2IyYDTs0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 1f098925-088c-478a-1618-08d5e2860bb1 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2018 14:46:09.0932 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4615 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-05_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807050169 Archived-At: Subject: Re: [secdir] review of draft-ietf-netconf-nmda-restconf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 14:46:16 -0000 SSB0aGluayB0aGF0IHRoZSBjdXJyZW50IHdvcmRpbmcgaXMgb2theSwgYnV0IEknbSBva2F5IHdp dGggY2hhbmdpbmcNCml0IHRvby4gSG93IGFib3V0IHRoaXM/DQoNCg0KT0xEOg0KICAgVGhlICJ3 aXRoLWRlZmF1bHRzIiBxdWVyeSBwYXJhbWV0ZXIgKFtSRkM4MDQwXSwgU2VjdGlvbiA0LjguOSkg aXMNCiAgIG9wdGlvbmFsIHRvIHN1cHBvcnQgd2hlbiBpbnRlcmFjdGluZyB3aXRoIHsrcmVzdGNv bmZ9L2RzL2lldGYtDQogICBkYXRhc3RvcmVzOm9wZXJhdGlvbmFsLiAgVGhlIGFzc29jaWF0ZWQg Y2FwYWJpbGl0eSB0byBpbmRpY2F0ZSBhDQogICBzZXJ2ZXIncyBzdXBwb3J0IGlzIGlkZW50aWZp ZWQgd2l0aCB0aGUgVVJJOg0KDQpORVc6DQogICBUaGUgIndpdGgtZGVmYXVsdHMiIHF1ZXJ5IHBh cmFtZXRlciAoW1JGQzgwNDBdLCBTZWN0aW9uIDQuOC45KSANCiAgIE1BWSBiZSBzdXBwb3J0ZWQg Zm9yIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUuICBTdXBwb3J0DQogICBmb3IgdGhl ICJ3aXRoLWRlZmF1bHRzIiBxdWVyeSBwYXJhbWV0ZXIgZm9yIHRoZSBvcGVyYXRpb25hbA0KICAg c3RhdGUgZGF0YXN0b3JlIGlzIGlkZW50aWZpZWQgd2l0aCB0aGUgVVJJOg0KDQoNCg0KT0xEOg0K ICAgVGhlICJ3aXRoLW9yaWdpbiIgcXVlcnkgcGFyYW1ldGVyIGlzIG9wdGlvbmFsIHRvIHN1cHBv cnQuICBJdCBpcw0KICAgaWRlbnRpZmllZCB3aXRoIHRoZSBVUkk6DQoNCk5FVzoNCiAgIFRoZSAi d2l0aC1vcmlnaW4iIHF1ZXJ5IHBhcmFtZXRlciBNQVkgYmUgc3VwcG9ydGVkLiAgU3VwcG9ydA0K ICAgZm9yIHRoZSAid2l0aC1vcmlnaW4iIHF1ZXJ5IHBhcmFtZXRlciBpcyBpZGVudGlmaWVkIHdp dGggdGhlDQogICBVUkk6DQoNCg0KDQpGV0lXLCBlbHNld2hlcmUgaW4gdGhlIGRyYWZ0IGlzIGFu b3RoZXIgIm9wdGlvbmFsIiB1c2FnZSB0aGF0IGNvdWxkDQpiZSBjaGFuZ2VkOg0KDQogT0xEOg0K ICAgQW4gTk1EQS1jb21wbGlhbnQgc2VydmVyIE1VU1QgaW1wbGVtZW50IHsrcmVzdGNvbmZ9L2Rz L2lldGYtDQogICBkYXRhc3RvcmVzOm9wZXJhdGlvbmFsLiAgT3RoZXIgZGF0YXN0b3JlIHJlc291 cmNlcyBhcmUgb3B0aW9uYWwgdG8NCiAgIGltcGxlbWVudC4NCg0KIE5FVzoNCiAgIEFuIE5NREEt Y29tcGxpYW50IHNlcnZlciBNVVNUIGltcGxlbWVudCB7K3Jlc3Rjb25mfS9kcy9pZXRmLQ0KICAg ZGF0YXN0b3JlczpvcGVyYXRpb25hbC4gIE90aGVyIGRhdGFzdG9yZSByZXNvdXJjZXMgTUFZIGJl DQogICBpbXBsZW1lbnRlZC4NCg0KDQoNCkNvbW1lbnRzPw0KDQpLZW50ICAvLyBjby1hdXRob3IN Cg0KDQoNCk9uIDcvNC8xOCAxMTozNCBBTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIHdyb3RlOg0K PiBPbiBXZWQsIEp1bCAwNCwgMjAxOCBhdCAxMTowODoxMEFNIC0wNzAwLCBEYW5pZWwgSGFya2lu cyB3cm90ZToNCj4+DQo+PiAgICBJJ20gc3VnZ2VzdGluZyBTSE9VTEQgX29yXyBNQVkgYW5kIEkg dGhvdWdodCB3aGVyZSB3b3VsZCBiZSBvYnZpb3VzLg0KPj4gSXQgaXMgdGhlIHBsYWNlcyB0aGF0 IHNheSAib3B0aW9uYWwgdG8gc3VwcG9ydCIgaW4gMy4yLjEuIGFuZCAzLjIuMiBhcw0KPj4gSSBp bmRpY2F0ZWQuIEZvciBleGFtcGxlLCAzLjIuMSBzYXlzLA0KPj4NCj4+ICAgICBUaGUgIndpdGgt ZGVmYXVsdHMiIHF1ZXJ5IHBhcmFtZXRlciAoW1JGQzgwNDBdLCBTZWN0aW9uIDQuOC45IDxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmll dGYub3JnX2h0bWxfcmZjODA0MC0yM3NlY3Rpb24tMkQ0LjguOSZkPUR3SURhUSZjPUhBa1l1aDYz cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09I N1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09ZkFwcVktTG5FZ2ptNE5iT2JOY3U1TDQ0akFaMlVZ SnowQ1dsNXE0VTBZRSZzPXI2NWtha3BnVjNPU2JZNmlJekJ5WE1tcXZWLTQ1Vm85d2tYWkhqaThq bGsmZT0+KSBpcw0KPj4gICAgIG9wdGlvbmFsIHRvIHN1cHBvcnQgd2hlbiBpbnRlcmFjdGluZyB3 aXRoIHsrcmVzdGNvbmZ9L2RzL2lldGYtDQo+PiAgICAgZGF0YXN0b3JlczpvcGVyYXRpb25hbC4N Cj4+DQo+PiAzLjIuMiBoYXMgc2ltaWxhciB0ZXh0LiBBcyB0byB3aHksIGl0IGlzIGZvciBjb25z aXN0ZW5jeSBhbmQgY2xhcml0eSBpbg0KPj4gZXhwcmVzc2luZyB3aGF0IHlvdSB3YW50Lg0KPj4N Cj4gV2hhdCBpcyB1bmNsZWFyIGFib3V0ICdvcHRpb25hbCB0byBzdXBwb3J0Jz8gUkZDIDgwNDAg dXNlcyBzaW1pbGFyDQo+IGxhbmd1YWdlIGFuZCBJIGRvIG5vdCByZWNhbGwgdGhhdCBhbnlvbmUg aGFkIGEgcHJvYmxlbSB3aXRoIHRoaXMgc28NCj4gZmFyLg0KDQogICBJZiB5b3Ugd2FudCB0byBy ZWplY3QgbXkgY29tbWVudCB0aGVuIGp1c3QgcmVqZWN0IG15IGNvbW1lbnQuIEl0IHdhcyBtYWRl DQppbiB0aGUgc3Bpcml0IG9mIGltcHJvdmluZyB5b3VyIGRyYWZ0IHdoaWNoIGFwcGFyZW50bHkg eW91IHRha2UgaXNzdWUgd2l0aA0KZm9yIHNvbWUgYml6YXJyZSByZWFzb24uIElmIHNvbWVvbmUg b3V0c2lkZSB0aGUgUkZDIDgwNDAgYnViYmxlIHlvdSBzZWVtIA0KdG8gYmUNCmxpdmluZyBpbiBm b3VuZCB0aGUgd29yZGluZyBsYWNraW5nIGluIGNsYXJpdHkgdGhlbiBpdCB3b3VsZCBzZWVtIGxv Z2ljYWwgdG8NCmluZmVyIHRoYXQgbWF5YmUgb3RoZXJzIG1pZ2h0IHRvby4gSnVzdCBhIHRob3Vn aHQuDQoNCiAgIERhbi4NCg0KDQoNCg0K From nobody Fri Jul 6 05:52:29 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAF1130F0F; Fri, 6 Jul 2018 01:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1530866635; bh=obrxWJWB6N1SAha4llzl2WXl20u8jho35c0/aVvHMpU=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=mIQrj895vj7/HyLQcEOzNn2ve0P1tf1k+pTH8JSIGBIVTdy6IS/HZttLXDToYCv5r sljYoz+/z2q/jy9cUgurTLBSn45cFaxE/wpxW7z7Dkyobt8mhtcCKd0kh4jDoA+YCw +y/DfqybdJdgk5QjqkRisS0fq50G6Yx2b2KzZOZY= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Jul 6 01:43:54 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA11130EAE; Fri, 6 Jul 2018 01:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1530866634; bh=obrxWJWB6N1SAha4llzl2WXl20u8jho35c0/aVvHMpU=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=oO4Mbt9YjVdjnMpI3AUQ5tzQllX/LyX+8HXir1/cDTCA9bl15T0zhwAHrdpOx+/aI JfI0D/rFb2fAQdBl4kBCIfb9iI3hUeHutVp0z5/LenQRYWJ/LkLaYv36S1RPBctNR8 xaKUFPLthLm9UvjlQQocndgVEh+PHPMD3OzeiKuc= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85B8130EAE for ; Fri, 6 Jul 2018 01:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt_SLyB0oRGv for ; Fri, 6 Jul 2018 01:43:50 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACA5130E8D for ; Fri, 6 Jul 2018 01:43:49 -0700 (PDT) Received: from [42.101.5.134] (helo=XueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1fbMLE-0007vl-5p for new-work@ietf.org; Fri, 06 Jul 2018 08:43:48 +0000 To: new-work@ietf.org From: Xueyuan Message-ID: <6317c937-4d58-55eb-43c8-22e01c17fb35@w3.org> Date: Fri, 6 Jul 2018 16:43:43 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.26 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 06 Jul 2018 05:52:28 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web Performance Working Group (until 2018-08-03) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 08:43:59 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgV2ViIFBl cmZvcm1hbmNlIFdvcmtpbmcgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcvMjAxOC8wNy93 ZWJwZXJmLWNoYXJ0ZXIKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhhdCB0aGUgY29tbXVuaXR5IGlz IGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRyYWZ0IGNoYXJ0ZXIgaXMgcHVi bGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJldmlldyBwZXJpb2QuCgpXM0MgaW52 aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDE4LTA4LTAzIG9uIHRoZQpwcm9wb3NlZCBj aGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpwdWJsaWMtbmV3LXdvcmtAdzMub3JnLCB3 aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2 ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4gY29tbWVudHMgc2VudCBpbiBm b3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0ZWUgUmVwcmVzZW50YXRpdmVz LCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNvbW1lbnRzLiBJZiB5b3Ugd29y ayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5hdGUKeW91ciBjb21tZW50cyB3 aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlLiBGb3IKZXhhbXBsZSwg eW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZpYSB0aGlzIGxpc3QgYW5kCmhh dmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUgcmVmZXIgdG8gaXQgZnJv bSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpJZiB5b3Ugc2hvdWxkIGhhdmUg YW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIHBsZWFzZQpjb250YWN0 IFhpYW9xaWFuIFd1IDx4aWFvcWlhbkB3My5vcmc+LCBwcmltYXJ5IFN0YWZmIENvbnRhY3QKZm9y IHRoZSBXZWIgUGVyZm9ybWFuY2UgV0csIG9yIFBoaWxpcHBlIExlIEhlZ2FyZXQgPHBsaEB3My5v cmc+LgoKVGhhbmsgeW91LAoKWHVleXVhbiBKaWEsIFczQyBNYXJrZXRpbmcgJiBDb21tdW5pY2F0 aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMub3JnL0NvbnNvcnRpdW0vTWVtYmVyL0xpc3QKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldy13b3JrIG1haWxp bmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldy13b3JrCg== From nobody Mon Jul 9 02:40:59 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A52130E1C; Mon, 9 Jul 2018 02:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ-d-aHxOk5a; Mon, 9 Jul 2018 02:40:52 -0700 (PDT) Received: from anna.localdomain (anna.eecs.jacobs-university.de [IPv6:2001:638:709:5::7]) by ietfa.amsl.com (Postfix) with ESMTP id 930B7130E2B; Mon, 9 Jul 2018 02:40:52 -0700 (PDT) Received: by anna.localdomain (Postfix, from userid 501) id 6DE5922FBBEC; Mon, 9 Jul 2018 11:40:50 +0200 (CEST) Date: Mon, 9 Jul 2018 11:40:50 +0200 From: Juergen Schoenwaelder To: Daniel Harkins Cc: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-netconf-nmda-restconf.all@ietf.org Message-ID: <20180709094050.2xo3zocx23o5an55@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Daniel Harkins , "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-netconf-nmda-restconf.all@ietf.org References: <20180704124128.qpr7tunjw5quiex6@anna.jacobs.jacobs-university.de> <9b2f8091-9ead-e188-ee34-1acfead2dcd2@lounge.org> <20180704183436.zjzwz4vowqi5phz7@anna.jacobs.jacobs-university.de> <14e7ae2d-90ae-32c5-c814-a2d31e9f1a4e@lounge.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <14e7ae2d-90ae-32c5-c814-a2d31e9f1a4e@lounge.org> User-Agent: NeoMutt/20180622 Archived-At: Subject: Re: [secdir] review of draft-ietf-netconf-nmda-restconf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 09:40:57 -0000 On Wed, Jul 04, 2018 at 12:46:10PM -0700, Daniel Harkins wrote: > > On 7/4/18 11:34 AM, Juergen Schoenwaelder wrote: > > On Wed, Jul 04, 2018 at 11:08:10AM -0700, Daniel Harkins wrote: > > > > > > I'm suggesting SHOULD _or_ MAY and I thought where would be obvious. > > > It is the places that say "optional to support" in 3.2.1. and 3.2.2 as > > > I indicated. For example, 3.2.1 says, > > > > > > The "with-defaults" query parameter ([RFC8040], Section4.8.9 ) is > > > optional to support when interacting with {+restconf}/ds/ietf- > > > datastores:operational. > > > > > > 3.2.2 has similar text. As to why, it is for consistency and clarity in > > > expressing what you want. > > > > > What is unclear about 'optional to support'? RFC 8040 uses similar > > language and I do not recall that anyone had a problem with this so > > far. > > If you want to reject my comment then just reject my comment. It was made > in the spirit of improving your draft which apparently you take issue with > for some bizarre reason. If someone outside the RFC 8040 bubble you seem to > be > living in found the wording lacking in clarity then it would seem logical to > infer that maybe others might too. Just a thought. > Thanks for your comments. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 9 08:15:53 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC9B12F295; Mon, 9 Jul 2018 08:15:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Leif Johansson To: Cc: draft-ietf-insipid-logme-marking.all@ietf.org, insipid@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153114934615.5366.9894430842150985630@ietfa.amsl.com> Date: Mon, 09 Jul 2018 08:15:46 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-insipid-logme-marking-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 15:15:47 -0000 Reviewer: Leif Johansson Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. >From the abstract: This document describes an indicator for the SIP protocol which can be used to mark signaling as being of interest to logging. The document is clearly written and feels ready for publication from a quality standpoint. My only issue is in 7.4.6 - User Control of Logging: Why is the "must" in the first paragraph non-normative? Is it because there is no way to prove the existence or absence of user consent? I realize this may be a hard problem to solve but if this issue was considered and rejected it might be worth including a discussion about this in the document. From nobody Mon Jul 9 09:04:19 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBBF130E48; Mon, 9 Jul 2018 09:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L47ePNAFVgHn; Mon, 9 Jul 2018 09:04:08 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 F1557130E31; Mon, 9 Jul 2018 09:04:07 -0700 (PDT) Received: from trixy.bergandi.net ([76.93.146.89]) by wwwlocal.goatley.com (PMDF V6.7-x02 #1001) with ESMTP id <0PBL00J7MWMVC6@wwwlocal.goatley.com>; Mon, 09 Jul 2018 11:04:07 -0500 (CDT) Received: from thinny.local ([66.238.57.226]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PBL0041UWMMH4@trixy.bergandi.net>; Mon, 09 Jul 2018 09:03:59 -0700 (PDT) Received: from 66.238.57.226.ptr.us.xo.net ([66.238.57.226] EXTERNAL) (EHLO thinny.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Mon, 09 Jul 2018 09:03:59 -0700 Date: Mon, 09 Jul 2018 09:03:12 -0700 From: Daniel Harkins In-reply-to: To: Kent Watsen , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-netconf-nmda-restconf.all@ietf.org" Message-id: <8dbe0263-de63-0ddd-86db-04fa7744155c@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=66.238.57.226) X-PMAS-External-Auth: 66.238.57.226.ptr.us.xo.net [66.238.57.226] (EHLO thinny.local) References: <20180704124128.qpr7tunjw5quiex6@anna.jacobs.jacobs-university.de> <9b2f8091-9ead-e188-ee34-1acfead2dcd2@lounge.org> <20180704183436.zjzwz4vowqi5phz7@anna.jacobs.jacobs-university.de> <14e7ae2d-90ae-32c5-c814-a2d31e9f1a4e@lounge.org> X-PMAS-Software: PreciseMail V3.3 [180709] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [secdir] review of draft-ietf-netconf-nmda-restconf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 16:04:11 -0000 On 7/5/18 7:46 AM, Kent Watsen wrote: > I think that the current wording is okay, but I'm okay with changing > it too. How about this? > > > OLD: > The "with-defaults" query parameter ([RFC8040], Section 4.8.9) is > optional to support when interacting with {+restconf}/ds/ietf- > datastores:operational. The associated capability to indicate a > server's support is identified with the URI: > > NEW: > The "with-defaults" query parameter ([RFC8040], Section 4.8.9) > MAY be supported for the operational state datastore. Support > for the "with-defaults" query parameter for the operational > state datastore is identified with the URI: > > > > OLD: > The "with-origin" query parameter is optional to support. It is > identified with the URI: > > NEW: > The "with-origin" query parameter MAY be supported. Support > for the "with-origin" query parameter is identified with the > URI: > > > > FWIW, elsewhere in the draft is another "optional" usage that could > be changed: > > OLD: > An NMDA-compliant server MUST implement {+restconf}/ds/ietf- > datastores:operational. Other datastore resources are optional to > implement. > > NEW: > An NMDA-compliant server MUST implement {+restconf}/ds/ietf- > datastores:operational. Other datastore resources MAY be > implemented. > > > > Comments?   Looks fine, thanks.   Dan. > > Kent // co-author > > > > On 7/4/18 11:34 AM, Juergen Schoenwaelder wrote: >> On Wed, Jul 04, 2018 at 11:08:10AM -0700, Daniel Harkins wrote: >>> I'm suggesting SHOULD _or_ MAY and I thought where would be obvious. >>> It is the places that say "optional to support" in 3.2.1. and 3.2.2 as >>> I indicated. For example, 3.2.1 says, >>> >>> The "with-defaults" query parameter ([RFC8040], Section 4.8.9 ) is >>> optional to support when interacting with {+restconf}/ds/ietf- >>> datastores:operational. >>> >>> 3.2.2 has similar text. As to why, it is for consistency and clarity in >>> expressing what you want. >>> >> What is unclear about 'optional to support'? RFC 8040 uses similar >> language and I do not recall that anyone had a problem with this so >> far. > If you want to reject my comment then just reject my comment. It was made > in the spirit of improving your draft which apparently you take issue with > for some bizarre reason. If someone outside the RFC 8040 bubble you seem > to be > living in found the wording lacking in clarity then it would seem logical to > infer that maybe others might too. Just a thought. > > Dan. > > > > From nobody Mon Jul 9 17:49:07 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8412412F1AB; Mon, 9 Jul 2018 17:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nEkww8oerGM; Mon, 9 Jul 2018 17:48:57 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6330127148; Mon, 9 Jul 2018 17:48:56 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id e13-v6so1464574pff.7; Mon, 09 Jul 2018 17:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qHXkPQ6lnv4ugCHg4oEcSh1aBKeb6eL14MEpBUpM8jQ=; b=nyiNhAc/ZBR1vXD6faC1MouU7MYrRrOMj9s6/r1DwzuXvMb9HhAxpaLxBqHsX2WPN2 OjnKXBnVGjWqtPwgmPe96mXfzbkqtNmg9N8lCdUj7wr6rs5gn3YRflF45mG2AltunbPA F/iNl4EBgImKfKTj7uQrDrlx+b0aYluDpbNudi4pKK44WQJYlORiwXKEV7dTLhGR5gUA JYY7ytWTqYo/Lb5Xe6sBqfWRvQTGOmw42DJYPRGE5zdfpODCQKzpx+aaAwYo+I+P1btY QglXl6k1goaCGEqoHPeCxNIJrE/wJ4WOkMj/2LYy6wtJyfsZVeJsHyX6kD1xo1RVjJsk m9VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qHXkPQ6lnv4ugCHg4oEcSh1aBKeb6eL14MEpBUpM8jQ=; b=jQ1rKRBWmspeSZZ11M1PGMzj2zmISK4NhDkqtws/QpPKRlz0ORwsFrMvHsbIUaT/In zKnadBWAOnv4AvsBHNer0xfiNoXSyZdSmg0Zejv6Yw+ilIpbXPbHsDK5QlA918myJxuq 5lkpF82tgholis0caZn7cGg0YwNJckL44E/subUzM/fqqyzk0eW+P9Szp+Tj+OedyKhC j0np+Wg6wRF+bYY4J50FkDoBIJCCDMMysqPJhvCpiZYowV+teF9IZiJKK+7ujDCk2qdw RH2Hupz62MJgc9TSIxeHfqL31GZLzUXoGwjk4L6Q9y36Puk6cRViTEucTpY6YqVJNJoi hnwA== X-Gm-Message-State: APt69E1jkf6mkDwYx7pNYEf4eF4gLUgDkxCgVLMHcQTNn55vUGiLhKFs wLgHTwY6EsxOTqxfwlLc18DM8pkZ X-Google-Smtp-Source: AAOMgpcKVlnoyzqoUwNY4RHZRLIc2g7mUUPgGlYwk1Lpj/GdH/xBo6goNFqPBa9UDxxWobuhQwDhFw== X-Received: by 2002:a62:3f44:: with SMTP id m65-v6mr23230514pfa.98.1531183736376; Mon, 09 Jul 2018 17:48:56 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:b836:21af:f5df:8992? ([2601:647:4700:1280:b836:21af:f5df:8992]) by smtp.gmail.com with ESMTPSA id f24-v6sm27805068pfe.39.2018.07.09.17.48.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 17:48:55 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <99EB8497-BCC0-45A3-A412-6FC5036243F6@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_88C26629-0030-41AC-832B-DAB98C0235EB" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Mon, 9 Jul 2018 17:48:53 -0700 In-Reply-To: <8dbe0263-de63-0ddd-86db-04fa7744155c@lounge.org> Cc: Kent Watsen , The IESG , "secdir@ietf.org" , "draft-ietf-netconf-nmda-restconf.all@ietf.org" To: Daniel Harkins References: <20180704124128.qpr7tunjw5quiex6@anna.jacobs.jacobs-university.de> <9b2f8091-9ead-e188-ee34-1acfead2dcd2@lounge.org> <20180704183436.zjzwz4vowqi5phz7@anna.jacobs.jacobs-university.de> <14e7ae2d-90ae-32c5-c814-a2d31e9f1a4e@lounge.org> <8dbe0263-de63-0ddd-86db-04fa7744155c@lounge.org> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [secdir] review of draft-ietf-netconf-nmda-restconf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 00:49:00 -0000 --Apple-Mail=_88C26629-0030-41AC-832B-DAB98C0235EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There have been a few comments that have been made to the version of the = draft that has been submitted to IESG. While we wait for other comments = to be provided, and direction of when an update should be provided, who = amongst the authors is updating GitHub with these changes?=20 I am concerned we might lose track of the changes that need to be made. Here are the changes that I am aware of for nmda-restconf. I can compile = a similar list for nmda-netconf if needed. Kent=E2=80=99s comment on nmda-restconf operations (thread = = from today). Dan=E2=80=99s comment on this thread (also from today, but is not on = netconf mailing list) Russ=E2=80=99s Genart review (thread = = from June 28) Rohit=E2=80=99s change-2 comments provided for nmda-netconf, that are = applicable for nmda-restconf (thread = = from June 1) Anything else that I missing? Mahesh Jethanandani // as document shephard > On Jul 9, 2018, at 9:03 AM, Daniel Harkins = wrote: >=20 >=20 > On 7/5/18 7:46 AM, Kent Watsen wrote: >> I think that the current wording is okay, but I'm okay with changing >> it too. How about this? >>=20 >>=20 >> OLD: >> The "with-defaults" query parameter ([RFC8040], Section 4.8.9) is >> optional to support when interacting with {+restconf}/ds/ietf- >> datastores:operational. The associated capability to indicate a >> server's support is identified with the URI: >>=20 >> NEW: >> The "with-defaults" query parameter ([RFC8040], Section 4.8.9) >> MAY be supported for the operational state datastore. Support >> for the "with-defaults" query parameter for the operational >> state datastore is identified with the URI: >>=20 >>=20 >>=20 >> OLD: >> The "with-origin" query parameter is optional to support. It is >> identified with the URI: >>=20 >> NEW: >> The "with-origin" query parameter MAY be supported. Support >> for the "with-origin" query parameter is identified with the >> URI: >>=20 >>=20 >>=20 >> FWIW, elsewhere in the draft is another "optional" usage that could >> be changed: >>=20 >> OLD: >> An NMDA-compliant server MUST implement {+restconf}/ds/ietf- >> datastores:operational. Other datastore resources are optional to >> implement. >>=20 >> NEW: >> An NMDA-compliant server MUST implement {+restconf}/ds/ietf- >> datastores:operational. Other datastore resources MAY be >> implemented. >>=20 >>=20 >>=20 >> Comments? >=20 > Looks fine, thanks. >=20 > Dan. >=20 >>=20 >> Kent // co-author >>=20 >>=20 >>=20 >> On 7/4/18 11:34 AM, Juergen Schoenwaelder wrote: >>> On Wed, Jul 04, 2018 at 11:08:10AM -0700, Daniel Harkins wrote: >>>> I'm suggesting SHOULD _or_ MAY and I thought where would be = obvious. >>>> It is the places that say "optional to support" in 3.2.1. and 3.2.2 = as >>>> I indicated. For example, 3.2.1 says, >>>>=20 >>>> The "with-defaults" query parameter ([RFC8040], Section 4.8.9 = ) is >>>> optional to support when interacting with {+restconf}/ds/ietf- >>>> datastores:operational. >>>>=20 >>>> 3.2.2 has similar text. As to why, it is for consistency and = clarity in >>>> expressing what you want. >>>>=20 >>> What is unclear about 'optional to support'? RFC 8040 uses similar >>> language and I do not recall that anyone had a problem with this so >>> far. >> If you want to reject my comment then just reject my comment. It = was made >> in the spirit of improving your draft which apparently you take issue = with >> for some bizarre reason. If someone outside the RFC 8040 bubble you = seem >> to be >> living in found the wording lacking in clarity then it would seem = logical to >> infer that maybe others might too. Just a thought. >>=20 >> Dan. --Apple-Mail=_88C26629-0030-41AC-832B-DAB98C0235EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 There= have been a few comments that have been made to the version of the = draft that has been submitted to IESG. While we wait for other comments = to be provided, and direction of when an update should be provided, who = amongst the authors is updating GitHub with these changes? 

I am concerned we might = lose track of the changes that need to be made.

Here are the changes that I am aware of = for nmda-restconf. I can compile a similar list for nmda-netconf if = needed.

Kent=E2=80= =99s comment on nmda-restconf operations (thread from today).
Dan=E2=80=99= s comment on this thread (also from today, but is not on netconf mailing = list)
Russ=E2=80=99s Genart review (thread from June 28)
Rohit=E2=80= =99s change-2 comments provided for nmda-netconf, that are applicable = for nmda-restconf (thread from June 1)

Anything else that I missing?


Mahesh Jethanandani // as document = shephard

On Jul 9, 2018, at 9:03 AM, Daniel Harkins = <dharkins@lounge.org> wrote:


On 7/5/18 7:46 AM, Kent Watsen = wrote:
I = think that the current wording is okay, but I'm okay with changing
it too. How about this?


OLD:
   The "with-defaults" = query parameter ([RFC8040], Section 4.8.9) is
   optional to support when interacting with = {+restconf}/ds/ietf-
   datastores:operational.  The = associated capability to indicate a
   server's support is identified with the = URI:

NEW:
   The= "with-defaults" query parameter ([RFC8040], Section 4.8.9)
   MAY be supported for the operational state = datastore.  Support
   for the = "with-defaults" query parameter for the operational
   state datastore is identified with the = URI:



OLD:
   The "with-origin" query parameter is = optional to support.  It is
   identified with the URI:

NEW:
   The "with-origin" query = parameter MAY be supported.  Support
   for the "with-origin" query parameter is = identified with the
   URI:


FWIW, elsewhere in the draft = is another "optional" usage that could
be changed:

 OLD:
   An = NMDA-compliant server MUST implement {+restconf}/ds/ietf-
   datastores:operational.  Other = datastore resources are optional to
   implement.

 NEW:
   An NMDA-compliant = server MUST implement {+restconf}/ds/ietf-
   datastores:operational.  Other = datastore resources MAY be
   implemented.


Comments?

  Looks fine, thanks.

  Dan.


Kent  // = co-author



On = 7/4/18 11:34 AM, Juergen Schoenwaelder wrote:
On Wed, Jul 04, 2018 at 11:08:10AM -0700, = Daniel Harkins wrote:
   I'm suggesting SHOULD _or_ MAY and I = thought where would be obvious.
It is the places that say = "optional to support" in 3.2.1. and 3.2.2 as
I indicated. = For example, 3.2.1 says,

    The "with-defaults" query parameter = ([RFC8040], Section 4.8.9 <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ie= tf.org_html_rfc8040-23section-2D4.8.9&d=3DDwIDaQ&c=3DHAkYuh63rsuhr= 6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjI= SlaJdcZo&m=3DfApqY-LnEgjm4NbObNcu5L44jAZ2UYJz0CWl5q4U0YE&s=3Dr65ka= kpgV3OSbY6iIzByXMmqvV-45Vo9wkXZHji8jlk&e=3D>) is
    optional to support when interacting = with {+restconf}/ds/ietf-
    datastores:operational.

3.2.2 has similar text. As to why, it is for = consistency and clarity in
expressing what you want.

What is unclear about 'optional = to support'? RFC 8040 uses similar
language and I do not = recall that anyone had a problem with this so
far.
   If you want to reject my = comment then just reject my comment. It was made
in the = spirit of improving your draft which apparently you take issue with
for some bizarre reason. If someone outside the RFC 8040 = bubble you seem
to be
living in found the = wording lacking in clarity then it would seem logical to
infer that maybe others might too. Just a thought.

   Dan.


= --Apple-Mail=_88C26629-0030-41AC-832B-DAB98C0235EB-- From nobody Tue Jul 10 19:11:35 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1C0130DD6; Tue, 10 Jul 2018 19:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HecG8wGJdQ1o; Tue, 10 Jul 2018 19:11:31 -0700 (PDT) Received: from mail-pl0-x242.google.com (mail-pl0-x242.google.com [IPv6:2607:f8b0:400e:c01::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5410712E039; Tue, 10 Jul 2018 19:11:31 -0700 (PDT) Received: by mail-pl0-x242.google.com with SMTP id a17-v6so2598008plm.12; Tue, 10 Jul 2018 19:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=U7jMd0VEur2N8ccCfvW3PqmeV3tmHl1og1tbuB/8vK8=; b=t+RWotPVE3f31RfaS9cZOkagnq1ofqWBXwb6GJ+XjMAwOcr+FLtkg8S2CywgqnC3+3 TADY6qYhL0RRzXvvUcWkC7vRCKe/wpW1SZblzM8t+9jg93P3ej6Yy1txpRTcgf3xuocS ZybXbWc6cEbGdr24uixmHMmJyV54iZNYgZbCDIiqRxH76TLJ7ic9Lkyjp0X06S7YB5uh bsKOn4AVjsUW4eenoRHrZMcG8Mt2rn2K8JP2dDp5Pd3h9pB4Xh7z3L7lk9Q8IHdGh9pt D1oGxe0Wl793vUn9SUii/ObWQG/xWy+YgKJACnDkvUxOuC/B3Wogld0b/koDcEbmxC91 nUcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=U7jMd0VEur2N8ccCfvW3PqmeV3tmHl1og1tbuB/8vK8=; b=j5Hvud692e5BzvZ8Cwy1qPjhaJPydtr3QmWvgw5n6Z4W5DNo+L9WRUPazyw6u+C6ez MlzqI0ZsUUIszvJbdm0gFfcc3ZqSsDd9vDmrKcKhpcDIRyLi33HBZCyWBLj9GSAxdsZ8 YQJrtHcbFh1RZJPwxiugZ1SpNktY9m5ioWfoJ3xbbt7bA/LQafffqJ3Xd5QeAM2oyFYn VG4c6CKof2skSpoIx9LlPF53/XEAr7psvMA5CBcagLdiMSkrZw5si4d8PmYk9/sL7YIo mVNp5S92x8dw3k6T+v7UTx6PaKPT5aYIwjvTZYm/W1W3X1Af+5z0LyY2MFJZZGwlqLF4 ybMQ== X-Gm-Message-State: APt69E02DJqXbmTVIjBauOog+xITF5w0vg/rKDYWHglFo7LnGAEGjESb jkwAYE/aYVkb259ifCIKan8= X-Google-Smtp-Source: AAOMgpcgKotx6Ng7Xi8uGYni/tIWXXRTTNhH/9G3GGx131yDKJZcTmBh9Ffye++8KXdCY3JAVcHpzw== X-Received: by 2002:a17:902:1007:: with SMTP id b7-v6mr26618730pla.277.1531275090900; Tue, 10 Jul 2018 19:11:30 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:816f:61c5:5a86:f7b1? ([2601:647:4700:1280:816f:61c5:5a86:f7b1]) by smtp.gmail.com with ESMTPSA id k16-v6sm4602062pfb.93.2018.07.10.19.11.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 19:11:29 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <22FA0124-48E4-46D2-B4DA-37DBF840DFC3@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_28A91719-5742-4315-91AD-A7FBE84C27FB" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 10 Jul 2018 19:11:28 -0700 In-Reply-To: <5f33d7efee044a08b51d206b605b945c@infineon.com> Cc: The IESG , secdir@ietf.org, draft-ietf-netmod-acl-model.all@ietf.org To: Steve.Hanna@infineon.com References: <5f33d7efee044a08b51d206b605b945c@infineon.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [secdir] Review of draft-ietf-netmod-acl-model-19.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 02:11:34 -0000 --Apple-Mail=_28A91719-5742-4315-91AD-A7FBE84C27FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Steve, > On Jun 29, 2018, at 3:12 PM, Steve.Hanna@infineon.com wrote: >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > The summary of the review is Ready with issues. >=20 > This document defines a YANG data model for ACL. When the term > "ACL" is used in this document it means the sort of ACL that > you might see in firewall rules (e.g., "drop IPv4 traffic with > destination port 21"). >=20 > *Overall Clarity and Quality* >=20 > The document is fairly clear and well written. However, there > is a confusing typo that is listed in the Minor Errors section > of this review. >=20 > *Security Analysis* >=20 > The Security Considerations section is brief but decent. > However, the last two sentences are unclear and maybe wrong: >=20 > Unauthorized write access to this list can allow intruders > to access and control the system. Unauthorized read access > to this list can allow intruders to spoof packets with > authorized addresses thereby compromising the system. >=20 > Which "system" is referred to here? Whatever the answer to > that question, I believe that the main impact of unauthorized > write access to the ACL is that the attacker can modify the > ACL to permit traffic that should not be permitted or deny > traffic that should be permitted. The former may result in > denial of service or compromise of systems on the network. > The latter may result in denial of service. The main impact > of unauthorized read access to the ACL is that the attacker > can determine what ACL rules are in effect and may be able > to use this information to better craft an attack. Ok. How about this? OLD: /acls/acl/aces: This list specifies all the configured access control entries on the device. Unauthorized write access to this list can allow intruders to access and control the system. Unauthorized read access to this list can allow intruders to spoof packets with authorized addresses thereby compromising the system. NEW: /acls/acl/aces: This list specifies all the configured = access control entries on the device. Unauthorized write access to this list can allow intruders to modify the entries so as to permit = traffic that should not be permitted, or deny traffic that should be = permitted. The former may result in a DoS attack, or compromise the device. The latter may result in a DoS attack. The impact of an = unauthorized=20 read access to the list will allow the attacker to determine which = rules are in effect, to better craft an attack. >=20 > *Minor Errors* >=20 > Section 3 refers to "action criteria". Every other part of > the specification refers only to "action" or "actions". > My review of the specification indicates that this text > in section 3 should say "actions" not "action criteria=E2=80=9D. There are three instances of =E2=80=9Caction criteria=E2=80=9D in the = document. But you point is well taken, they can all be changed to = =E2=80=9Caction=E2=80=9D or =E2=80=9Cactions=E2=80=9D. Cheers. >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_28A91719-5742-4315-91AD-A7FBE84C27FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Steve,

On Jun 29, 2018, at 3:12 PM, Steve.Hanna@infineon.com wrote:

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

The summary of = the review is Ready with issues.

This = document defines a YANG data model for ACL. When the term
"ACL" is used in this document it means the sort of ACL = that
you might see in firewall rules (e.g., "drop IPv4 = traffic with
destination port 21").

*Overall Clarity and Quality*

The = document is fairly clear and well written. However, there
is= a confusing typo that is listed in the Minor Errors section
of this review.

*Security = Analysis*

The Security Considerations = section is brief but decent.
However, the last two = sentences are unclear and maybe wrong:

=   Unauthorized write access to this list can allow = intruders
  to access and control the system. = Unauthorized read access
  to this list can = allow intruders to spoof packets with
=   authorized addresses thereby compromising the system.

Which "system" is referred to here? Whatever = the answer to
that question, I believe that the main = impact of unauthorized
write access to the ACL is that the = attacker can modify the
ACL to permit traffic that should = not be permitted or deny
traffic that should be permitted. = The former may result in
denial of service or compromise = of systems on the network.
The latter may result in denial = of service. The main impact
of unauthorized read access to = the ACL is that the attacker
can determine what ACL rules = are in effect and may be able
to use this information to = better craft an attack.

Ok. How about this?

OLD:
      /acls/acl/aces: This list specifies all the configured access
      control entries on the device.  Unauthorized write access to this
      list can allow intruders to access and control the system.
      Unauthorized read access to this list can allow intruders to spoof
      packets with authorized addresses thereby compromising the =
system.


NEW:
          =     /acls/acl/aces: This list specifies all the = configured access
      control =
entries on the device.  Unauthorized write access to this
      list can allow intruders to modify the entries so as to permit =
traffic
      that =
should not be permitted, or deny traffic that should be =
permitted.
      The former =
may result in a DoS attack, or compromise the device.
      The latter may result in a DoS attack. The =
impact of an unauthorized 
      read access to the list will allow the attacker to determine =
which rules
      are in =
effect, to better craft an attack.



*Minor = Errors*

Section 3 refers to "action = criteria". Every other part of
the specification refers = only to "action" or "actions".
My review of the = specification indicates that this text
in section 3 should = say "actions" not "action criteria=E2=80=9D.

There are = three instances of =E2=80=9Caction criteria=E2=80=9D in the document. = But you point is well taken, they can all be changed to =E2=80=9Caction=E2= =80=9D or =E2=80=9Cactions=E2=80=9D.

Cheers.



Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_28A91719-5742-4315-91AD-A7FBE84C27FB-- From nobody Tue Jul 10 19:33:15 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3621130DD9; Tue, 10 Jul 2018 19:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infineon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opM0ljcPuoBw; Tue, 10 Jul 2018 19:33:07 -0700 (PDT) Received: from smtp2.infineon.com (smtp2.infineon.com [IPv6:2a00:18f0:1e00:4::4]) (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 EEE2E12E039; Tue, 10 Jul 2018 19:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infineon.com; i=@infineon.com; q=dns/txt; s=IFXMAIL; t=1531276386; x=1562812386; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HB+/PpFh8tTmlv3INAwiLKxlvmDQ/tlkQJ/XwwrCMCI=; b=WlLHwHCeRAgxUW7l6ov7eyKtMTcKRsdrkfVv0oIttCCzSEaQuU0xV96J 49W7wFkO4pSp8gLCjIOgdW4wBXufGC3Z2JSRj6RH97gdzyyix3o9xtx5O +Drk1ao2EiTIxgUAip6YNL7fyOVZq6/s/gmoDM5gkxkNCtFpu11/YOoBI w=; X-SBRS: None X-IronPort-AV: E=McAfee;i="5900,7806,8950"; a="71684845" X-IronPort-AV: E=Sophos; i="5.51,336,1526335200"; d="scan'208,217"; a="71684845" Received: from unknown (HELO mucxv003.muc.infineon.com) ([172.23.11.20]) by smtp2.infineon.com with ESMTP/TLS/AES256-GCM-SHA384; 11 Jul 2018 04:33:03 +0200 Received: from MUCSE706.infineon.com (MUCSE706.infineon.com [172.23.7.80]) by mucxv003.muc.infineon.com (Postfix) with ESMTPS; Wed, 11 Jul 2018 04:33:03 +0200 (CEST) Received: from MUCSE707.infineon.com (172.23.7.81) by MUCSE706.infineon.com (172.23.7.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1466.3; Wed, 11 Jul 2018 04:33:03 +0200 Received: from MUCSE707.infineon.com ([172.23.106.27]) by MUCSE707.infineon.com ([172.23.106.27]) with mapi id 15.01.1466.008; Wed, 11 Jul 2018 04:33:03 +0200 From: To: CC: , , Thread-Topic: Review of draft-ietf-netmod-acl-model-19.txt Thread-Index: AdQP9Y2jSrah9SdYSKyvzsnOr44HiQItijMAAATugcA= Date: Wed, 11 Jul 2018 02:33:03 +0000 Message-ID: References: <5f33d7efee044a08b51d206b605b945c@infineon.com> <22FA0124-48E4-46D2-B4DA-37DBF840DFC3@gmail.com> In-Reply-To: <22FA0124-48E4-46D2-B4DA-37DBF840DFC3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.8.247] Content-Type: multipart/alternative; boundary="_000_d3791f64130a473eb6d3d65694ae817binfineoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Review of draft-ietf-netmod-acl-model-19.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 02:33:09 -0000 --_000_d3791f64130a473eb6d3d65694ae817binfineoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFoZXNoLA0KDQpMb29rcyBnb29kIHRvIG1lLiBUaG9zZSBjaGFuZ2VzIHdpbGwgcmVzb2x2ZSBt eSBjb25jZXJucy4NCg0KVGhhbmtzLA0KDQpTdGV2ZQ0KDQpGcm9tOiBNYWhlc2ggSmV0aGFuYW5k YW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMTAsIDIw MTggMTA6MTEgUE0NClRvOiBIYW5uYSBTdGV2ZSAoSUZBTSBDQ1MgU01EIEFNUikgPFN0ZXZlLkhh bm5hQGluZmluZW9uLmNvbT4NCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IHNlY2RpckBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLmFsbEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFJldmlldyBvZiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTkudHh0DQoNCkhp IFN0ZXZlLA0KDQoNCk9uIEp1biAyOSwgMjAxOCwgYXQgMzoxMiBQTSwgU3RldmUuSGFubmFAaW5m aW5lb24uY29tPG1haWx0bzpTdGV2ZS5IYW5uYUBpbmZpbmVvbi5jb20+IHdyb3RlOg0KDQpJIGhh dmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3Rv cmF0ZSdzDQpvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5n IHByb2Nlc3NlZCBieSB0aGUNCklFU0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmlt YXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZQ0Kc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERv Y3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQNCnRoZXNlIGNvbW1lbnRz IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpUaGUgc3VtbWFyeSBv ZiB0aGUgcmV2aWV3IGlzIFJlYWR5IHdpdGggaXNzdWVzLg0KDQpUaGlzIGRvY3VtZW50IGRlZmlu ZXMgYSBZQU5HIGRhdGEgbW9kZWwgZm9yIEFDTC4gV2hlbiB0aGUgdGVybQ0KIkFDTCIgaXMgdXNl ZCBpbiB0aGlzIGRvY3VtZW50IGl0IG1lYW5zIHRoZSBzb3J0IG9mIEFDTCB0aGF0DQp5b3UgbWln aHQgc2VlIGluIGZpcmV3YWxsIHJ1bGVzIChlLmcuLCAiZHJvcCBJUHY0IHRyYWZmaWMgd2l0aA0K ZGVzdGluYXRpb24gcG9ydCAyMSIpLg0KDQoqT3ZlcmFsbCBDbGFyaXR5IGFuZCBRdWFsaXR5Kg0K DQpUaGUgZG9jdW1lbnQgaXMgZmFpcmx5IGNsZWFyIGFuZCB3ZWxsIHdyaXR0ZW4uIEhvd2V2ZXIs IHRoZXJlDQppcyBhIGNvbmZ1c2luZyB0eXBvIHRoYXQgaXMgbGlzdGVkIGluIHRoZSBNaW5vciBF cnJvcnMgc2VjdGlvbg0Kb2YgdGhpcyByZXZpZXcuDQoNCipTZWN1cml0eSBBbmFseXNpcyoNCg0K VGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMgYnJpZWYgYnV0IGRlY2VudC4N Ckhvd2V2ZXIsIHRoZSBsYXN0IHR3byBzZW50ZW5jZXMgYXJlIHVuY2xlYXIgYW5kIG1heWJlIHdy b25nOg0KDQogIFVuYXV0aG9yaXplZCB3cml0ZSBhY2Nlc3MgdG8gdGhpcyBsaXN0IGNhbiBhbGxv dyBpbnRydWRlcnMNCiAgdG8gYWNjZXNzIGFuZCBjb250cm9sIHRoZSBzeXN0ZW0uIFVuYXV0aG9y aXplZCByZWFkIGFjY2Vzcw0KICB0byB0aGlzIGxpc3QgY2FuIGFsbG93IGludHJ1ZGVycyB0byBz cG9vZiBwYWNrZXRzIHdpdGgNCiAgYXV0aG9yaXplZCBhZGRyZXNzZXMgdGhlcmVieSBjb21wcm9t aXNpbmcgdGhlIHN5c3RlbS4NCg0KV2hpY2ggInN5c3RlbSIgaXMgcmVmZXJyZWQgdG8gaGVyZT8g V2hhdGV2ZXIgdGhlIGFuc3dlciB0bw0KdGhhdCBxdWVzdGlvbiwgSSBiZWxpZXZlIHRoYXQgdGhl IG1haW4gaW1wYWN0IG9mIHVuYXV0aG9yaXplZA0Kd3JpdGUgYWNjZXNzIHRvIHRoZSBBQ0wgaXMg dGhhdCB0aGUgYXR0YWNrZXIgY2FuIG1vZGlmeSB0aGUNCkFDTCB0byBwZXJtaXQgdHJhZmZpYyB0 aGF0IHNob3VsZCBub3QgYmUgcGVybWl0dGVkIG9yIGRlbnkNCnRyYWZmaWMgdGhhdCBzaG91bGQg YmUgcGVybWl0dGVkLiBUaGUgZm9ybWVyIG1heSByZXN1bHQgaW4NCmRlbmlhbCBvZiBzZXJ2aWNl IG9yIGNvbXByb21pc2Ugb2Ygc3lzdGVtcyBvbiB0aGUgbmV0d29yay4NClRoZSBsYXR0ZXIgbWF5 IHJlc3VsdCBpbiBkZW5pYWwgb2Ygc2VydmljZS4gVGhlIG1haW4gaW1wYWN0DQpvZiB1bmF1dGhv cml6ZWQgcmVhZCBhY2Nlc3MgdG8gdGhlIEFDTCBpcyB0aGF0IHRoZSBhdHRhY2tlcg0KY2FuIGRl dGVybWluZSB3aGF0IEFDTCBydWxlcyBhcmUgaW4gZWZmZWN0IGFuZCBtYXkgYmUgYWJsZQ0KdG8g dXNlIHRoaXMgaW5mb3JtYXRpb24gdG8gYmV0dGVyIGNyYWZ0IGFuIGF0dGFjay4NCg0KT2suIEhv dyBhYm91dCB0aGlzPw0KDQpPTEQ6DQoNCiAgICAgIC9hY2xzL2FjbC9hY2VzOiBUaGlzIGxpc3Qg c3BlY2lmaWVzIGFsbCB0aGUgY29uZmlndXJlZCBhY2Nlc3MNCg0KICAgICAgY29udHJvbCBlbnRy aWVzIG9uIHRoZSBkZXZpY2UuICBVbmF1dGhvcml6ZWQgd3JpdGUgYWNjZXNzIHRvIHRoaXMNCg0K ICAgICAgbGlzdCBjYW4gYWxsb3cgaW50cnVkZXJzIHRvIGFjY2VzcyBhbmQgY29udHJvbCB0aGUg c3lzdGVtLg0KDQogICAgICBVbmF1dGhvcml6ZWQgcmVhZCBhY2Nlc3MgdG8gdGhpcyBsaXN0IGNh biBhbGxvdyBpbnRydWRlcnMgdG8gc3Bvb2YNCg0KICAgICAgcGFja2V0cyB3aXRoIGF1dGhvcml6 ZWQgYWRkcmVzc2VzIHRoZXJlYnkgY29tcHJvbWlzaW5nIHRoZSBzeXN0ZW0uDQoNCg0KTkVXOg0K ICAgICAgICAgICAgICAvYWNscy9hY2wvYWNlczogVGhpcyBsaXN0IHNwZWNpZmllcyBhbGwgdGhl IGNvbmZpZ3VyZWQgYWNjZXNzDQoNCiAgICAgIGNvbnRyb2wgZW50cmllcyBvbiB0aGUgZGV2aWNl LiAgVW5hdXRob3JpemVkIHdyaXRlIGFjY2VzcyB0byB0aGlzDQoNCiAgICAgIGxpc3QgY2FuIGFs bG93IGludHJ1ZGVycyB0byBtb2RpZnkgdGhlIGVudHJpZXMgc28gYXMgdG8gcGVybWl0IHRyYWZm aWMNCg0KICAgICAgdGhhdCBzaG91bGQgbm90IGJlIHBlcm1pdHRlZCwgb3IgZGVueSB0cmFmZmlj IHRoYXQgc2hvdWxkIGJlIHBlcm1pdHRlZC4NCg0KICAgICAgVGhlIGZvcm1lciBtYXkgcmVzdWx0 IGluIGEgRG9TIGF0dGFjaywgb3IgY29tcHJvbWlzZSB0aGUgZGV2aWNlLg0KDQogICAgICBUaGUg bGF0dGVyIG1heSByZXN1bHQgaW4gYSBEb1MgYXR0YWNrLiBUaGUgaW1wYWN0IG9mIGFuIHVuYXV0 aG9yaXplZA0KDQogICAgICByZWFkIGFjY2VzcyB0byB0aGUgbGlzdCB3aWxsIGFsbG93IHRoZSBh dHRhY2tlciB0byBkZXRlcm1pbmUgd2hpY2ggcnVsZXMNCg0KICAgICAgYXJlIGluIGVmZmVjdCwg dG8gYmV0dGVyIGNyYWZ0IGFuIGF0dGFjay4NCg0KDQoNCg0KKk1pbm9yIEVycm9ycyoNCg0KU2Vj dGlvbiAzIHJlZmVycyB0byAiYWN0aW9uIGNyaXRlcmlhIi4gRXZlcnkgb3RoZXIgcGFydCBvZg0K dGhlIHNwZWNpZmljYXRpb24gcmVmZXJzIG9ubHkgdG8gImFjdGlvbiIgb3IgImFjdGlvbnMiLg0K TXkgcmV2aWV3IG9mIHRoZSBzcGVjaWZpY2F0aW9uIGluZGljYXRlcyB0aGF0IHRoaXMgdGV4dA0K aW4gc2VjdGlvbiAzIHNob3VsZCBzYXkgImFjdGlvbnMiIG5vdCAiYWN0aW9uIGNyaXRlcmlh4oCd Lg0KDQpUaGVyZSBhcmUgdGhyZWUgaW5zdGFuY2VzIG9mIOKAnGFjdGlvbiBjcml0ZXJpYeKAnSBp biB0aGUgZG9jdW1lbnQuIEJ1dCB5b3UgcG9pbnQgaXMgd2VsbCB0YWtlbiwgdGhleSBjYW4gYWxs IGJlIGNoYW5nZWQgdG8g4oCcYWN0aW9u4oCdIG9yIOKAnGFjdGlvbnPigJ0uDQoNCkNoZWVycy4N Cg0KDQoNCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFp bHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQo= --_000_d3791f64130a473eb6d3d65694ae817binfineoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ TWFoZXNoLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Mb29rcyBnb29kIHRvIG1lLiBUaG9zZSBjaGFuZ2VzIHdp bGwgcmVzb2x2ZSBteSBjb25jZXJucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5TdGV2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1haGVzaCBKZXRoYW5hbmRh bmkgJmx0O21qZXRoYW5hbmRhbmlAZ21haWwuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIEp1bHkgMTAsIDIwMTggMTA6MTEgUE08YnI+DQo8Yj5Ubzo8L2I+IEhhbm5hIFN0ZXZl IChJRkFNIENDUyBTTUQgQU1SKSAmbHQ7U3RldmUuSGFubmFAaW5maW5lb24uY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7OyBzZWNkaXJAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC5hbGxAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFJldmlldyBvZiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTkudHh0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgU3RldmUs PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKdW4gMjks IDIwMTgsIGF0IDM6MTIgUE0sIDxhIGhyZWY9Im1haWx0bzpTdGV2ZS5IYW5uYUBpbmZpbmVvbi5j b20iPg0KU3RldmUuSGFubmFAaW5maW5lb24uY29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3Vt ZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3M8YnI+DQpvbmdvaW5nIGVm Zm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGU8 YnI+DQpJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUg YmVuZWZpdCBvZiB0aGU8YnI+DQpzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRp dG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdDxicj4NCnRoZXNlIGNvbW1lbnRzIGp1c3Qg bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxicj4NCjxicj4NClRoZSBzdW1tYXJ5 IG9mIHRoZSByZXZpZXcgaXMgUmVhZHkgd2l0aCBpc3N1ZXMuPGJyPg0KPGJyPg0KVGhpcyBkb2N1 bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIGZvciBBQ0wuIFdoZW4gdGhlIHRlcm08YnI+ DQomcXVvdDtBQ0wmcXVvdDsgaXMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IGl0IG1lYW5zIHRoZSBz b3J0IG9mIEFDTCB0aGF0PGJyPg0KeW91IG1pZ2h0IHNlZSBpbiBmaXJld2FsbCBydWxlcyAoZS5n LiwgJnF1b3Q7ZHJvcCBJUHY0IHRyYWZmaWMgd2l0aDxicj4NCmRlc3RpbmF0aW9uIHBvcnQgMjEm cXVvdDspLjxicj4NCjxicj4NCipPdmVyYWxsIENsYXJpdHkgYW5kIFF1YWxpdHkqPGJyPg0KPGJy Pg0KVGhlIGRvY3VtZW50IGlzIGZhaXJseSBjbGVhciBhbmQgd2VsbCB3cml0dGVuLiBIb3dldmVy LCB0aGVyZTxicj4NCmlzIGEgY29uZnVzaW5nIHR5cG8gdGhhdCBpcyBsaXN0ZWQgaW4gdGhlIE1p bm9yIEVycm9ycyBzZWN0aW9uPGJyPg0Kb2YgdGhpcyByZXZpZXcuPGJyPg0KPGJyPg0KKlNlY3Vy aXR5IEFuYWx5c2lzKjxicj4NCjxicj4NClRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0 aW9uIGlzIGJyaWVmIGJ1dCBkZWNlbnQuPGJyPg0KSG93ZXZlciwgdGhlIGxhc3QgdHdvIHNlbnRl bmNlcyBhcmUgdW5jbGVhciBhbmQgbWF5YmUgd3Jvbmc6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7 VW5hdXRob3JpemVkIHdyaXRlIGFjY2VzcyB0byB0aGlzIGxpc3QgY2FuIGFsbG93IGludHJ1ZGVy czxicj4NCiZuYnNwOyZuYnNwO3RvIGFjY2VzcyBhbmQgY29udHJvbCB0aGUgc3lzdGVtLiBVbmF1 dGhvcml6ZWQgcmVhZCBhY2Nlc3M8YnI+DQombmJzcDsmbmJzcDt0byB0aGlzIGxpc3QgY2FuIGFs bG93IGludHJ1ZGVycyB0byBzcG9vZiBwYWNrZXRzIHdpdGg8YnI+DQombmJzcDsmbmJzcDthdXRo b3JpemVkIGFkZHJlc3NlcyB0aGVyZWJ5IGNvbXByb21pc2luZyB0aGUgc3lzdGVtLjxicj4NCjxi cj4NCldoaWNoICZxdW90O3N5c3RlbSZxdW90OyBpcyByZWZlcnJlZCB0byBoZXJlPyBXaGF0ZXZl ciB0aGUgYW5zd2VyIHRvPGJyPg0KdGhhdCBxdWVzdGlvbiwgSSBiZWxpZXZlIHRoYXQgdGhlIG1h aW4gaW1wYWN0IG9mIHVuYXV0aG9yaXplZDxicj4NCndyaXRlIGFjY2VzcyB0byB0aGUgQUNMIGlz IHRoYXQgdGhlIGF0dGFja2VyIGNhbiBtb2RpZnkgdGhlPGJyPg0KQUNMIHRvIHBlcm1pdCB0cmFm ZmljIHRoYXQgc2hvdWxkIG5vdCBiZSBwZXJtaXR0ZWQgb3IgZGVueTxicj4NCnRyYWZmaWMgdGhh dCBzaG91bGQgYmUgcGVybWl0dGVkLiBUaGUgZm9ybWVyIG1heSByZXN1bHQgaW48YnI+DQpkZW5p YWwgb2Ygc2VydmljZSBvciBjb21wcm9taXNlIG9mIHN5c3RlbXMgb24gdGhlIG5ldHdvcmsuPGJy Pg0KVGhlIGxhdHRlciBtYXkgcmVzdWx0IGluIGRlbmlhbCBvZiBzZXJ2aWNlLiBUaGUgbWFpbiBp bXBhY3Q8YnI+DQpvZiB1bmF1dGhvcml6ZWQgcmVhZCBhY2Nlc3MgdG8gdGhlIEFDTCBpcyB0aGF0 IHRoZSBhdHRhY2tlcjxicj4NCmNhbiBkZXRlcm1pbmUgd2hhdCBBQ0wgcnVsZXMgYXJlIGluIGVm ZmVjdCBhbmQgbWF5IGJlIGFibGU8YnI+DQp0byB1c2UgdGhpcyBpbmZvcm1hdGlvbiB0byBiZXR0 ZXIgY3JhZnQgYW4gYXR0YWNrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2suIEhvdyBhYm91dCB0aGlzPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PTEQ6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6IHBh Z2U7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO29ycGhhbnM6IDI7d2lkb3dzOiAyIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgL2FjbHMvYWNsL2FjZXM6IFRoaXMgbGlzdCBz cGVjaWZpZXMgYWxsIHRoZSBjb25maWd1cmVkIGFjY2VzczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb250cm9sIGVudHJpZXMgb24gdGhlIGRl dmljZS4mbmJzcDsgVW5hdXRob3JpemVkIHdyaXRlIGFjY2VzcyB0byB0aGlzPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpc3QgY2FuIGFsbG93 IGludHJ1ZGVycyB0byBhY2Nlc3MgYW5kIGNvbnRyb2wgdGhlIHN5c3RlbS48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVW5hdXRob3JpemVkIHJl YWQgYWNjZXNzIHRvIHRoaXMgbGlzdCBjYW4gYWxsb3cgaW50cnVkZXJzIHRvIHNwb29mPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhY2tldHMg d2l0aCBhdXRob3JpemVkIGFkZHJlc3NlcyB0aGVyZWJ5IGNvbXByb21pc2luZyB0aGUgc3lzdGVt LjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TkVXOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7 PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi9hY2xzL2FjbC9hY2VzOiBUaGlzIGxpc3Qg c3BlY2lmaWVzIGFsbCB0aGUgY29uZmlndXJlZCBhY2Nlc3M8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTogcGFnZTtmb250LXZhcmlhbnQtbGln YXR1cmVzOiBub3JtYWw7b3JwaGFuczogMjt3aWRvd3M6IDIiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjb250cm9sIGVudHJpZXMgb24gdGhlIGRldmljZS4mbmJzcDsgVW5hdXRob3Jp emVkIHdyaXRlIGFjY2VzcyB0byB0aGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpc3QgY2FuIGFsbG93IGludHJ1ZGVycyB0byBtb2RpZnkg dGhlIGVudHJpZXMgc28gYXMgdG8gcGVybWl0IHRyYWZmaWM8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0iYnJlYWstYmVmb3JlOiBwYWdlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1h bDtvcnBoYW5zOiAyO3dpZG93czogMiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo YXQgc2hvdWxkIG5vdCBiZSBwZXJtaXR0ZWQsIG9yIGRlbnkgdHJhZmZpYyB0aGF0IHNob3VsZCBi ZSBwZXJtaXR0ZWQuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTog cGFnZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7b3JwaGFuczogMjt3aWRvd3M6IDIi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgZm9ybWVyIG1heSByZXN1bHQgaW4g YSBEb1MgYXR0YWNrLCBvciBjb21wcm9taXNlIHRoZSBkZXZpY2UuPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTogcGFnZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBu b3JtYWw7b3JwaGFuczogMjt3aWRvd3M6IDIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUaGUgbGF0dGVyIG1heSByZXN1bHQgaW4gYSBEb1MgYXR0YWNrLiBUaGUgaW1wYWN0IG9mIGFu IHVuYXV0aG9yaXplZCZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1i ZWZvcmU6IHBhZ2U7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO29ycGhhbnM6IDI7d2lk b3dzOiAyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVhZCBhY2Nlc3MgdG8gdGhl IGxpc3Qgd2lsbCBhbGxvdyB0aGUgYXR0YWNrZXIgdG8gZGV0ZXJtaW5lIHdoaWNoIHJ1bGVzPG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTogcGFnZTtmb250LXZhcmlh bnQtbGlnYXR1cmVzOiBub3JtYWw7b3JwaGFuczogMjt3aWRvd3M6IDIiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBhcmUgaW4gZWZmZWN0LCB0byBiZXR0ZXIgY3JhZnQgYW4gYXR0YWNr LjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQoqTWlub3IgRXJyb3JzKjxicj4NCjxicj4NClNlY3Rpb24gMyByZWZlcnMgdG8gJnF1 b3Q7YWN0aW9uIGNyaXRlcmlhJnF1b3Q7LiBFdmVyeSBvdGhlciBwYXJ0IG9mPGJyPg0KdGhlIHNw ZWNpZmljYXRpb24gcmVmZXJzIG9ubHkgdG8gJnF1b3Q7YWN0aW9uJnF1b3Q7IG9yICZxdW90O2Fj dGlvbnMmcXVvdDsuPGJyPg0KTXkgcmV2aWV3IG9mIHRoZSBzcGVjaWZpY2F0aW9uIGluZGljYXRl cyB0aGF0IHRoaXMgdGV4dDxicj4NCmluIHNlY3Rpb24gMyBzaG91bGQgc2F5ICZxdW90O2FjdGlv bnMmcXVvdDsgbm90ICZxdW90O2FjdGlvbiBjcml0ZXJpYeKAnS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJl IGFyZSB0aHJlZSBpbnN0YW5jZXMgb2Yg4oCcYWN0aW9uIGNyaXRlcmlh4oCdIGluIHRoZSBkb2N1 bWVudC4gQnV0IHlvdSBwb2ludCBpcyB3ZWxsIHRha2VuLCB0aGV5IGNhbiBhbGwgYmUgY2hhbmdl ZCB0byDigJxhY3Rpb27igJ0gb3Ig4oCcYWN0aW9uc+KAnS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TWFoZXNoIEpldGhhbmFuZGFuaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRh bmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_d3791f64130a473eb6d3d65694ae817binfineoncom_-- From nobody Fri Jul 13 07:38:36 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5097F130E0E; Fri, 13 Jul 2018 07:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKcp26rz7WKq; Fri, 13 Jul 2018 07:38:34 -0700 (PDT) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A40129619; Fri, 13 Jul 2018 07:38:30 -0700 (PDT) Received: by mail-yw0-x242.google.com with SMTP id y203-v6so11800651ywd.9; Fri, 13 Jul 2018 07:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=7gw4lHbVBVHpRN0Yx+3ZSoSgkfuNMjoECxylqRXKfqs=; b=WMvw1BdsXHLEB5ieGUAZZTP3ax30XZPtqtHhaJ4m4FHF+VBgIylc4Luwx9+F364O3P uAzWlc7BI1Z9ya6g1kzNhM7Z9OwtUR1sYzg9M2ZIA64LNPzvm5n86llpRuyPb5dMfEp/ 3DiNEPs0pS6UbOflH00yy6UgbQVyu7wXR/rutgQVe8yzGcHi5j/+c/XB1+9+fNwm+ktT 5BQmCjZ4eerUDBQMHn+BnFyX0KMKnXQrZOKvODHoi/t/1S9KV9qpjNwZYwNCXhXns8TK 9Rd8bU3ggwKGJPLS34bZUkdicnmHTCooe3NqThB05ay1Bzh4RqqfMn8WK0iZ2mQuQsL9 ZDmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=7gw4lHbVBVHpRN0Yx+3ZSoSgkfuNMjoECxylqRXKfqs=; b=sX6KHrjozqXM9Cw2h6l0WB7Uya5Ui6S1PgM32gqryl4IyDuzfvxs7Ry40aoS+1wUj9 w9NRB+w+QhiGpr0fNdSVITSeruCyqfNYoaQ0wlIqjeYV0JNvXMCnkOOnuniNS2Ve4WIb q2UWI6tSw20cSCDCwA/Da020Nydkzrl5YEfynpSeJ6F74C1AjHOytsXTnOyCEBraKJ6o OgULYPYvjZF9LzIXlMZPAjj3PZZqigalXifyXiiwcaNsjLMd/IxEl4btUOACfYDGIuSd yPiotes/X3aYpxpShU4Hgx3XJjB/hwlnQcYEVHepCvARDhLeonMtBd+e9d0yWp/rjDLF tu+g== X-Gm-Message-State: AOUpUlHHSxM5QKV185ueGfilAaU2xzAmzM2mQti0NpR4aCEaCk2xYKT/ PTuFCgCzNE2qR0z2lRHzulG5qg== X-Google-Smtp-Source: AAOMgpdXgCqno4NhqHAAqzagNeh4jjjb3sx5Iq+W7knUWrrtrx3i0kQQyQt1j/T6E802O6slJ/IQ6A== X-Received: by 2002:a0d:db92:: with SMTP id d140-v6mr3387733ywe.213.1531492709994; Fri, 13 Jul 2018 07:38:29 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:98ec:3d3d:ff1f:48de]) by smtp.googlemail.com with ESMTPSA id m19-v6sm18498566ywd.90.2018.07.13.07.38.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jul 2018 07:38:29 -0700 (PDT) To: draft-ietf-extra-imap-objectid.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" From: Chris Lonvick Message-ID: <5B48B964.3010208@gmail.com> Date: Fri, 13 Jul 2018 09:38:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090407000705010200090600" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-extra-imap-objectid-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 14:38:35 -0000 This is a multi-part message in MIME format. --------------090407000705010200090600 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY with nits. I found the document to be understandable and thorough. The only nit I would call out is that the security considerations section should reference the security considerations section of RFC 3501, which it is updating. Perhaps an additional line such as: Implementers should be aware of and follow the advice provided in the security considerations section of RFC 3501. Regards, Chris --------------090407000705010200090600 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

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

The summary of the review is READY with nits.

I found the document to be understandable and thorough. The only nit I would call out is that the security considerations section should reference the security considerations section of RFC 3501, which it is updating. Perhaps an additional line such as:

Implementers should be aware of and follow the advice provided in the security considerations section of RFC 3501.

Regards,
Chris
--------------090407000705010200090600-- From nobody Sat Jul 14 06:57:20 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A10130DBE; Sat, 14 Jul 2018 06:57:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba To: Cc: ietf@ietf.org, draft-sahib-451-new-protocol-elements.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153157663246.12737.5786220541781133621@ietfa.amsl.com> Date: Sat, 14 Jul 2018 06:57:12 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-sahib-451-new-protocol-elements-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 13:57:13 -0000 Reviewer: Barry Leiba Review result: Has Issues I've already commented on this before being assigned the SecDir review, but I'll add further comment here. Basically, I object to handling this as an AD-sponsored Informational document, which updates a working group product that is Standards Track. I also object to complicating a protocol element that was intentionally devised as very simple. That said, I don't object to everything in the document, and if the 2119 key words were removed we could salvage things. Looking at the recommendations in Section 4: - I object to the first recommendation on the grounds that it makes no sense that I can determine, and whatever sense I do try to make of it seems wrong. If the legal demand is "don't return any information about pangalactic gargle-blasters (PGBs)," does that meet the specificity requirement for (1) the Wikipedia page on PGBs, (2) an Amazon listing for a PGB for purchase, (3) a blog post about "The "Hitchhiker's Guide to the Galaxy" that mentions intergalactic drinks, (4) *any* web page that has the string "pangalactic gargle-blaster" in it, regardless of the other content? If the legal demand is not to provide any content whatsoever to users outside the solar system, such that every request from Alpha Centauri gets a 451, why should we not use 451 for that? Please let's strike this recommendation. - The second recommendation is simply not necessary: RFC 7725 is clear on this, and if operators are doing otherwise there's no reason to think that a sentence in an Informational document will change anything. Let's please strike this one as well. - The third and fourth recommendations, and the link relation definition and header that go with them, are benign enough: we can see whether they get deployed or not. If we removed the "SHOULD"s and made it clear that this is suggested as a means to add more information, and is not part of the standard, I'd not object to registering them and including the recommendations. In Section 7.2, I suggest a change such as this: OLD HTTP 451 is used as a response when the client requests a resource that's unavailable because of legal reasons. Consequentially, there are potential privacy (and anonymity) ramifications if there is leakage of who accessed what resource. NEW With any HTTP request, there are potential privacy and anonymity ramifications if there is leakage of who accessed what resource. HTTP 451 is used as a response when the client requests a resource that's unavailable because of legal reasons. Consequentially, the privacy and anonymity ramifications may be even more significant. END I find Section 7.11 to be vague to the point of being content-free, and, therefore, pointless. In 7.14, the draft says, "Objective of this draft is to increase reliability by making it clearer what a good HTTP 451 response looks like." That looks like marketing, and, to my eyes, looks wrong, as well... or, at least, if that's the objective, I think the draft has failed here. I'd strike that sentence. (By the way, in general it's good to avoid referring to a document as "this draft", because that designation becomes obsolete if the draft becomes an RFC. Better to say "this document".) In 7.16, there's nothing specific about the 451 response code here. I guess you could say, "All HTTP transactions are susceptible to leakage unless they are protected by encryption, such as through the use of HTTPS." -- Barry From nobody Sat Jul 14 11:43:06 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A501130DC4 for ; Sat, 14 Jul 2018 11:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNyIZXp2SPom for ; Sat, 14 Jul 2018 11:43:03 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 C2BD6130DC2 for ; Sat, 14 Jul 2018 11:43:03 -0700 (PDT) X-AuditID: 12074423-6abff7000000076f-65-5b4a4436aa0d 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-6.mit.edu (Symantec Messaging Gateway) with SMTP id CD.15.01903.6344A4B5; Sat, 14 Jul 2018 14:43:02 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w6EIh1DK000400 for ; Sat, 14 Jul 2018 14:43:02 -0400 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w6EIgwCS025791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 14 Jul 2018 14:43:00 -0400 Date: Sat, 14 Jul 2018 13:42:58 -0500 From: Benjamin Kaduk To: secdir@ietf.org Message-ID: <20180714184255.GL59001@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPIsWRmVeSWpSXmKPExsUixCmqrGvm4hVt8LTT0OLDwocsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+LFmDmvBTsaKrjd3mBsYJzB2MXJySAiYSCxf8Iqpi5GLQ0hg MZPE3z2t7BDOcUaJxgcPoZzHTBJrvj9nAWlhEVCVaPv8lQ3EZhNQkWjovswMYosICEvcPviA FcQWFtCSmL7uA1g9r4COxIZ7T5kgbEGJkzOfgMWZgWpu/HsJFOcAsqUllv/jAAmLCihL7O07 xD6BkXcWko5ZSDpmIXQsYGRexSibklulm5uYmVOcmqxbnJyYl5dapGuml5tZopeaUrqJERRK 7C7KOxhf9nkfYhTgYFTi4a2w8YoWYk0sK67MPcQoycGkJMp7WQgoxJeUn1KZkVicEV9UmpNa fIhRgoNZSYR3lThQjjclsbIqtSgfJiXNwaIkzpuziDFaSCA9sSQ1OzW1ILUIJivDwaEkwdvp DNQoWJSanlqRlplTgpBm4uAEGc4DNDwIpIa3uCAxtzgzHSJ/itGY49u1rknMHH/eT53ELMSS l5+XKiXOu8AJqFQApDSjNA9uGigdSGTvr3nFKA70nDDvepCBPMBUAjfvFdAqJqBVeh2eIKtK EhFSUg2M6mq39ogv/Nl8oHz63/evTFVKeiLfvPnD3rbWXO/+bSvPehHuDslAScMFPwwb9+Ve EnabffzpijmTc74YfQpmmPuUu/grX2v8vAN7fHfNcFF0W+gVobx467X1h9Y9nSY2+8SM9/bu b8uvm6b9YK5SWiTbHRTs+nbRgkPpy45uMai/8u7G2ySbX0osxRmJhlrMRcWJADRsgdbiAgAA Archived-At: Subject: [secdir] secdir lunch in Square Dorchester X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 18:43:05 -0000 Hi folks, We have the room Square Dorchester reserved for the regular Tuesday secdir lunch. Unfortunately, I will not be able to attend, so Ekr will be running the show. -Ben From nobody Mon Jul 16 03:42:41 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447B3130FEC; Mon, 16 Jul 2018 03:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzxWeTXba4Ta; Mon, 16 Jul 2018 03:42:29 -0700 (PDT) Received: from anna.localdomain (anna.eecs.jacobs-university.de [IPv6:2001:638:709:5::7]) by ietfa.amsl.com (Postfix) with ESMTP id B259B130FE9; Mon, 16 Jul 2018 03:42:29 -0700 (PDT) Received: by anna.localdomain (Postfix, from userid 501) id 41650233FEEE; Mon, 16 Jul 2018 12:42:25 +0200 (CEST) Date: Mon, 16 Jul 2018 12:42:25 +0200 From: Juergen Schoenwaelder To: Mahesh Jethanandani Cc: Daniel Harkins , Kent Watsen , The IESG , "secdir@ietf.org" , "draft-ietf-netconf-nmda-restconf.all@ietf.org" Message-ID: <20180716104225.hlg3r3x62q4ipq2x@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Mahesh Jethanandani , Daniel Harkins , Kent Watsen , The IESG , "secdir@ietf.org" , "draft-ietf-netconf-nmda-restconf.all@ietf.org" References: <20180704124128.qpr7tunjw5quiex6@anna.jacobs.jacobs-university.de> <9b2f8091-9ead-e188-ee34-1acfead2dcd2@lounge.org> <20180704183436.zjzwz4vowqi5phz7@anna.jacobs.jacobs-university.de> <14e7ae2d-90ae-32c5-c814-a2d31e9f1a4e@lounge.org> <8dbe0263-de63-0ddd-86db-04fa7744155c@lounge.org> <99EB8497-BCC0-45A3-A412-6FC5036243F6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <99EB8497-BCC0-45A3-A412-6FC5036243F6@gmail.com> User-Agent: NeoMutt/20180622 Archived-At: Subject: Re: [secdir] review of draft-ietf-netconf-nmda-restconf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 10:42:33 -0000 On Mon, Jul 09, 2018 at 05:48:53PM -0700, Mahesh Jethanandani wrote: > There have been a few comments that have been made to the version of the draft that has been submitted to IESG. While we wait for other comments to be provided, and direction of when an update should be provided, who amongst the authors is updating GitHub with these changes? > > I am concerned we might lose track of the changes that need to be made. > > Here are the changes that I am aware of for nmda-restconf. I can compile a similar list for nmda-netconf if needed. Having a list of outstanding edits for nmda-netconf would be nice as well so we can make the edits on github. > Kent’s comment on nmda-restconf operations (thread from today). Given that lock and unlock require session semantics, I think the resolution should be to add. A RESTCONF server supporting NMDA datastores MAY implement the "ietf-netconf-nmda" [I-D. ietf-netconf-nmda-netconf] module to enable the NETCONF operations defined in this draft to appear under the {+restconf}/operations resource. But then, what is the value of this? You do not need get-data and edit-data with RESTCONF since you can send GET/POST/PATCH straight to the datastore resources. I guess I am still unclear which problem we are trying to solve by adding this (or a similar) statement. > Dan’s comment on this thread (also from today, but is not on netconf mailing list) Not sure which one you mean. > Russ’s Genart review (thread from June 28) Not sure what the resolution is, removing the example text or trying to better explain that this is example text. > Rohit’s change-2 comments provided for nmda-netconf, that are applicable for nmda-restconf (thread from June 1) The inclusion of an example showing the usage of negated-origin-filter? This was an nmda netconf command. We do not seem to have an origin filter in nmda restconf, this is an nmda netconf only feature? > Anything else that I missing? Not that I recall. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jul 17 03:30:53 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427BD130EB4; Tue, 17 Jul 2018 03:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sys-fL4l8llr; Tue, 17 Jul 2018 03:30:45 -0700 (PDT) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.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 88F07130DE9; Tue, 17 Jul 2018 03:30:44 -0700 (PDT) Received: from [46.226.52.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-a.eu-west-1.aws.symcld.net id 82/1D-10350-255CD4B5; Tue, 17 Jul 2018 10:30:42 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBKsWRWlGSWpSXmKPExsWi75nTpRt41Df aYOs/S4vWvk1MFs82zmexmH//GZPFgt6tzBYfFj5kcWD1WLLkJ5PH3k197AFMUayZeUn5FQms Gbtnr2Qv+CBU0XbTsIHxglAXIxeHkMB2RomLp/6zQDiHGSVaP/QydjFyAjlHGCWOH9KHSGxhl Jh+bzFQFQcHm4C9xIw9MSCmiICHxI8j5iAlzAJrGSWal/0G6xUW8Jb4sugXE4gtIuAjcfzLAS jbSKKhdz7YGBYBVYm5ZxVAwrwCoRKNr1ewQqx1kmg8+hbM5hRwlli19wQ7iM0oICvxpXE1M4j NLCAucevJfLCREgICEkv2nGeGsEUlXj7+xwoynllAU2L9Ln2IckWJKd0P2SFWCUqcnPmEBWKV qsS/lYuYJjCKzUIydRZC9ywk3bOQdC9gZFnFaJFUlJmeUZKbmJmja2hgoGtoaKRraGmsa2hsq ZdYpZuol1qqW55aXKJrqJdYXqxXXJmbnJOil5dasokRGJMMQLCD8dK35EOMkhxMSqK8vNW+0U J8SfkplRmJxRnxRaU5qcWHGGU4OJQkeAOPAOUEi1LTUyvSMnOAyQEmLcHBoyTCmwmS5i0uSMw tzkyHSJ1itOT4837qJGaOfd3TgOQdECnEkpeflyolzisF0iAA0pBRmgc3DpbALjHKSgnzMgId KMRTkFqUm1mCKv+KUZyDUUmYtxVkCk9mXgnc1ldABzEBHSRdDXZQSSJCSqqB0X6Hq4bLaqe9l SGfpeu/F5qxidzmb8k5vkaw3MnumlCx426Hqh2JoUvKY5L5GXxi+r6umeu1NPYj8+fVov2lRj aTLTq/eeUky6ke2X1QbOviPreFMsahSz5bb9aJT+2KvbFVc4+xFkdf5yueSTYzTp7I8P8Wf/T AMutM84WLYvYpzXi2JrxbiaU4I9FQi7moOBEAZRwvdlsDAAA= X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-3.tower-265.messagelabs.com!1531823439!5203838!9 X-Originating-IP: [47.73.108.138] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21239 invoked from network); 17 Jul 2018 10:30:41 -0000 Received: from vgdpm12vr.vodafone.com (HELO voxe06hw.internal.vodafone.com) (47.73.108.138) by server-3.tower-265.messagelabs.com with AES256-SHA256 encrypted SMTP; 17 Jul 2018 10:30:41 -0000 Received: from VOEXH07W.internal.vodafone.com (47.73.211.205) by edge1.vodafone.com (195.232.244.51) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 17 Jul 2018 12:30:35 +0200 Received: from VOEXC01W.internal.vodafone.com (145.230.101.21) by VOEXH07W.internal.vodafone.com (47.73.211.205) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 17 Jul 2018 12:30:34 +0200 Received: from AVOEXH03W.internal.vodafone.com (145.230.15.141) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 17 Jul 2018 12:30:33 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.229]) by AVOEXH03W.internal.vodafone.com ([145.230.15.141]) with mapi id 14.03.0361.001; Tue, 17 Jul 2018 12:30:32 +0200 From: "Dawes, Peter, Vodafone Group" To: Leif Johansson , "secdir@ietf.org" CC: "draft-ietf-insipid-logme-marking.all@ietf.org" , "insipid@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-insipid-logme-marking-11 Thread-Index: AQHUF5e6fr7JOcukTkaupAzeB2v15qSTQUZA Date: Tue, 17 Jul 2018 10:30:32 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E323C15C@VOEXM31W.internal.vodafone.com> References: <153114934615.5366.9894430842150985630@ietfa.amsl.com> In-Reply-To: <153114934615.5366.9894430842150985630@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-insipid-logme-marking-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 10:30:48 -0000 SGVsbG8gTGVpZiwNClRoYW5rcyBhIGxvdCBmb3IgcmV2aWV3aW5nIHRoZSBkcmFmdC4gV2UgaGF2 ZSBzdWJtaXR0ZWQgcmV2aXNpb24gLTEyIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWluc2lwaWQtbG9nbWUtbWFya2luZy8pIHdoaWNoIG1ha2VzIHRoZSAibXVz dCIgbm9ybWF0aXZlIGluIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgOC40LjYgVXNlciBDb250cm9s IG9mIExvZ2dpbmcsIGFzIHBlciB0aGUgcmV2aWV3IGNvbW1lbnQuDQoNCjguNC42LiAgVXNlciBD b250cm9sIG9mIExvZ2dpbmcNCkNvbnNlbnQgdG8gdHVybiBvbiAibG9nIG1lIiBtYXJraW5nIGZv ciBhIGdpdmVuIHNlc3Npb24gTVVTVCBiZQ0KcHJvdmlkZWQgYnkgdGhlIGVuZCB1c2VyIG9yIGJ5 IHRoZSBuZXR3b3JrIGFkbWluaXN0cmF0b3IuDQoNCg0KQmVzdCByZWdhcmRzLA0KUGV0ZXIgYW5k IEFydW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMZWlmIEpvaGFu c3NvbiA8bGVpZmpAc3VuZXQuc2U+DQo+IFNlbnQ6IDA5IEp1bHkgMjAxOCAxNjoxNg0KPiBUbzog c2VjZGlyQGlldGYub3JnDQo+IENjOiBkcmFmdC1pZXRmLWluc2lwaWQtbG9nbWUtbWFya2luZy5h bGxAaWV0Zi5vcmc7IGluc2lwaWRAaWV0Zi5vcmc7DQo+IGlldGZAaWV0Zi5vcmcNCj4gU3ViamVj dDogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pbnNpcGlkLWxvZ21lLW1h cmtpbmctMTENCj4gDQo+IFJldmlld2VyOiBMZWlmIEpvaGFuc3Nvbg0KPiBSZXZpZXcgcmVzdWx0 OiBSZWFkeQ0KPiANCj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0 aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nDQo+IGVmZm9ydCB0byByZXZpZXcgYWxs IElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlDQo+IGNv bW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1 cml0eSBhcmVhDQo+IGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBz aG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMNCj4ganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNh bGwgY29tbWVudHMuDQo+IA0KPiA+RnJvbSB0aGUgYWJzdHJhY3Q6IFRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIGFuIGluZGljYXRvciBmb3IgdGhlIFNJUA0KPiBwcm90b2NvbCB3aGljaCBjYW4gYmUg dXNlZCB0byBtYXJrIHNpZ25hbGluZyBhcyBiZWluZyBvZiBpbnRlcmVzdCB0byBsb2dnaW5nLg0K PiANCj4gVGhlIGRvY3VtZW50IGlzIGNsZWFybHkgd3JpdHRlbiBhbmQgZmVlbHMgcmVhZHkgZm9y IHB1YmxpY2F0aW9uIGZyb20gYSBxdWFsaXR5DQo+IHN0YW5kcG9pbnQuDQo+IA0KPiBNeSBvbmx5 IGlzc3VlIGlzIGluIDcuNC42IC0gVXNlciBDb250cm9sIG9mIExvZ2dpbmc6IFdoeSBpcyB0aGUg Im11c3QiDQo+IGluIHRoZSBmaXJzdCBwYXJhZ3JhcGggbm9uLW5vcm1hdGl2ZT8gSXMgaXQgYmVj YXVzZSB0aGVyZSBpcyBubyB3YXkgdG8gcHJvdmUNCj4gdGhlIGV4aXN0ZW5jZSBvciBhYnNlbmNl IG9mIHVzZXIgY29uc2VudD8gSSByZWFsaXplIHRoaXMgbWF5IGJlIGEgaGFyZA0KPiBwcm9ibGVt IHRvIHNvbHZlIGJ1dCBpZiB0aGlzIGlzc3VlIHdhcyBjb25zaWRlcmVkIGFuZCByZWplY3RlZCBp dCBtaWdodCBiZQ0KPiB3b3J0aCBpbmNsdWRpbmcgYSBkaXNjdXNzaW9uIGFib3V0IHRoaXMgaW4g dGhlIGRvY3VtZW50Lg0KPiANCg0K From nobody Tue Jul 17 06:15:57 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8572130E79; Tue, 17 Jul 2018 06:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHF-mAxjYyG5; Tue, 17 Jul 2018 06:15:48 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6670E130F75; Tue, 17 Jul 2018 06:15:45 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 188-v6so1781876ita.5; Tue, 17 Jul 2018 06:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=lx7A8KPDH+gvQ4RI6kGKzjaZWkY/LWZHMLXnOR3GMs4=; b=rx9If6VXZcafeGIBfz/VahW0VMdInIgzshTxjHfwVSXhJTcCAVSQ5KePzIBA7WhkXE eCxBQttUO3KzFdOxevbcnEP78hWZQkPNXkq9HrPExtsiH4h6R/ppKd3RONvyfsh9uX2z aslyKwn78ODSw2dcFYnw59SvmXtvyPdFM4hW3Dw0FAhXlDvihGojex4MsnJyGGato2+c Ba8rs26WjCBfIU66wSOXUFOCg53aFBBnUCgDj88xTCOKYBel/OtG292+ik2Ey2/sQ5jH p1mqy5nOaD6bD6CKvxl+KLKlZf9i8VR/l5Ujd/y0GcssI7YvxJnZ1H9oOcB1V4wtifb5 dw+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=lx7A8KPDH+gvQ4RI6kGKzjaZWkY/LWZHMLXnOR3GMs4=; b=Xoi5mPQhLg+uZFjgBBm4qVbypcRGosppctP6bEwAKS7KNTpCf+RNoEIebwaGpIJfte UJ8NRL+WkkSfrPqDo9L77VMZR5DWOtQLyDcSxRNp6Kj5DD9ZoIcIQb1/KtIQgaRcp61u VgDWc9F9qCpAmiRwswcdnp0ToxK5ApW6sJ0BqRZS5yzXZODRysD3B0zLk6FMLKooa1ej xvza9zlg79o4ZLttXADnYXEAIgr6NWJgFv3x0bNEYMJaB/RLMvqQnuoC6GKvxrc6XlRl ovYz089EIPd+/IxeYyXM0ND/d4WKT2XDvOR8glv4pMg8o6ofHKhtEwoEPcGi+s7Ng4/Z A/rQ== X-Gm-Message-State: AOUpUlGA1nKQVDM3bYqRmvsJT0UJphOBhnrlt4w/vmkB5XfuBP2OJ+F7 CPUYod6j48Od4P6+vadgQdiTtpBOGnYv69SjJhTRn+nV X-Google-Smtp-Source: AAOMgpcK83fdIZRT2JX7RRYjAcdHKgaQoJjL6uuZhxFRaV6pZX/D2+XAdWdIaLSqpOgwbTfC8sQyKMiCqHYxwb8TrJo= X-Received: by 2002:a24:1155:: with SMTP id 82-v6mr1425213itf.59.1531833344474; Tue, 17 Jul 2018 06:15:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bf84:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 06:15:28 -0700 (PDT) From: Donald Eastlake Date: Tue, 17 Jul 2018 09:15:28 -0400 Message-ID: To: draft-ietf-mptcp-rfc6824bis.all@ietf.org Cc: secdir@ietf.org, "iesg@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005a43dd057131bea0" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-mptcp-rfc6824bis-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 13:15:55 -0000 --0000000000005a43dd057131bea0 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. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. This draft specified version 1 of Multipath TCP obsoleting version 0. The paths are identified by the 4-tuple of IP addresses and ports for each path. The services offered to applications are the same as TCP. The additional information needed for setting up and tearing down paths, synchronizing flows, etc., is communicated using TCP options. The Security Considerations section appears to be good and the security mechanisms adequate to achieve the documents goal of being as secure as TCP. There is a good if somewhat generalized Threat Analysis in RFC 6181 as well as an Architecture document in RFC 6182 that considers security aspects. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com --0000000000005a43dd057131bea0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security= directorate's ongoing effort to review all IETF documents being proces= sed by the=C2=A0
IESG.=C2=A0 Document editors and WG chairs shoul= d treat these comments just like any other last call comments.
The summary of the review is Ready.

T= his draft specified version 1 of Multipath TCP obsoleting version 0. The pa= ths are identified by the 4-tuple of IP addresses and ports for each path. = The services offered to applications are the same as TCP. The additional in= formation needed for setting up and tearing down paths, synchronizing flows= , etc., is communicated using TCP options.

The Sec= urity Considerations section appears to be good and the security mechanisms= adequate to achieve the documents goal of being as secure as TCP. There is= a good if somewhat generalized Threat Analysis in RFC 6181 as well as an A= rchitecture document in RFC 6182 that considers security aspects.=C2=A0

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=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (= cell)
=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.com
<= /div>
--0000000000005a43dd057131bea0-- From nobody Thu Jul 19 06:55:38 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A733E130F62 for ; Thu, 19 Jul 2018 06:55:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <153200852760.5412.12979780745674252689.idtracker@ietfa.amsl.com> Date: Thu, 19 Jul 2018 06:55:27 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 13:55:37 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-08-02 Reviewer LC end Draft Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-11 Phillip Hallam-Baker 2018-07-10 draft-ietf-codec-ambisonics-07 Chris Lonvick 2018-07-13 draft-ietf-extra-imap-objectid-05 Tina Tsou 2018-05-21 draft-ietf-v6ops-conditional-ras-05 Liang Xia R2018-02-26 draft-ietf-anima-autonomic-control-plane-16 Taylor Yu 2018-06-19 draft-ietf-regext-rdap-object-tag-04 Last calls: Reviewer LC end Draft John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-09 Daniel Franke 2018-06-28 draft-ietf-netconf-rfc7895bis-06 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Tobias Gondrom 2018-06-25 draft-ietf-6man-rfc6434-bis-09 Christian Huitema 2018-07-09 draft-ietf-netconf-nmda-netconf-06 Barry Leiba 2018-08-13 draft-york-p-charge-info-08 Chris Lonvick 2018-08-11 draft-mahesh-etsi-urn-03 David Mandelberg None draft-ietf-netconf-zerotouch-22 David Mandelberg 2018-08-03 draft-ietf-regext-allocation-token-08 Catherine Meadows 2018-07-30 draft-sahib-451-new-protocol-elements-02 Daniel Migault 2018-07-30 draft-ietf-core-object-security-13 Matthew Miller 2018-07-24 draft-ietf-tls-tls13-vectors-06 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Adam Montville Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk From nobody Thu Jul 19 10:01:55 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE727130E3C for ; Thu, 19 Jul 2018 10:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VztN5g0hLE5u for ; Thu, 19 Jul 2018 10:01:49 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 5C57B130E23 for ; Thu, 19 Jul 2018 10:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532019708; 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=Z4b1igGTgvo3q30bfV87yBl0xHBoosUlYcYS2VKC0o8=; b=JDcUMhVjAB66c4zRxgPJQ8dXsOpdGHicTQ5P1ERAIgLEAy2dmNv2ohBDjNUsnLqi X136jHN4IHzHLxL6Nw4ke1mzSS6xmDMtz9NgO8AIhKCKEq8Cw3ty7Ktq5h2yauf2 Ji8gyLWKB8+Rjf1YePKHGZJVBQOY57UV6+sqZiIVGS8=; X-AuditID: c618062d-bdbff70000004941-ee-5b50c3fba779 Received: from EUSASMB502.ericsson.se (Unknown_Domain [147.117.188.220]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 24.82.18753.BF3C05B5; Thu, 19 Jul 2018 19:01:48 +0200 (CEST) Received: from EUSASMB503.ericsson.se (147.117.188.221) by EUSASMB502.ericsson.se (147.117.188.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 19 Jul 2018 13:01:47 -0400 Received: from EUSASMB503.ericsson.se ([147.117.188.239]) by EUSASMB503.ericsson.se ([147.117.188.239]) with mapi id 15.01.1466.003; Thu, 19 Jul 2018 13:01:47 -0400 From: Daniel Migault To: "secdir-secretary@mit.edu" , "secdir@ietf.org" Thread-Topic: [secdir] Assignments Thread-Index: AQHUH2g2NAVuRc1mjEezO5Ns75uIwqSWvh7Q Date: Thu, 19 Jul 2018 17:01:47 +0000 Message-ID: <63a17623fea04e37acb521fe37e36894@ericsson.com> References: <153200852760.5412.12979780745674252689.idtracker@ietfa.amsl.com> In-Reply-To: <153200852760.5412.12979780745674252689.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXTPHd0/hwOiDa7+YLO4Ovk+o8WHhQ9Z HJg8liz5yeTRdOYocwBTFJdNSmpOZllqkb5dAlfG7yf32QrOiFQ8eXeasYFxikAXIyeHhICJ xNb+2exdjFwcQgLHGCWWnlnADOH8YJQ4sv06E4SzglHi9NpNrCAtbAJGEm2H+tlBbBGBBInt /64zgtjCAooSc+82sHUxcgDFlST6D8ZClBhJ3LxynwnEZhFQlVi2aS8LiM0rYC2x+/IHNhBb SMBXYsXs72A2p4CfxKx/08HGMwqISXw/tQasl1lAXOLWk/lMEFcLSCzZc54ZwhaVePn4HyuE rSjx+fQNdoh6HYkFuz+xQdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGLk KC0uyMlNNzLYxAiMh2MSbLo7GO9P9zzEKMDBqMTDu3hzQLQQa2JZcWXuIUYJDmYlEd6CDUAh 3pTEyqrUovz4otKc1OJDjNIcLErivGc8eaOEBNITS1KzU1MLUotgskwcnFINjLsVbHY7RKVa pXis+2ib9umiipMF6+V/jxbXWm2W5GVndb1nMlFuz48G99mn5mTMlP766afpgp4oAbX6yIqU zaGhzbWrgzsfPEhP06+bK7k8zNWKw7ztQ5L1tfu/pi1cz79TQe1B7oWbqkoJ+yfI5uQW7Poc J21f5KjnZznvwfIIc5OFJ9dPVWIpzkg01GIuKk4EAEC/P8WDAgAA Archived-At: Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 17:01:53 -0000 Hi,=20 I have been assigned to review draft-ietf-core-object-security-13. As 3 of = the co-authors from Ericsson, I am wondering if there is not a conflict of= interest. Feel free to let me know if I should proceed to a review or if s= omeone else should be assigned.=20 Yours,=20 Daniel -----Original Message----- From: secdir On Behalf Of Tero Kivinen Sent: Thursday, July 19, 2018 9:55 AM To: secdir@ietf.org Subject: [secdir] Assignments Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-08-02 Reviewer LC end Draft Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-11 Phillip Hallam-Baker 2018-07-10 draft-ietf-codec-ambisonics-07 Chris Lonvick 2018-07-13 draft-ietf-extra-imap-objectid-05 Tina Tsou 2018-05-21 draft-ietf-v6ops-conditional-ras-05 Liang Xia R2018-02-26 draft-ietf-anima-autonomic-control-plane-= 16 Taylor Yu 2018-06-19 draft-ietf-regext-rdap-object-tag-04 Last calls: Reviewer LC end Draft John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-09 Daniel Franke 2018-06-28 draft-ietf-netconf-rfc7895bis-06 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Tobias Gondrom 2018-06-25 draft-ietf-6man-rfc6434-bis-09 Christian Huitema 2018-07-09 draft-ietf-netconf-nmda-netconf-06 Barry Leiba 2018-08-13 draft-york-p-charge-info-08 Chris Lonvick 2018-08-11 draft-mahesh-etsi-urn-03 David Mandelberg None draft-ietf-netconf-zerotouch-22 David Mandelberg 2018-08-03 draft-ietf-regext-allocation-token-08 Catherine Meadows 2018-07-30 draft-sahib-451-new-protocol-elements-02 Daniel Migault 2018-07-30 draft-ietf-core-object-security-13 Matthew Miller 2018-07-24 draft-ietf-tls-tls13-vectors-06 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-0= 0 Next in the reviewer rotation: Adam Montville Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk _______________________________________________ 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 Thu Jul 19 10:14:50 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26046130E23 for ; Thu, 19 Jul 2018 10:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0efWuOZnZNxm for ; Thu, 19 Jul 2018 10:14:47 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB36B130E80 for ; Thu, 19 Jul 2018 10:14:46 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id g141-v6so8575332ita.4 for ; Thu, 19 Jul 2018 10:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:sender:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=th+fQIuMeqqqLvUC/lNAxBQQgZ4hYmMQHHijcdP3sDk=; b=KXBraT6Fw2yE91sSZchNz7A9EZ7/5Iq363QY/OjCTwFPg8kEHMoZskFyKGGIPcuSAg nWDWfezYGpGg5U9hxK+EZhbuYzQpcX16iKLljZ7SATaX1nw6wYaaPPJQttBLhtsWTxQ/ qkbpvpShzIkN8nHAlmgQnIUtGt1jU8iU2a/xC4LoBwkgPMqa3yrGNj3Z7Visma/gkHRE M6K8Iwi2IBS0vuQ1kTyQSuNR5aRivY6EqJXjJ0z9NKncRI+MayQ8IDka7esKk4I1ygS8 5zeBWzUGOH+bsLkcNVY31r3UcQeh+D3ByogCdZ9SKLw7H6L+G8JCT9SUQj267Vlf+ERf VCRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:sender:in-reply-to :references:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=th+fQIuMeqqqLvUC/lNAxBQQgZ4hYmMQHHijcdP3sDk=; b=OENBJAopVVFDJjPjGd8Y5QCWaPTJSj74QEav5/10nIcL7yVLU7hgOwHI9QpSp0Ryuf drY3gWp5GpdNnfqHx3iufZ7nE+azY82jI3Suxy7FGOnEs+VVMHn5mbZOCghcPo8GdLVx Nck/xJLFEj1QjHGj+xEtJmkRtadQrB6X+1IqGljrJHnZhSSJXbszwhVNxp57Rf3ztXm8 fvcdIskCq6RmEzhCf2bbxxbnX4EgqKsh54UubrKcx+XIFQ6yi+GdQynoBiK5G2EUJJHH CJqkBLcifrCX/NngSEQA9jeuEzwlIIoNbhYZKWbnbBcWtfYTZADjJcWx+aJq1pJCI75z 7dOQ== X-Gm-Message-State: AOUpUlEkq2Up2qzJBzM25YkZM5pI7keDLnXt+8WYJrNtj/J2hTrjGnw0 KHpRCNpDt39R99vfQxx6xEiJ6R+WXbP7V13O/EY= X-Google-Smtp-Source: AAOMgpez2L3afM5Dhy4hlPXWhZitrUYofHfgggomgq/Up4RugqN2vMQ65zWcQARaM+MDASjod9se1c6FutgezP99dSk= X-Received: by 2002:a24:7910:: with SMTP id z16-v6mr6714362itc.15.1532020483662; Thu, 19 Jul 2018 10:14:43 -0700 (PDT) MIME-Version: 1.0 Reply-To: barryleiba@computer.org Sender: barryleiba@gmail.com Received: by 2002:ac0:8e88:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 10:14:43 -0700 (PDT) In-Reply-To: <63a17623fea04e37acb521fe37e36894@ericsson.com> References: <153200852760.5412.12979780745674252689.idtracker@ietfa.amsl.com> <63a17623fea04e37acb521fe37e36894@ericsson.com> From: Barry Leiba Date: Thu, 19 Jul 2018 13:14:43 -0400 X-Google-Sender-Auth: SOYNzVjyX7MEMrqw18Ef76dJAlw Message-ID: To: Daniel Migault Cc: "secdir-secretary@mit.edu" , "secdir@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 17:14:49 -0000 My opinion is that if you feel you can give it a fair review, go for it. If you think your review may be tainted, or that some in your company might "lean on you" if your review is critical, ask Tero to reassign it. I've always felt free to give my company's documents fair review, and I never saw it as an issue. Barry On Thu, Jul 19, 2018 at 1:01 PM, Daniel Migault wrote: > Hi, > > I have been assigned to review draft-ietf-core-object-security-13. As 3 o= f the co-authors from Ericsson, I am wondering if there is not a conflict = of interest. Feel free to let me know if I should proceed to a review or if= someone else should be assigned. > > Yours, > Daniel > > -----Original Message----- > From: secdir On Behalf Of Tero Kivinen > Sent: Thursday, July 19, 2018 9:55 AM > To: secdir@ietf.org > Subject: [secdir] Assignments > > Review instructions and related resources are at: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > For telechat 2018-08-02 > > Reviewer LC end Draft > Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-11 > Phillip Hallam-Baker 2018-07-10 draft-ietf-codec-ambisonics-07 > Chris Lonvick 2018-07-13 draft-ietf-extra-imap-objectid-05 > Tina Tsou 2018-05-21 draft-ietf-v6ops-conditional-ras-05 > Liang Xia R2018-02-26 draft-ietf-anima-autonomic-control-plan= e-16 > Taylor Yu 2018-06-19 draft-ietf-regext-rdap-object-tag-04 > > Last calls: > > Reviewer LC end Draft > John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-0= 9 > Daniel Franke 2018-06-28 draft-ietf-netconf-rfc7895bis-06 > Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 > Tobias Gondrom 2018-06-25 draft-ietf-6man-rfc6434-bis-09 > Christian Huitema 2018-07-09 draft-ietf-netconf-nmda-netconf-06 > Barry Leiba 2018-08-13 draft-york-p-charge-info-08 > Chris Lonvick 2018-08-11 draft-mahesh-etsi-urn-03 > David Mandelberg None draft-ietf-netconf-zerotouch-22 > David Mandelberg 2018-08-03 draft-ietf-regext-allocation-token-08 > Catherine Meadows 2018-07-30 draft-sahib-451-new-protocol-elements-0= 2 > Daniel Migault 2018-07-30 draft-ietf-core-object-security-13 > Matthew Miller 2018-07-24 draft-ietf-tls-tls13-vectors-06 > Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 > Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 > > Early review requests: > > Reviewer Due Draft > Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains= -00 > > Next in the reviewer rotation: > > Adam Montville > Kathleen Moriarty > Russ Mundy > Sandra Murphy > Yoav Nir > Magnus Nystrom > Hilarie Orman > Radia Perlman > Derrell Piper > Tim Polk > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --=20 Barry --=20 Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ http://staringatemptypages.blogspot.com/ From nobody Thu Jul 19 10:29:11 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB091310F7; Thu, 19 Jul 2018 10:29:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba To: Cc: ietf@ietf.org, draft-york-p-charge-info.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153202134048.10604.10229293446561018185@ietfa.amsl.com> Date: Thu, 19 Jul 2018 10:29:00 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-york-p-charge-info-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 17:29:05 -0000 Reviewer: Barry Leiba Review result: Ready This document appears to carefully document existing usage, and I no issues with the document. I might have preferred to see it published in the Independent Stream, as it's not reflecting IETF work, but seeing as it's where it is there's no point in rerouting it now. Ready to go as is.... Barry From nobody Sat Jul 21 14:25:44 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541FF12426A; Sat, 21 Jul 2018 14:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-FEVRBElpkm; Sat, 21 Jul 2018 14:25:34 -0700 (PDT) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F22130E15; Sat, 21 Jul 2018 14:25:33 -0700 (PDT) Received: by mail-yw0-x242.google.com with SMTP id r3-v6so5580331ywc.5; Sat, 21 Jul 2018 14:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to; bh=oFIHQgzILqlTpZ0OriKaogCflE675eOiYs9pTwfqT0A=; b=byZPNi/HWRilrJenXKKsN0HYgjJ1ucq2s3Ts1b9SYq5atKTbuDYTu/xB3nGhfqABqO PPhE4bG/gAG3XkgUsg37dPUD4PFGasTEc52dMWT0p1SIBv6ybenxvwdoBIRcIMeTBnoN jV8FipLzoECjegfTWS4xJj49H0TqRQU+kCzRjqNkGQTmSjcGp3B8fwz9l4MB3eMQWJlc a/IOu1hFrB7BdAO3W2Jn+DyH8/QXRBVAyCVN35TN699XtryzlxnYRCspKB+NH2nX64Zb ThlVK5u+lgCJw2hpltUfIhx56I7aOSzGhOq4UZ6HXoLPAOEJAz1c8SWZwVd9syu8V32X Ngig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to; bh=oFIHQgzILqlTpZ0OriKaogCflE675eOiYs9pTwfqT0A=; b=QUFaDGHK1TKycA0AwbpapHR3UOR/unwx+ZNXDT4RRsLAPQOHo6ouDna2Krg095ZUIr vE+Myuu21tf03NziMfCd5K5Z0yXAzdhS/QNpUJumLtEzcm+7Rk3qxEhnG22DvMybaalr mgJvLbyfRszrfcGpylKtrptrbiw289OBcmwimGUB5YewA8MdvWIhDAvUvHGWKf7kot2E 9OHOhfKDv5SovmovlZIgJH4crVZzVTEhzYepmj+DL9oM3SzJgTulfJda9k3ruXD8U8GQ 8bVOPsxGCxAB7SUhgDTdFuLLmUTiGgosb40E+pjWKlvySI1DW6NUfOd2X06DsmMnN/FK iDkA== X-Gm-Message-State: AOUpUlH1lEg/yD1TV3EZhzWwoA1HI2JCLIAXz60gtTe8+71Pb0Coy4I/ IY7y9TySDSgFpuUKydQwtZvcQUz5 X-Google-Smtp-Source: AAOMgpd/BFxOGa8eQD7O2U3MGOjkmkItNmWjQ4ZSSsprqIU5jr4A1jL1FA+B6wbrRHHOZZqsdtMzrg== X-Received: by 2002:a81:7a82:: with SMTP id v124-v6mr3714045ywc.149.1532208332786; Sat, 21 Jul 2018 14:25:32 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:405b:f9f:6372:d017]) by smtp.googlemail.com with ESMTPSA id t6-v6sm2560584ywe.81.2018.07.21.14.25.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jul 2018 14:25:32 -0700 (PDT) References: <1531858198.2510671.1444040480.5D771E87@webmail.messagingengine.com> To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-extra-imap-objectid.all@ietf.org From: Chris Lonvick X-Forwarded-Message-Id: <1531858198.2510671.1444040480.5D771E87@webmail.messagingengine.com> Message-ID: <5B53A4CA.1050109@gmail.com> Date: Sat, 21 Jul 2018 16:25:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1531858198.2510671.1444040480.5D771E87@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------040903070307050508050902" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-extra-imap-objectid-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 21:25:37 -0000 This is a multi-part message in MIME format. --------------040903070307050508050902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Bron, Thanks for the update. All looks good now. I have re-reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY. Thanks, Chris -------- Forwarded Message -------- Subject: new version of objectid draft uploaded Date: Wed, 18 Jul 2018 06:09:58 +1000 From: Bron Gondwana To: extra@ietf.org CC: Pete Resnick , Chris Lonvick , Alexey Melnikov Hi All, I've just uploaded draft-ietf-extra-imap-objectid-04, based on multiple reviews. Thanks to: Alexey (AD) Pete (GenArt) Chris (SecDir) Here's the set of changes: * described NIL THREADID in more detail (ad review) * made RFC5256 a normative reference (ad review) * fixed ABNF missing quote (ad review) * documented hash upgrade process (ad review) * referenced RFC3501 for INBOX rename (ad review) * referenced RFC3501 security considerations (secdir review) * turned mealy-mouthed "SHOULDs" in to "MUSTs" on immutability (genart review) * remove suggested algorithms which are no longer legitimate (genart review) * updated proxy advice to suggest rewriting ids (genart review) * fixed minor gramatical issues (genart review) * required that EMAILID and THREADID are not identical (own decision) ==== Of particular interest is that EMAILID and THREADID now MUST be different (just prefix them if they may otherwise clash!) and a whole lot of SHOULD turned into MUST. Everyone who's going to implement this already has stable storage for their IDs, and it means clients can really rely on these IDs. I would appreciate any further reviews! Thanks, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --------------040903070307050508050902 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Bron,

Thanks for the update. All looks good now.

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

The summary of the review is READY.

Thanks,
Chris

-------- Forwarded Message --------
Subject: new version of objectid draft uploaded
Date: Wed, 18 Jul 2018 06:09:58 +1000
From: Bron Gondwana <brong@fastmailteam.com>
To: extra@ietf.org
CC: Pete Resnick <presnick@qti.qualcomm.com>, Chris Lonvick <lonvick.ietf@gmail.com>, Alexey Melnikov <alexey.melnikov@isode.com>


Hi All,

I've just uploaded draft-ietf-extra-imap-objectid-04, based on multiple reviews.  Thanks to:

Alexey (AD)
Pete (GenArt)
Chris (SecDir)

Here's the set of changes:

* described NIL THREADID in more detail (ad review)
* made RFC5256 a normative reference (ad review)
* fixed ABNF missing quote (ad review)
* documented hash upgrade process (ad review)
* referenced RFC3501 for INBOX rename (ad review)
* referenced RFC3501 security considerations (secdir review)
* turned mealy-mouthed "SHOULDs" in to "MUSTs" on immutability (genart review)
* remove suggested algorithms which are no longer legitimate (genart review)
* updated proxy advice to suggest rewriting ids (genart review)
* fixed minor gramatical issues (genart review)
* required that EMAILID and THREADID are not identical (own decision)

====

Of particular interest is that EMAILID and THREADID now MUST be different (just prefix them if they may otherwise clash!) and a whole lot of SHOULD turned into MUST.  Everyone who's going to implement this already has stable storage for their IDs, and it means clients can really rely on these IDs.

I would appreciate any further reviews!

Thanks,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com




--------------040903070307050508050902-- From nobody Sun Jul 22 01:55:58 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2625A12872C; Sun, 22 Jul 2018 01:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb4QUHw7_sRU; Sun, 22 Jul 2018 01:55:49 -0700 (PDT) Received: from gondrom.org (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB8C1130E69; Sun, 22 Jul 2018 01:55:48 -0700 (PDT) Received: from seraph (60-249-114-118.HINET-IP.hinet.net [60.249.114.118]) by gondrom.org (Postfix) with ESMTPSA id 507C9642EC; Sun, 22 Jul 2018 10:55:41 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=nKNgq/xWcpkcTNVwcPEILNEtwFsJnMp0ZqhEU51Kr+qFvUrZ57gC/UgOpsNX/X/WrUN7AVpQjm5n4eOmwy01FMAAaCj1cwjthaq6i0wmXny2f5L4EaPX6Ta+HXEYDUzEwHOPUiwLfU5Er0TuqXUStqsaiuq9kRtIcsFy49NqiFw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; From: "Tobias Gondrom" To: , Cc: , , , , , , Date: Sun, 22 Jul 2018 16:55:35 +0800 Message-ID: <047701d42199$c67e8400$537b8c00$@gondrom.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0478_01D421DC.D4A43500" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdQhlQ5ntbyuUydiTQuODMgQHYbIfw== Content-Language: en-us Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-6man-rfc6434-bis-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 08:55:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0478_01D421DC.D4A43500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reviewer: Tobias Gondrom Review result: Ok 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. Overall the document is an update to RFC6434 and looks ok, ready to go. In my review, I did not find any material concerns with the document, and no nits. The security considerations are nearly identical to RFC6434 with the added paragraph in relation to IPv4 networking and reference to RFC7123, which is ok. From the overall new document text, it also is ok. Ready to release. Best regards, Tobias ------=_NextPart_000_0478_01D421DC.D4A43500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reviewer: Tobias Gondrom

Review result: Ok

 

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.

 

Overall the = document is an update to RFC6434 and looks ok, ready to go. =

In my review, I did not find any = material concerns with the document, and no nits.

The security considerations are nearly identical to = RFC6434 with the added paragraph in relation to IPv4 networking and = reference to RFC7123, which is ok. From the overall  new document = text, it also is ok.

 

Ready to = release.

 

Best regards, Tobias

 

 

------=_NextPart_000_0478_01D421DC.D4A43500-- From nobody Sun Jul 22 19:14:52 2018 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1531413109A; Sun, 22 Jul 2018 19:14:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia To: Cc: anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153231208604.23012.10077186169272862057@ietfa.amsl.com> Date: Sun, 22 Jul 2018 19:14:46 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-anima-autonomic-control-plane-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 02:14:46 -0000 Reviewer: Liang Xia Review result: Has Issues I have provided the secdir review on -13 of the draft. I have the same conclusion as before: this document is well-written and considers security issues carefully throughout the whole architecture. But I don't see your author's response to my -13 secdir review, so please double check you had addressed all my previous comments and nits. Besides above, I think the draft is ready. From nobody Mon Jul 23 14:16:32 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6C4130F63; Mon, 23 Jul 2018 14:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N42mQzEuFfA5; Mon, 23 Jul 2018 14:16:04 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD6C130E73; Mon, 23 Jul 2018 14:16:04 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id CC4FD58C4AF; Mon, 23 Jul 2018 23:15:59 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 954674402CB; Mon, 23 Jul 2018 23:15:59 +0200 (CEST) Date: Mon, 23 Jul 2018 23:15:59 +0200 From: Toerless Eckert To: Liang Xia Cc: secdir@ietf.org, anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org Message-ID: <20180723211559.f2u4ydl55ns5yhgo@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-anima-autonomic-control-plane-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 21:16:07 -0000 Hi Frank, Mea maxima culpa. Your -13 review below was probably overlooked by me when integrating all received feeedbac from -13 into 14/15/16, although it looks more as if i did fix most of the stuff from your review but then forgot to send a reply. This is integretated into -17, i didn't push a new version up, but you can check it at: https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-17.txt Replies inline below Cheers Toerless On Fri, Feb 23, 2018 at 07:28:05PM -0800, Liang Xia wrote: > Reviewer: Liang Xia > Review result: Has Issues > > In general, this document is well-written and considers security issues > carefully throughout the whole architecture. Thanks! > > nits: > Abstract: /or not misconfigured/or misconfigured/ Was fixed n -16. > the fifth paragraph of section 6.1: the last ")" is redundant, therefore can be > deleted Fixed. > some section titles don't comply the rule of starting from a capital letter Hmm.. checked -13 and -16 but could not find anything besides: (-16) A.3.3.2 mDNS and ... This starts with small letter because "mDNS" is a unique name with a lower letter, i think this is correct. If we're unsure, RFC editor would be best to resolve later on. (-16) Titles are all draft names and this section will be removed anyhow for RFC. > section 6.5 > /("IP security", see [RFC4301] and "Internet Key Exchange protocol version 2", > see [RFC7296] > /("IP security", see [RFC4301] and "Internet Key Exchange protocol version 2", > see [RFC7296])/ What change do you suggest, looks identical ? > suggestion: > all the Figures (e.g., Figure 1,2...) should have a title for explanation Done in -16. > section 2, please update the last paragraph to reference RFC8174 to indicate > that lowercase versions of the keywords are not normative Done in -16. > Section 11 (Security Considerations) Since section 9.2 has described the > self-protection properties of ACP well, it may be useful in this section to > mention them as a whole. Hmm.. Didn't want to reiterate too much text that is already written out in the document, but instead inserted a reference to section 9.2 into the security section. From nobody Mon Jul 23 18:02:48 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20357130FCB; Mon, 23 Jul 2018 18:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dS0Oepage4k; Mon, 23 Jul 2018 18:02:32 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75EF9130F82; Mon, 23 Jul 2018 18:02:29 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id s8-v6so1014075ybe.8; Mon, 23 Jul 2018 18:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=s1DyOckFRuoMdiu0oJyeLa2KBFrfM1QArCpf8i27zKE=; b=GO4j5hWa3Ifs2KNOFcbYSR3OZJpaTrOaiG5L/pcV8h4nUUMHlhHuky3/YhULSeNgvJ 5eMdBHkp3IYOPLivirA2kGjUBrTK4BvCLICj7rSit1UnpfKO7qDBvEP2xzFjg6ySv4I6 13D2FIi1K/G8hYop9ohgq+6CpJTz0An4ttn9J1qGkfw4CaH1ihB75aOQ4jL9QH6nplw6 76GeAmd7GfYCkYKro3A5G/PrJjTPZOAh9dqK58dARYefoW7XrEhTyuYKy9iA+xWTykH5 oykv6j4LXCWhTFoZe3a7ABQq+Zdxs5lphjNOgw2ZSUs1HTcKauobQ01/QlONOYwBMN3c NZww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=s1DyOckFRuoMdiu0oJyeLa2KBFrfM1QArCpf8i27zKE=; b=PLP8V98GvcGbLv+NU58oUvTgRg+1rrRk/F0UejMK1IdV4ChfguyUEI5VeeUWOCF3jU /YwvnFOWSpDN4DvZJd4rHchQx3S85mO3thyEzpWhavzuBY0LIW9sFLrj/VqDyR9yce7J XsOkGmVfbtA4No5Jo+SIiQRD7Lpz2rlNjRV8A+v2X3ScCpP+mLBHzIB8ckX2OcJO4Ce/ ioEJPU8SiyTgyk1cM1TWzrmLqo4eN6IDNVCp/BUKoUVXNHX5x0Z04oHnCVx+h4cdcqEh 8MQNULxCGCy+Xjv8hzNs+TYO+PgfTKUjB5i5DNCIoYLXHwGxW8bvvFR9hbeBZB6zwSGU 4MQA== X-Gm-Message-State: AOUpUlE3qkeeVO/VtTwHevfWCTErBHIyNd0XCuU58LkFDiRnKrUPQ4MT nk7XHJVXl6QIlXQbcJ0/HAR8vb6w X-Google-Smtp-Source: AAOMgpdJTNzbtRAO2Yc6A6bwxJXuoHxZQ3oQfTUqOR6VxYiEJI+fgC/P6Yv20uJweQO08b80xZQOqQ== X-Received: by 2002:a25:e6c6:: with SMTP id d189-v6mr8114809ybh.341.1532394148345; Mon, 23 Jul 2018 18:02:28 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:6089:f65:f180:8308]) by smtp.googlemail.com with ESMTPSA id r17-v6sm2712099ywa.36.2018.07.23.18.02.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jul 2018 18:02:28 -0700 (PDT) To: "secdir@ietf.org" , "iesg@ietf.org" , draft-mahesh-etsi-urn.all@ietf.org From: Chris Lonvick Message-ID: <5B567AA3.1010902@gmail.com> Date: Mon, 23 Jul 2018 20:02:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020400060008050500030703" Archived-At: Subject: [secdir] SECDIR review of draft-mahesh-etsi-urn-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 01:02:39 -0000 This is a multi-part message in MIME format. --------------020400060008050500030703 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with Issues. I am not that familiar with creating and maintaining URNs so please set me straight and move on if I'm off base here. Section 2, "URN Specification for ETSI" contains the following: "ETSI will manage resource classes using the "etsi" NID and will be the authority for managing resources and associated subsequent strings. ETSI will guarantee the uniqueness of the strings themselves, or it may permit secondary responsibility for certain defined resources." But then says: "ETSI may allow for use of experimental type values for testing purposes only. Note that using experimental types may create collision as multiple users may use the same values for different resources and specific strings." It looks like RFC 8141 gives guidance that experimental use of URN namespaces is to be done using RFC 6963 (URNs for "Examples".) RFC 8184 does not address establishing or using namespaces under the subsequent strings for experimental use, but I could see that the registered owner of the namespace could make a designation for that purpose. That being said, I think that the two statements above are in conflict in the document and should be clarified. Perhaps it would be better to reconstruct the second paragraph to say something like: "ETSI may allow for use of experimental type values for testing purposes only. Some experimentation may be controlled by ETSI within a subsequent string to ensure that there will be no namespace collisions among participants. Other experimentation may be controlled within a secondary namespace that may allow collisions, but this experimental use will be constrained. All other experimentation must follow the guidance set forth in RFC 6963." Just as a nit, the Security Considerations section should be revised as it seems to be a bit unclear. Current: There are no additional security considerations other than those described above, and are normally associated with the use and resolution of URNs in general, which are described in Function Requirements for URN [RFC1737 ], Uniform Resource Names (URNs) [RFC8141 ]. Suggested: There are no additional security considerations other than those described above, and_those_ normally associated with the use and resolution of URNs in general._These a__re generally_ described in Function_al_ Requirements for_Uniform Resource Names_ [RFC1737 ],_and_ Uniform Resource Names (URNs) [RFC8141 ]. Best regards, Chris --------------020400060008050500030703 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

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

The summary of the review is Ready with Issues.

I am not that familiar with creating and maintaining URNs so please set me straight and move on if I'm off base here.

Section 2, "URN Specification for ETSI" contains the following:

"ETSI will manage resource classes using the "etsi" NID and will be the authority for managing resources and associated subsequent strings. ETSI will guarantee the uniqueness of the strings themselves, or it may permit secondary responsibility for certain defined resources."

But then says:

"ETSI may allow for use of experimental type values for testing purposes only. Note that using experimental types may create collision as multiple users may use the same values for different resources and specific strings."

It looks like RFC 8141 gives guidance that experimental use of URN namespaces is to be done using RFC 6963 (URNs for "Examples".) RFC 8184 does not address establishing or using namespaces under the subsequent strings for experimental use, but I could see that the registered owner of the namespace could make a designation for that purpose. That being said, I think that the two statements above are in conflict in the document and should be clarified.

Perhaps it would be better to reconstruct the second paragraph to say something like:

"ETSI may allow for use of experimental type values for testing purposes only. Some experimentation may be controlled by ETSI within a subsequent string to ensure that there will be no namespace collisions among participants. Other experimentation may be controlled within a secondary namespace that may allow collisions, but this experimental use will be constrained. All other experimentation must follow the guidance set forth in RFC 6963."

Just as a nit, the Security Considerations section should be revised as it seems to be a bit unclear.
Current:
   There are no additional security considerations other than those
   described above, and are normally associated with the use and
   resolution of URNs in general, which are described in Function
   Requirements for URN [RFC1737], Uniform Resource Names (URNs)
   [RFC8141].

Suggested:
   There are no additional security considerations other than those
   described above, and those normally associated with the use and
   resolution of URNs in general. These are generally described in Functional
   Requirements for Uniform Resource Names [RFC1737], and Uniform Resource Names (URNs)
   [RFC8141].



Best regards,
Chris

--------------020400060008050500030703--


From nobody Tue Jul 24 14:37:57 2018
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6687130E8F; Tue, 24 Jul 2018 14:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4W2VZhLXASyp; Tue, 24 Jul 2018 14:37:53 -0700 (PDT)
Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BF1124C04; Tue, 24 Jul 2018 14:37:53 -0700 (PDT)
Received: by mail-pf1-x441.google.com with SMTP id k19-v6so1156206pfi.1; Tue, 24 Jul 2018 14:37:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CmHpisiEUdP66AhVBymW9343t7wUABBgwNu4RtgGS+0=; b=kU4stuEWh+AxHp/7kIKzwW79ubL3K2ig7J3oI6KmAIH7zToXkcVZ7t485ylY9sNdj1 aLbcgd6u0BU4f/zEH65rlU1YFmKvH4oFRhqKXIuP/w+uLWRRLkEtT2ZvMH7oGlpMNUEM PO+5xzXfeoUxGZX3kaySk8BFUrFMGxTo1a547v68QvaecFgnN/PK7n3M9LcweHD0m74a YVkH+H+IkLpgQ5/XTkkoi4onrE+TXsWC2/JYx4RlOoI4IHFdcjz09FCO47o1PDqdYJFZ uq4ZqMOaJlazqKrtfymIy6m0Kctu34sQWL8X8VbYBWwFDmlOvPMb/VoL4kuqBVDNB7QX bcaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CmHpisiEUdP66AhVBymW9343t7wUABBgwNu4RtgGS+0=; b=XS273WIBq8xCHpMTxbRrhNLXmJco3zCxY7SftV41TcMX11fFIj9CQymvU84wZLe1wB b3WyhvyPNmM184aiq9Izf4r7obdiHMMYKLvc4gNxFMAGTAOkZJ5Rga9NKPYmwCO2Jvgr joqQE6w9cjDEKBJPkQ+BpRxjSzq1VkRwMftAQ+L68RItCKoAk56J2hJOC5k7NOVeaH/F 9af8d4hSpR0EcELLVNhM0FSBejAnJMJIc9ZYZb+QkCnQV09x7WK/F7DwKI1R/pCWgqFx vqMhgIfQ/7dR5z/64yGPz1jqsnUB1CF33anXaZWZnFir2t9lLwEhQY5ytUU0pZsuRXrC N9xQ==
X-Gm-Message-State: AOUpUlGAc09RmmFV1ssagS3FxvKNKET7908s2ui0BRR8adjcodX0HEaj AJk42E7LLHtcWEPpTFqfYME=
X-Google-Smtp-Source: AAOMgpekxFFvdsEYYzyYdFA0F/FfcsootMINGsvzX9FDO9yeokllNGu2Jtezl6AWv3Z8aP2qmmezmw==
X-Received: by 2002:aa7:88d3:: with SMTP id p19-v6mr19371696pfo.160.1532468272581;  Tue, 24 Jul 2018 14:37:52 -0700 (PDT)
Received: from ?IPv6:2601:647:4700:1280:3596:f6c9:d32c:c4dd? ([2601:647:4700:1280:3596:f6c9:d32c:c4dd]) by smtp.gmail.com with ESMTPSA id d81-v6sm32015287pfj.122.2018.07.24.14.37.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jul 2018 14:37:51 -0700 (PDT)
From: Mahesh Jethanandani 
Message-Id: <52B57BE1-B92E-42C2-8F7F-815A7658A903@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F9081262-B1F5-4696-902E-301A5BBD912F"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Tue, 24 Jul 2018 14:37:50 -0700
In-Reply-To: <5B567AA3.1010902@gmail.com>
Cc: "secdir@ietf.org" , The IESG , draft-mahesh-etsi-urn.all@ietf.org
To: Chris Lonvick 
References: <5B567AA3.1010902@gmail.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: 
Subject: Re: [secdir] SECDIR review of draft-mahesh-etsi-urn-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jul 2018 21:37:56 -0000

--Apple-Mail=_F9081262-B1F5-4696-902E-301A5BBD912F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Chris,

> On Jul 23, 2018, at 6:02 PM, Chris Lonvick  =
wrote:
>=20
> Hi,
>=20
> I have reviewed this document as part of the security directorate's =
ongoing effort to review all IETF documents being processed by the IESG. =
These comments were written primarily for the benefit of the security =
area directors. Document editors and WG chairs should treat these =
comments just like any other last call comments.=20
>=20
> The summary of the review is Ready with Issues.
>=20
> I am not that familiar with creating and maintaining URNs so please =
set me straight and move on if I'm off base here.=20
>=20
> Section 2, "URN Specification for ETSI" contains the following:
>=20
> "ETSI will manage resource classes using the "etsi" NID and will be =
the authority for managing resources and associated subsequent strings. =
ETSI will guarantee the uniqueness of the strings themselves, or it may =
permit secondary responsibility for certain defined resources."=20
>=20
> But then says:
>=20
> "ETSI may allow for use of experimental type values for testing =
purposes only. Note that using experimental types may create collision =
as multiple users may use the same values for different resources and =
specific strings."
>=20
> It looks like RFC 8141 gives guidance that experimental use of URN =
namespaces is to be done using RFC 6963 (URNs for "Examples".) RFC 8184 =
does not address establishing or using namespaces under the subsequent =
strings for experimental use, but I could see that the registered owner =
of the namespace could make a designation for that purpose. That being =
said, I think that the two statements above are in conflict in the =
document and should be clarified.

Not necessarily.

RFC6963 says that there are three types of namespaces, formal, informal =
and experimental. What this draft is requesting for is the formal =
namespace. The RFC also says that experimental namespaces are by =
definition unregistered. That there is no issuing authority for =
experimental URNs. The owner of the NID therefore is not required to =
keep track of experimental namespaces.=20

>=20
> Perhaps it would be better to reconstruct the second paragraph to say =
something like:
>=20
> "ETSI may allow for use of experimental type values for testing =
purposes only. Some experimentation may be controlled by ETSI within a =
subsequent string to ensure that there will be no namespace collisions =
among participants. Other experimentation may be controlled within a =
secondary namespace that may allow collisions, but this experimental use =
will be constrained. All other experimentation must follow the guidance =
set forth in RFC 6963.=E2=80=9D

How about this?

OLD:

ETSI may allow for use of experimental type values for testing purposes =
only. Note that using experimental types may create collision as =
multiple users may use the same values for different resources and =
specific strings.

NEW:

ETSI may allow for use of experimental type values for testing purposes =
only. Note that using experimental types may create collision as =
multiple users may use the same values for different resources and =
specific strings. All experimentation must follow the guidance set forth =
in RFC 6963.

>=20
> Just as a nit, the Security Considerations section should be revised =
as it seems to be a bit unclear.
> Current:
>    There are no additional security considerations other than those
>    described above, and are normally associated with the use and
>    resolution of URNs in general, which are described in Function
>    Requirements for URN [RFC1737 =
], Uniform Resource Names (URNs)
>    [RFC8141 ].
>=20
> Suggested:
>    There are no additional security considerations other than those
>    described above, and those normally associated with the use and
>    resolution of URNs in general. These are generally described in =
Functional
>    Requirements for Uniform Resource Names [RFC1737 =
], and Uniform Resource Names =
(URNs)
>    [RFC8141 ].

Ok.

Thanks.

>=20
> Best regards, Chris

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_F9081262-B1F5-4696-902E-301A5BBD912F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Chris,

On Jul 23, 2018, at 6:02 PM, Chris Lonvick =
<lonvick.ietf@gmail.com> wrote:


 =20

    
 =20
  

    Hi,

    

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

    

    The summary of the review is Ready with Issues.

    

    I am not that familiar with creating and maintaining URNs so please
    set me straight and move on if I'm off base here. 

    

    Section 2, "URN Specification for ETSI" contains the following:

    

    "ETSI will manage resource classes using the "etsi" NID and will be
    the authority for managing resources and associated subsequent
    strings. ETSI will guarantee the uniqueness of the strings
    themselves, or it may permit secondary responsibility for certain
    defined resources."
    
    
    
    

    

    But then says:

    

    
    "ETSI may allow for use of experimental type values for testing
    purposes only. Note that using experimental types may create
    collision as multiple users may use the same values for different
    resources and specific strings."

    

    It looks like RFC
    
    8141 gives guidance that experimental use of URN namespaces is to be
    done using RFC 6963 (URNs for "Examples".) RFC 8184 does not address
    establishing or using namespaces under the subsequent strings for
    experimental use, but I could see that the registered owner of the
    namespace could make a designation for that purpose. That being
    said, I think that the two statements above are in conflict in the
    document and should be clarified.

Not =
necessarily.

RFC6963 says that there =
are three types of namespaces, formal, informal and experimental. What =
this draft is requesting for is the formal namespace. The RFC also says =
that experimental namespaces are by definition unregistered. That there =
is no issuing authority for experimental URNs. The owner of the NID =
therefore is not required to keep track of experimental =
namespaces. 


    

    Perhaps it would be better to reconstruct the second paragraph to
    say something like:

    

    "ETSI may allow for use of experimental type values for testing
    purposes only. Some experimentation may be controlled by ETSI within
    a subsequent string to ensure that there will be no namespace
    collisions among participants. Other experimentation may be
    controlled within a secondary namespace that may allow collisions,
    but this experimental use will be constrained. All other
    experimentation must follow the guidance set forth in RFC =
6963.=E2=80=9D

How =
about this?

OLD:

ETSI may allow for use of experimental type values for =
testing purposes only. Note that using experimental types may create =
collision as multiple users may use the same values for different =
resources and specific strings.

NEW:

ETSI may =
allow for use of experimental type values for testing purposes only. =
Note that using experimental types may create collision as multiple =
users may use the same values for different resources and specific =
strings. All experimentation must follow the guidance set forth in RFC =
6963.


    

    Just as a nit, the Security Considerations section should be revised
    as it seems to be a bit unclear.

    Current:

    
    
   There are no additional security =
considerations other than those
   described above, and are normally associated with the use and
   resolution of URNs in general, which are described in Function
   Requirements for URN [RFC1737], Uniform Resource Names (URNs)
   [RFC8141].

Suggested:
   There are no additional security =
considerations other than those
   described above, and those normally associated with =
the use and
   resolution of URNs in general. These are generally described in Functional
   Requirements for Uniform Resource Names [RFC1737], =
and Uniform Resource Names (URNs)
   [RFC8141].

Ok.

Thanks.




Best regards,
Chris




Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_F9081262-B1F5-4696-902E-301A5BBD912F--


From nobody Tue Jul 24 16:20:40 2018
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B991311DD for ; Tue, 24 Jul 2018 16:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTyRYtVLQNCf for ; Tue, 24 Jul 2018 16:20:24 -0700 (PDT)
Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD621311F8 for ; Tue, 24 Jul 2018 16:20:22 -0700 (PDT)
X_CMAE_Category: , ,
X-CNFS-Analysis: v=2.2 cv=e9pEcuh/ c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=R9QF1RCXAYgA:10 a=bmmO2AaSJ7QA:10 a=BTUBnpS-AAAA:8 a=yNzICCC_xv75c2v2eKQA:9 a=yfGOJNFoQxixm5pA:21 a=NjTHmDkTon47Fx94:21 a=QEXdDO2ut3YA:10 a=pblkFgjdBCuYZ9-HdJ6i:22
X-CM-Score: 0
X-Scanned-by: Cloudmark Authority Engine
X-Authed-Username: ZHNlb21uQHJjbi5jb20=
Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=david+work@mandelberg.org; spf=neutral; sender-id=neutral
Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=david+work@mandelberg.org; sender-id=neutral
Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN)
Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.43.168 is neither permitted nor denied by domain of mandelberg.org)
Received: from [209.6.43.168] ([209.6.43.168:52106] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384)  id 4B/41-18484-134B75B5; Tue, 24 Jul 2018 19:20:17 -0400
Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id A474A1C605C; Tue, 24 Jul 2018 19:20:16 -0400 (EDT)
To: draft-ietf-netconf-zerotouch.all@ietf.org, iesg@ietf.org, secdir@ietf.org
From: David Mandelberg 
Organization: David Mandelberg, LLC
Message-ID: <361393b0-6666-08ff-bdf4-3ba3bf4323c7@mandelberg.org>
Date: Tue, 24 Jul 2018 19:20:14 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [secdir] secdir review of draft-ietf-netconf-zerotouch-22
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jul 2018 23:20:27 -0000

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

The summary of the review is Almost ready.

Is there any protection against old signed Zero Touch Information? I see 
that Ownership Vouchers and Owner Certificates both have mechanisms for 
expiration (and for certs, revocation), but I don't see anything 
comparable for redirect or onboarding information. If an owner creates a 
valid redirect or onboarding object and discovers a bug in it, is there 
any way for the owner to make that object no-longer-valid without 
getting an entirely new owner certificate and revoking the old cert? Is 
that intentional?

It seems like this protocol places more trust in device manufacturers 
than was previously required, but I don't see any discussion of that in 
the security considerations. If necessary, is there any way to disable 
zero touch, and configure a device manually? E.g., if the supply chain 
is presumed-secure, but the manufacturer's well-known bootstrap server 
is compromised, is there any way to securely provision a new device?

Section 3.4 mentions a device identify certificate. I assume the public 
keys in those certificates are unique per-device? If not, I want to 
think a bit more about possible attacks where the attacker correlates 
encrypted artifacts without being able to decrypt them.

Section 5.4 says what to do "if the revocation status is not 
attainable". What does that mean precisely? E.g., I assume failure to 
download a CRL, absence of a CRL in the CMS data, and failure to contact 
an OCSP server all count. But what if the device acquires a valid CRL 
that is stale (nextUpdate < now)?

If I'm understanding correctly, the intent of well-known bootstrap 
servers is that the manufacturer can redirect devices to customer 
bootstrap servers that have the actual onboarding information. But I 
also don't see any reason that a (potentially compromised) trusted 
manufacturer's bootstrap server couldn't provide the onboarding 
information directly. It's probably easier to secure the (potentially 
offline) private keys used to sign ownership vouchers than it is to 
secure the (presumably highly available, online) well-known bootstrap 
servers. So it seems like the system as a whole could be more secure if 
well-known bootstrap servers could only provide untrusted redirects.

I don't understand the error cases around the "flag to enable zerotouch 
bootstrapping" in section 5.1. How exactly is that flag set to false? Is 
it by the initial configuration step in section 5.6? If that's where the 
flag is set to false, won't some owners forget to include that in their 
config? Also, how atomic is the application of initial configuration? Is 
there any possible case in which some of the initial configuration can 
be applied without touching the flag, so that the device appears to be 
correctly configured, but will try to bootstrap again on the next 
reboot? Conversely, can the flag be set to false without the device 
being fully configured? (I don't think that's a security issue, just 
potentially a management headache.)

Section 9.4 says to assume owner certificates "are not revokable" if 
there's no accurate clock. Is there no value in checking for a CRL or 
OCSP response, even without the ability to determine if it's recent? It 
seems to me that checking with an active server (CRL Distribution Point 
or OCSP server, as opposed to a stapled CRL or OCSP response) would make 
it significantly harder (not infeasible, just harder) for an attacker to 
use a revoked cert against a device with no clock.

-- 
Freelance cyber security consultant, software developer, and more
https://david.mandelberg.org/


From nobody Thu Jul 26 15:08:30 2018
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F54131242; Thu, 26 Jul 2018 15:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nXMeIRLpQ7M; Thu, 26 Jul 2018 15:08:15 -0700 (PDT)
Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03FC13123B; Thu, 26 Jul 2018 15:08:15 -0700 (PDT)
Received: by mail-pl0-x234.google.com with SMTP id b1-v6so1400608pls.5; Thu, 26 Jul 2018 15:08:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=B+H7z1iJKOJrNej/Wb2wJFy4U2kFLz8gzkGje0mncz8=; b=sIyvsFS909ocffPDil4hiqnWzRArfmSEmpK5dPTF7ReeXpenxfL+0j5Hu1aiBJrkid U9syvR3RDYdX7OgTQgr+GRQtq7IRGj065lI3c/riUMrDlX1xQKdve788VNPEhLvbr9rN YzoNMWa53z9zIrfzGsd3rzP74n9+Juv4vAf++Q2PGkn7mSfEK4BnUASYhXWFFpAmTRdM yESPSaNbd+bwVDlR19cOTK8OtRwQnFbeww4qBVbk60eVvsOINVASxzDR7DAdKMm5kruP eeiQcQy/M0SoPrMosbC9H9P/E33ZLA45IG4PI5OMqzsY6diSZURG9T2jeUeN/8xAUizr 6xzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=B+H7z1iJKOJrNej/Wb2wJFy4U2kFLz8gzkGje0mncz8=; b=jARc5mSTkmFBRlv/mCsCI0O8VPQj2jfGppSnh4dd7M8CCxC5VST8pnId/52WoYAT6e vHXLShxv23JiYIAEUOAsaWc5tR/HStVka2+fM0r6NRBRQ3ereAQGjKk+AUiMy700+2Qh 6rgUcOyB6Af4o2wpy714IZPPEsCs3yQdE6mHO9vDEvUZUyN1a+3/uz8gppFhTohyENUM d3OznHBDIupN1FBpFTQyEOx7jUhYjYhn7SScn8vEvAjbgG76D7/z1a+4p47SOIZBhIdy nJXMKr8sFVyknjIA4kAyaHJ7pE1CNFCMI/b6Bne4Dw3tbOZGnaJI3ZGY/ZfqpxMJyYr7 d/fQ==
X-Gm-Message-State: AOUpUlH3J9KEhWk5P8OS89UV3b0Ihm7cLJqeHFl19nlGjRIKr5zSZFL6 S9sDf+L17MLIZSITz+1feyc41QZK
X-Google-Smtp-Source: AAOMgpdGpoKIHCLYT9VFDEw7NuxHqiB+KBEbjcgL6yqTVTdeSmoDaoIuDJ0KdmUNGMeRdUTFkO9GAw==
X-Received: by 2002:a17:902:c6b:: with SMTP id 98-v6mr3478928pls.233.1532642895312;  Thu, 26 Jul 2018 15:08:15 -0700 (PDT)
Received: from ?IPv6:2601:647:4700:1280:c591:d2f4:a72b:c1de? ([2601:647:4700:1280:c591:d2f4:a72b:c1de]) by smtp.gmail.com with ESMTPSA id r22-v6sm4234534pfl.112.2018.07.26.15.08.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jul 2018 15:08:14 -0700 (PDT)
From: Mahesh Jethanandani 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_E65F9D6C-2A65-4AA4-83AC-83CF4BD3C7CF"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 26 Jul 2018 15:08:11 -0700
In-Reply-To: <20180716104225.hlg3r3x62q4ipq2x@anna.jacobs.jacobs-university.de>
Cc: Daniel Harkins , Kent Watsen , The IESG , "secdir@ietf.org" , "draft-ietf-netconf-nmda-restconf.all@ietf.org" ,  Russ Housley 
To: Juergen Schoenwaelder 
References:  <20180704124128.qpr7tunjw5quiex6@anna.jacobs.jacobs-university.de> <9b2f8091-9ead-e188-ee34-1acfead2dcd2@lounge.org> <20180704183436.zjzwz4vowqi5phz7@anna.jacobs.jacobs-university.de> <14e7ae2d-90ae-32c5-c814-a2d31e9f1a4e@lounge.org>  <8dbe0263-de63-0ddd-86db-04fa7744155c@lounge.org> <99EB8497-BCC0-45A3-A412-6FC5036243F6@gmail.com> <20180716104225.hlg3r3x62q4ipq2x@anna.jacobs.jacobs-university.de>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [secdir] review of draft-ietf-netconf-nmda-restconf-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jul 2018 22:08:19 -0000

--Apple-Mail=_E65F9D6C-2A65-4AA4-83AC-83CF4BD3C7CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

[Adding Russ Housley]

> On Jul 16, 2018, at 3:42 AM, Juergen Schoenwaelder =
 wrote:
>=20
> On Mon, Jul 09, 2018 at 05:48:53PM -0700, Mahesh Jethanandani wrote:
>> There have been a few comments that have been made to the version of =
the draft that has been submitted to IESG. While we wait for other =
comments to be provided, and direction of when an update should be =
provided, who amongst the authors is updating GitHub with these changes?=20=

>>=20
>> I am concerned we might lose track of the changes that need to be =
made.
>>=20
>> Here are the changes that I am aware of for nmda-restconf. I can =
compile a similar list for nmda-netconf if needed.
>=20
> Having a list of outstanding edits for nmda-netconf would be nice as =
well
> so we can make the edits on github.

Let me compile a list of edits that are applicable for nmda-netconf.

>=20
>> Kent=E2=80=99s comment on nmda-restconf operations (thread =
 =
from today).
>=20
> Given that lock and unlock require session semantics, I think the
> resolution should be to add.
>=20
>   A RESTCONF server supporting NMDA datastores MAY implement the
>   "ietf-netconf-nmda" [I-D. ietf-netconf-nmda-netconf] module to
>   enable the NETCONF operations defined in this draft to appear
>   under the {+restconf}/operations resource.
>=20
> But then, what is the value of this? You do not need get-data and
> edit-data with RESTCONF since you can send GET/POST/PATCH straight to
> the datastore resources. I guess I am still unclear which problem we
> are trying to solve by adding this (or a similar) statement.

I am responding to the last sentence that was made on that thread, where =
Kent asked the question.

> So, adding something like this to nmda-restconf would be good?

It likely does not hurt to be clear that this option of using NETCONF
operations in RESTCONF exists.
/js
If you and the authors now believe that the clarification is not needed, =
then please state so.

>=20
>> Dan=E2=80=99s comment on this thread (also from today, but is not on =
netconf mailing list)
>=20
> Not sure which one you mean.

I mean all the the OLD and NEW suggestions from Kent. Basically replace =
=E2=80=9Coptional to support=E2=80=9D with RFC 2119 use of MAY.

>=20
>> Russ=E2=80=99s Genart review (thread =
 =
from June 28)
>=20
> Not sure what the resolution is, removing the example text or trying
> to better explain that this is example text.

I believe either of the options would be ok with Russ. I have added him =
to confirm.

>=20
>> Rohit=E2=80=99s change-2 comments provided for nmda-netconf, that are =
applicable for nmda-restconf (thread =
 =
from June 1)
>=20
> The inclusion of an example showing the usage of
> negated-origin-filter? This was an nmda netconf command. We do not
> seem to have an origin filter in nmda restconf, this is an nmda
> netconf only feature?

Again, I am responding to the last comment that Robert made on the =
follow up e-mail where he proposed changes for NETCONF and said:

Similar updates will need to also be done to RESTCONF, but let's agree =
the NETCONF text first.

Maybe he can clarify what he had in mind for RESTCONF.

Cheers.

>=20
>> Anything else that I missing?
>=20
> Not that I recall.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_E65F9D6C-2A65-4AA4-83AC-83CF4BD3C7CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

[Adding Russ Housley]

On Jul =
16, 2018, at 3:42 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On =
Mon, Jul 09, 2018 at 05:48:53PM -0700, Mahesh Jethanandani wrote:
There have been a few =
comments that have been made to the version of the draft that has been =
submitted to IESG. While we wait for other comments to be provided, and =
direction of when an update should be provided, who amongst the authors =
is updating GitHub with these changes? 

I =
am concerned we might lose track of the changes that need to be made.

Here are the changes that I am aware of for =
nmda-restconf. I can compile a similar list for nmda-netconf if =
needed.

Having a list of =
outstanding edits for nmda-netconf would be nice as well
so =
we can make the edits on github.

Let me =
compile a list of edits that are applicable for =
nmda-netconf.


Kent=E2=80=99s comment on nmda-restconf =
operations (thread <https://www.ietf.org/mail-archive/web/netconf/current/msg14998.=
html> from today).

Given =
that lock and unlock require session semantics, I think the
resolution should be to add.

 =
  A RESTCONF server supporting NMDA datastores MAY implement =
the
   "ietf-netconf-nmda" [I-D. =
ietf-netconf-nmda-netconf] module to
   enable =
the NETCONF operations defined in this draft to appear
 =
  under the {+restconf}/operations resource.

But then, what is the value of this? You do not need get-data =
and
edit-data with RESTCONF since you can send =
GET/POST/PATCH straight to
the datastore resources. I =
guess I am still unclear which problem we
are trying to =
solve by adding this (or a similar) statement.

I am =
responding to the last sentence that was made on that thread, where Kent =
asked the question.

> So, adding something like this to nmda-restconf would be =
good?

It likely does not hurt to be clear that this option of using NETCONF
operations in RESTCONF exists.
/js
If you and the authors now believe that the clarification is =
not needed, then please state so.


Dan=E2=80=99=
s comment on this thread (also from today, but is not on netconf mailing =
list)

Not sure which one you =
mean.

I =
mean all the the OLD and NEW suggestions from Kent. Basically replace =
=E2=80=9Coptional to support=E2=80=9D with RFC 2119 use of =
MAY.


Russ=E2=80=99s Genart review (thread <https://www.ietf.org/mail-archive/web/netconf/current/msg14834.=
html> from June 28)

Not =
sure what the resolution is, removing the example text or trying
to better explain that this is example text.

I believe =
either of the options would be ok with Russ. I have added him to =
confirm.


Rohit=E2=80=99s change-2 comments provided for =
nmda-netconf, that are applicable for nmda-restconf (thread <https://www.ietf.org/mail-archive/web/netconf/current/msg14607.=
html> from June 1)

The =
inclusion of an example showing the usage of
negated-origin-filter? This was an nmda netconf command. We =
do not
seem to have an origin filter in nmda restconf, =
this is an nmda
netconf only feature?

Again, I =
am responding to the last comment that Robert made on the follow up =
e-mail where he proposed changes for NETCONF and said:

Similar updates will =
need to also be done to RESTCONF, but let's agree the NETCONF text =
first.

Maybe he can clarify what he had in mind for =
RESTCONF.

Cheers.


Anything else that I missing?

Not that I recall.

/js

-- 
Juergen Schoenwaelder =
          Jacobs =
University Bremen gGmbH
Phone: +49 421 200 3587 =
        Campus Ring 1 | 28759 =
Bremen | Germany
Fax:   +49 421 200 3103 =
        <https://www.jacobs-university.de/>



Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_E65F9D6C-2A65-4AA4-83AC-83CF4BD3C7CF--


From nobody Thu Jul 26 19:42:17 2018
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D26A12785F; Thu, 26 Jul 2018 19:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ_6VXF6yCz6; Thu, 26 Jul 2018 19:42:12 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 4949E127333; Thu, 26 Jul 2018 19:42:12 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6R2dwxO030349; Thu, 26 Jul 2018 19:42:11 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=Yeby97JpZtt3aC730P4twF8SOBc8wDOr2ARDrklQ9Mo=; b=T4+oMacMvo3mwoWktUYE/a7JsKYcIlF39CwVOxe0jZCuer19wIFb4HGPBsBBj2pU80r7 h0x0LolvuNHtaje4wavNboNRiATY6TIZbjeengfM5bRWArqrVcfykdDU9ReuDOxHGyLy TFQVCB5pNo3Kq1yClGkODWXGZ0lntJGLA0Unp+5PeitYqeN9kVFYwcxkBv0eljtooXwM WNRu9jtQIo73GSAd6PjKt5x7QgMXQxcL5UHC2QDxw8DjmFYDCjFP56Q8Hx5/rG+cgZra Jy5Xpu42k3iCB72fZTItJWvFI5iQHsobAq2zlm1E11htzw+1yRlf168zBL+TCoL4/SOg Bw== 
Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp0115.outbound.protection.outlook.com [216.32.180.115]) by mx0b-00273201.pphosted.com with ESMTP id 2kfp3r0fhm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 26 Jul 2018 19:42:11 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4104.namprd05.prod.outlook.com (52.135.199.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.5; Fri, 27 Jul 2018 02:42:09 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::84c5:999c:9159:d416]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::84c5:999c:9159:d416%2]) with mapi id 15.20.0995.014; Fri, 27 Jul 2018 02:42:09 +0000
From: Kent Watsen 
To: David Mandelberg , "draft-ietf-netconf-zerotouch.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" 
Thread-Topic: secdir review of draft-ietf-netconf-zerotouch-22
Thread-Index: AQHUI6TomGkNAzmsB0eB34I+6n1ia6SiHHoA
Date: Fri, 27 Jul 2018 02:42:08 +0000
Message-ID: <47EEE9B6-5BC2-4A1F-ABB2-2ACB1C494545@juniper.net>
References: <361393b0-6666-08ff-bdf4-3ba3bf4323c7@mandelberg.org>
In-Reply-To: <361393b0-6666-08ff-bdf4-3ba3bf4323c7@mandelberg.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4104; 6:3MOK9rGgxrlfPT5H/jGDnBX7UjQQ5ddW+fze/nvm9aS73VkztvCEiDfL2j4GhuzPROm6KFxxKVzahHMTFD6q2FF7QpsasOxFldFtUyV9ryAkwM4jAri7wXEueGNOSv5/dBUYojGUiLLkl7ntly/0A6qR/XQBE/zoawjHY3Qt0ysx6EnGxl5YbsKv7tdIGixE8Ksb4f2g7J91LfAxpabhKtd03kQNgl7w/8PvskekGS0LSGSqiCCdWsp2h16HJrtqfBq7AlH9nuR2csFwaEJWMwG9vq51h4un2YxTnGtz7qefJMh3RLPHM5g5bqe0KP9cMZMiM0vN6tH2gARxiBeuwTLvY2UYrs2m09g786fWBIO2f+u2EQMxoIIvZ+9QfFhm9iJE7dk/0iw9XFglBTm3V7oRKujeJ0BlwlUqR/Z2p3BqNCdxjKruXhNHTu/ha9ZCAq2iT9ezhldQTnSja38Fhw==; 5:09MeGSj0DnytLiXhxAaz9aQF3RSOWnd4kSi5NE8EWamQnlErG0VSi2+QHzuWOnqvKr4fj7hh+2+4m097IkswTUWgQmJqd8ELqmg9SXRB2kRO1xXrzk3RFxcAbaMaPm8x8Il3G2VNaa6xzb47Kc6UE1QzGxWo/tzVnMMfstScd2M=; 7:6LNoJEJq1Dp8GSiBP1YZ9uWJGfSJbVzZMRhB0dg2E/NknphpVaRr7Gk8B9GVkfAby3uF/b2qiih9F4eOAzSc8U2ks3NScrw+q8OhStMGjF0LCiEOFSedO3CbHegmCicQQgHnbNHWQffvCYC+Cxd6U/slY3ylxXLzZwx338C6agzrSzPmprqLqg182AO7f86cWfE+6KtvANT77SPr/WfETiDrqCDH2C608OjYTERCe5fNxU9HWslK/bFBPGILQ/PS
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 46f51c24-09a8-494e-4fbd-08d5f36a8c7b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4104; 
x-ms-traffictypediagnostic: BYAPR05MB4104:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(60795455431006)(158342451672863)(209352067349851)(192374486261705)(788757137089);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4104; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4104; 
x-forefront-prvs: 07467C4D33
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(346002)(136003)(39860400002)(376002)(189003)(199004)(51444003)(478694002)(58126008)(8936002)(7736002)(83716003)(99286004)(82746002)(110136005)(68736007)(345774005)(316002)(86362001)(106356001)(25786009)(11346002)(6116002)(2201001)(53936002)(446003)(3846002)(81166006)(6246003)(2906002)(81156014)(305945005)(2900100001)(8676002)(97736004)(14444005)(966005)(66066001)(36756003)(6436002)(478600001)(14454004)(229853002)(2501003)(2616005)(476003)(6306002)(5660300001)(6506007)(5250100002)(76176011)(26005)(102836004)(186003)(6512007)(486006)(105586002)(256004)(6486002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4104; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: a67NAjCyfylW4PttQwItUoTmY3x6MzpimVZhVMMaJdbuULn+1LVB/uvD6k5DQqa1pTbWJhCUro4ES33hRZQenghaKxhsSrHfrGIjdih4mr8WXbXG2JMIFNwcuGW8gLX3f+a4SbdhVzqXB8jOa1b3Kw3rA1aIF6Pr3JCB9UegdwSG1l74KcihVcdPhNZoqvSReg/Qe85ka1dYYj0XIY6RDuh6VkX0m3soVtlE25hpNKZmrutQBsF6kR1sXRH1nga8W0Rzrajq46RQs0opWz6FxA7ET5T4ts2PkDZ+VU6KzoVBKVr/9bUshc/WBNRh+Nai7OHSLsGec/XEYk7m3qR9tvnuXaw25gDOI/JFv4AANgw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <6AA22ACC73EE794487FE89EE7F9AD466@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 46f51c24-09a8-494e-4fbd-08d5f36a8c7b
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2018 02:42:09.0205 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4104
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-26_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807270023
Archived-At: 
Subject: Re: [secdir] secdir review of draft-ietf-netconf-zerotouch-22
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jul 2018 02:42:16 -0000

SGkgRGF2aWQsDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXchDQpQbGVhc2UgZmluZCBjb21t
ZW50cyBiZWxvdy4NCg0KS2VudA0KDQoNCj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQg
YXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncw0KPiBvbmdvaW5nIGVmZm9ydCB0
byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUNCj4gSUVT
Ry4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0
IG9mIHRoZQ0KPiBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5k
IFdHIGNoYWlycyBzaG91bGQgdHJlYXQNCj4gdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBv
dGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+DQo+IFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcg
aXMgQWxtb3N0IHJlYWR5Lg0KPg0KPiBJcyB0aGVyZSBhbnkgcHJvdGVjdGlvbiBhZ2FpbnN0IG9s
ZCBzaWduZWQgWmVybyBUb3VjaCBJbmZvcm1hdGlvbj8gSSBzZWUgDQo+IHRoYXQgT3duZXJzaGlw
IFZvdWNoZXJzIGFuZCBPd25lciBDZXJ0aWZpY2F0ZXMgYm90aCBoYXZlIG1lY2hhbmlzbXMgZm9y
IA0KPiBleHBpcmF0aW9uIChhbmQgZm9yIGNlcnRzLCByZXZvY2F0aW9uKSwgYnV0IEkgZG9uJ3Qg
c2VlIGFueXRoaW5nIA0KPiBjb21wYXJhYmxlIGZvciByZWRpcmVjdCBvciBvbmJvYXJkaW5nIGlu
Zm9ybWF0aW9uLiBJZiBhbiBvd25lciBjcmVhdGVzIGEgDQo+IHZhbGlkIHJlZGlyZWN0IG9yIG9u
Ym9hcmRpbmcgb2JqZWN0IGFuZCBkaXNjb3ZlcnMgYSBidWcgaW4gaXQsIGlzIHRoZXJlIA0KPiBh
bnkgd2F5IGZvciB0aGUgb3duZXIgdG8gbWFrZSB0aGF0IG9iamVjdCBuby1sb25nZXItdmFsaWQg
d2l0aG91dCANCj4gZ2V0dGluZyBhbiBlbnRpcmVseSBuZXcgb3duZXIgY2VydGlmaWNhdGUgYW5k
IHJldm9raW5nIHRoZSBvbGQgY2VydD8gSXMgDQo+IHRoYXQgaW50ZW50aW9uYWw/DQoNCk5vLCBh
cyB5b3Ugc2F5LCBpdCBpcyBub3QgcG9zc2libGUgdG8gcmV2b2tlIHNpZ25lZCBkYXRhLCBvdGhl
ciB0aGFuDQp0byByZXZva2UgdGhlIE93bmVyIENlcnRpZmljYXRlIGFzc29jaWF0ZWQgd2l0aCB0
aGUgcHJpdmF0ZSBrZXkgdGhhdA0Kc2lnbmVkIGl0Lg0KDQpJIHdvdWxkbid0IHNheSB0aGF0IHRo
aXMgd2FzL2lzIGludGVudGlvbmFsLCBvdGhlciB0aGFuIG5vdGUgdGhhdCANCml0IHNlZW1zIGNv
bnNpc3RlbnQgd2l0aCBhc3N1bXB0aW9ucyBtYWRlIHdoZW4gdGhlIGJvb3RzdHJhcHBpbmcgDQpk
ZXZpY2Ugb2J0YWlucyB1bnNpZ25lZCBkYXRhIGZyb20gYSB0cnVzdGVkIGJvb3RzdHJhcCBzZXJ2
ZXIsIGluIA0KdGhhdCB0aGUgZGF0YSBpcyBvbmx5IHByb3RlY3RlZCBieSB0aGUgYm9vdHN0cmFw
IHNlcnZlcidzIFRMUyANCmNlcnRpZmljYXRlOyB0aGUgZGV2aWNlIGNhbiBjaGVjayB0aGF0IHRo
ZSBjZXJ0aWZpY2F0ZSBoYXNuJ3QgYmVlbg0KcmV2b2tlZCwgYnV0IHRoYXQgZG9lc24ndCBzYXkg
YW55dGhpbmcgYWJvdXQgdGhlIGN1cnJlbnQgdmFsaWRpdHkNCm9mIHRoZSBkYXRhLg0KDQpEbyB5
b3UgdGhpbmsgYSBTZWN1cml0eSBDb25zaWRlcmF0aW9uIHdvdWxkIGNvdmVyIGl0PyAgU29tZXRo
aW5nDQpsaWtlOg0KDQogICBaZXJvdG91Y2ggaW5mb3JtYXRpb24sIHJlZ2FyZGxlc3Mgb2YgaG93
IG9idGFpbmVkIG9yIGhvdyANCiAgIHRydXN0ZWQsIGRvZXMgbm90IGhhdmUgYSB2YWxpZGl0eSBh
c3NlcnRpb24gYmV5b25kIHRoZSBQS0kNCiAgIHVzZWQgdG8gYXV0aGVudGljYXRlIGl0LiAgWmVy
b3RvdWNoIGluZm9ybWF0aW9uIG5laXRoZXINCiAgIGV4cGlyZXMgbm9yIGNhbiBiZSByZXZva2Vk
LiAgV2hlbiBwcm92aWRlZCBieSBhIHRydXN0ZWQNCiAgIGJvb3RzdHJhcCBzZXJ2ZXIsIHRoZSB2
YWxpZGl0eSBvZiB0aGUgemVyb3RvdWNoIGluZm9ybWF0aW9uDQogICBpcyBpbXBsaWVkIGJ5IGl0
cyBhdmFpbGFiaWxpdHkuICBIb3dldmVyLCB3aGVuIHplcm90b3VjaCANCiAgIGluZm9ybWF0aW9u
IGlzIHByb3ZpZGVkIG91dHNpZGUgdGhlIHB1cnZpZXcgb2YgYSBib290c3RyYXANCiAgIHNlcnZl
ciAoaS5lLiwgc2lnbmVkIGRhdGEgb24gYSByZW1vdmFibGUgc3RvcmFnZSBkZXZpY2UpLA0KICAg
aXRzIGN1cnJlbnQgdmFsaWRpdHkgaXMgbGVzcyBjZXJ0YWluLiAgT3BlcmF0b3JzIGFyZSBhZHZp
c2VkDQogICB0byBlbnN1cmUgb25seSBhY2N1cmF0ZSB6ZXJvdG91Y2ggaW5mb3JtYXRpb24gaXMg
ZXZlciANCiAgIHB1Ymxpc2hlZC4gIEluIGNhc2UgaW5hY2N1cmF0ZSB6ZXJvdG91Y2ggaW5mb3Jt
YXRpb24gaXMNCiAgIHB1Ymxpc2hlZCwgb3Igb3RoZXJ3aXNlIGRlZW1lZCBubyBsb25nZXIgdmFs
aWQsIGFuZCBpdCBpcw0KICAgZGVlbWVkIGEgc2VjdXJpdHkgcmlzaywgdGhlIHNpZ25pbmcgY2Vy
dGlmaWNhdGUgU0hPVUxEIGJlIA0KICAgcmV2b2tlZCBhbmQgYSBuZXcgb25lIGNyZWF0ZWQgaGF2
aW5nIGEgY2hhaW4gdG8gdHJ1c3QgDQogICBsZWFkaW5nIHRvIHRoZSBzYW1lICdwaW5uZWQtZG9t
YWluLWNlcnRpZmljYXRlJyBwcm92aWRlZCANCiAgIGluIHRoZSBPd25lcnNoaXAgVm91Y2hlciBm
b3IgdGhlIGRldmljZS4gIEhvd2V2ZXIsIGRvaW5nDQogICBzbywgd2lsbCBuZWNlc3NhcmlseSBh
ZmZlY3QgdGhlIHZhbGlkaXR5IG9mIGFueSBvdGhlcg0KICAgcHJldmlvdXNseSBwdWJsaXNoZWQg
emVyb3RvdWNoIGluZm9ybWF0aW9uIGFydGlmYWN0cw0KICAgc2lnbmVkIHVzaW5nIHRoZSBqdXN0
LXJldm9rZWQgY2VydGlmaWNhdGUuICBJdCB0aGUgbmVlZA0KICAgdG8gZG8gdGhpcyBpcyBmYWly
bHkgY29tbW9uLCBvcGVyYXRvcnMgY2FuIGRlZmluZSBhbg0KICAgT3duZXIgQ2VydGlmaWNhdGUg
cGVyIGRldmljZS4NCg0KDQo+IEl0IHNlZW1zIGxpa2UgdGhpcyBwcm90b2NvbCBwbGFjZXMgbW9y
ZSB0cnVzdCBpbiBkZXZpY2UgbWFudWZhY3R1cmVycyANCj4gdGhhbiB3YXMgcHJldmlvdXNseSBy
ZXF1aXJlZCwgYnV0IEkgZG9uJ3Qgc2VlIGFueSBkaXNjdXNzaW9uIG9mIHRoYXQgaW4gDQo+IHRo
ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4gSWYgbmVjZXNzYXJ5LCBpcyB0aGVyZSBhbnkgd2F5
IHRvIGRpc2FibGUgDQo+IHplcm8gdG91Y2gsIGFuZCBjb25maWd1cmUgYSBkZXZpY2UgbWFudWFs
bHk/IEUuZy4sIGlmIHRoZSBzdXBwbHkgY2hhaW4gDQo+IGlzIHByZXN1bWVkLXNlY3VyZSwgYnV0
IHRoZSBtYW51ZmFjdHVyZXIncyB3ZWxsLWtub3duIGJvb3RzdHJhcCBzZXJ2ZXIgDQo+IGlzIGNv
bXByb21pc2VkLCBpcyB0aGVyZSBhbnkgd2F5IHRvIHNlY3VyZWx5IHByb3Zpc2lvbiBhIG5ldyBk
ZXZpY2U/DQoNClJlZ2FyZGluZyBwbGFjaW5nIG1vcmUgdHJ1c3QgaW4gZGV2aWNlIG1hbnVmYWN0
dXJlcnMsIGFuZCBhIA0KcG90ZW50aWFsIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHN0YXRlbWVu
dCwgSSdtIHRyeWluZyB0byANCmRldGVybWluZSB3aGF0IHN0YXRlbWVudHMgeW91J3JlIGxvb2tp
bmcgZm9yLiAgDQoNCkJ1dCBmaXJzdCwgSSB0aGluayB5b3UgbWVhbiAid2VsbC1rbm93biBib290
c3RyYXAgc2VydmVycyIgbW9yZQ0Kc28gdGhhbiAibWFudWZhY3R1cmVycyIuICBBRkFJSywgdGhl
IGRyYWZ0IG5ldmVyIHNheXMgaW4gbm9ybWF0aXZlDQp0ZXh0IHRoYXQgdGhlIHdlbGwta25vd24g
Ym9vdHN0cmFwIHNlcnZlcnMgYXJlIGhvc3RlZCBieSB0aGUgDQptYW51ZmFjdHVyZXIgKHRob3Vn
aCBlbnRpcmVseSBwb3NzaWJsZSBhbmQgc29tZXdoYXQgbGlrZWx5KS4NCg0KU28gbWF5YmUgYSBj
b3VwbGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbiBzdGF0ZW1lbnRzIHJlbGF0ZWQgdG86DQoNCjEp
IHRoZSBzZWN1cml0eSBpc3N1ZSB0aGF0IHRoZSB3ZWxsLWtub3duIGJvb3RzdHJhcCBzZXJ2ZXIg
bWF5IGhhdmUNCiAgIGJlZW4gY29tcHJvbWlzZWQuICBUaG91Z2gsIGl0IHNlZW1zIHRoYXQgdGhp
cyBpcyBhIHN0YXRlbWVudCB0aGF0DQogICBhbnkgVExTLXByb3RlY3RlZCByZXNvdXJjZSBjb3Vs
ZCBtYWtlLg0KDQoyKSB0aGUgcHJpdmFjeSBpc3N1ZSB0aGF0IHRoZSBpbmZvcm1hdGlvbiBwcm92
aWRlZCB0byB0aGUgd2VsbC1rbm93bg0KICAgYm9vdHN0cmFwIHNlcnZpY2UgbWF5IGJlIHZpc2li
bGUgdG8gb3RoZXJzIChlLmcuLCBhZG1pbnMgb2YgdGhlIA0KICAgYm9vdHN0cmFwIHNlcnZlcikg
aWYgbm90IGVuY3J5cHRlZC4NCg0KQXJlIHRoZXNlIHdoYXQgeW91IGhhZCBpbiBtaW5kPyAgSWYg
bm90LCBjYW4geW91IHBsZWFzZSBqb3QgZG93biBhDQpmZXcgbGluZXMgY2FwdHVyaW5nIHdoYXQg
eW91IGhvcGUgdG8gc2VlPw0KDQpSZWdhcmRpbmcgImlzIHRoZXJlIGFueSB3YXkgdG8gZGlzYWJs
ZSB6ZXJvIHRvdWNoLCBhbmQgY29uZmlndXJlIGENCmRldmljZSBtYW51YWxseSIsIEkgdGhpbmsg
dGhhdCB0aGlzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSANCmRvY3VtZW50LiAgU29tZSB2
ZW5kb3JzIG1heSBsb2NrIGRvd24gYSBkZXZpY2Ugc3VjaCB0aGF0IGl0IGNhbg0Kb25seSBhY3Rp
dmF0ZSB0aHJ1IHRoZSBib290c3RyYXBwaW5nIHByb2Nlc3MsIHdoaWxlIG90aGVyIGRldmljZXMN
CnNpbXVsdGFuZW91c2x5IGVuYWJsZSBjb25zb2xlIGFjY2Vzcy4NCg0KUmVnYXJkaW5nICJpcyB0
aGVyZSBhbnkgd2F5IHRvIHNlY3VyZWx5IHByb3Zpc2lvbiBhIG5ldyBkZXZpY2UiDQp3aGVuIGEg
d2VsbC1rbm93biBib290c3RyYXAgc2VydmVyIGlzIGtub3duIHRvIGJlIGNvbXByb21pc2VkLiAg
TXkNCmZpcnN0IHRob3VnaHQgaXMsIGlmIGl0J3Mga25vd24gdG8gYmUgY29tcHJvbWlzZWQsIHRo
ZW4gaXQncyBhbHNvDQpsaWtlbHkgcGF0Y2hlZC4gIEJ1dCBsZXQncyBzYXkgdGhlIGlzc3VlIGlz
IG1vcmUgbGlrZSBhbiBvcGVyYXRvcg0Kbm90IHRydXN0aW5nIGEgcGFydGljdWxhciB3ZWxsLWtu
b3duIGJvb3RzdHJhcCBzZXJ2ZXIgZm9yIHNvbWUNCm90aGVyIHJlYXNvbiwgYW5kIHdvdWxkIGxp
a2UgdG8gbmV2ZXIgYWxsb3cgZGV2aWNlcyB0byBvYnRhaW4gDQpib290c3RyYXBwaW5nIGRhdGEg
dGhlcmUuLi50aGVuIHRoZSBvcHRpb25zIGFyZSBzbGltLCBhbiBleHRlcm5hbA0KZmlyZXdhbGwg
cG9saWN5IGJsb2NraW5nIGFjY2VzcyB0byB0aGF0IGJvb3RzdHJhcCBzZXJ2ZXIgbWF5IGJlDQpu
ZWVkZWQuDQoNCg0KPiBTZWN0aW9uIDMuNCBtZW50aW9ucyBhIGRldmljZSBpZGVudGlmeSBjZXJ0
aWZpY2F0ZS4gSSBhc3N1bWUgdGhlDQo+IHB1YmxpYyBrZXlzIGluIHRob3NlIGNlcnRpZmljYXRl
cyBhcmUgdW5pcXVlIHBlci1kZXZpY2U/IElmIG5vdCwgDQo+IEkgd2FudCB0byB0aGluayBhIGJp
dCBtb3JlIGFib3V0IHBvc3NpYmxlIGF0dGFja3Mgd2hlcmUgdGhlIA0KPiBhdHRhY2tlciBjb3Jy
ZWxhdGVzIGVuY3J5cHRlZCBhcnRpZmFjdHMgd2l0aG91dCBiZWluZyBhYmxlIHRvDQo+IGRlY3J5
cHQgdGhlbS4NCg0KWWVzLCBwcm9iYWJpbGlzdGljYWxseS9jcnlwdG9ncmFwaGljYWxseSB1bmlx
dWUga2V5cyBwZXIgZGV2aWNlLg0KDQoNCj4gU2VjdGlvbiA1LjQgc2F5cyB3aGF0IHRvIGRvICJp
ZiB0aGUgcmV2b2NhdGlvbiBzdGF0dXMgaXMgbm90IA0KPiBhdHRhaW5hYmxlIi4gV2hhdCBkb2Vz
IHRoYXQgbWVhbiBwcmVjaXNlbHk/IEUuZy4sIEkgYXNzdW1lIGZhaWx1cmUgdG8gDQo+IGRvd25s
b2FkIGEgQ1JMLCBhYnNlbmNlIG9mIGEgQ1JMIGluIHRoZSBDTVMgZGF0YSwgYW5kIGZhaWx1cmUg
dG8gY29udGFjdCANCj4gYW4gT0NTUCBzZXJ2ZXIgYWxsIGNvdW50LiBCdXQgd2hhdCBpZiB0aGUg
ZGV2aWNlIGFjcXVpcmVzIGEgdmFsaWQgQ1JMIA0KPiB0aGF0IGlzIHN0YWxlIChuZXh0VXBkYXRl
IDwgbm93KT8NCg0KWWVzLCBleGFjdGx5LCBpdCBtZWFudCB0byBjb3ZlciB0aG9zZSBjYXNlcywg
YXMgd2VsbCBhcyB0aGUgInN0YWxlIg0KY2FzZSwgdGhvdWdoIEkgYWRtaXQgdGhlIHRleHQgZG9l
c24ndCBleGFjdGx5IHNheSBpdC4gIEhvdyBhYm91dCB0aGlzPw0KDQogIE9MRA0KICAgICBpZiB0
aGUgcmV2b2NhdGlvbiBzdGF0dXMgaXMgbm90IGF0dGFpbmFibGUNCiAgTkVXDQogICAgIGlmIHN1
aXRhYmx5LWZyZXNoIHJldm9jYXRpb24gc3RhdHVzIGlzIG5vdCBhdHRhaW5hYmxlIA0KDQoNCg0K
PiBJZiBJJ20gdW5kZXJzdGFuZGluZyBjb3JyZWN0bHksIHRoZSBpbnRlbnQgb2Ygd2VsbC1rbm93
biBib290c3RyYXAgDQo+IHNlcnZlcnMgaXMgdGhhdCB0aGUgbWFudWZhY3R1cmVyIGNhbiByZWRp
cmVjdCBkZXZpY2VzIHRvIGN1c3RvbWVyIA0KPiBib290c3RyYXAgc2VydmVycyB0aGF0IGhhdmUg
dGhlIGFjdHVhbCBvbmJvYXJkaW5nIGluZm9ybWF0aW9uLiBCdXQgSSANCj4gYWxzbyBkb24ndCBz
ZWUgYW55IHJlYXNvbiB0aGF0IGEgKHBvdGVudGlhbGx5IGNvbXByb21pc2VkKSB0cnVzdGVkIA0K
PiBtYW51ZmFjdHVyZXIncyBib290c3RyYXAgc2VydmVyIGNvdWxkbid0IHByb3ZpZGUgdGhlIG9u
Ym9hcmRpbmcgDQo+IGluZm9ybWF0aW9uIGRpcmVjdGx5LiBJdCdzIHByb2JhYmx5IGVhc2llciB0
byBzZWN1cmUgdGhlIChwb3RlbnRpYWxseSANCj4gb2ZmbGluZSkgcHJpdmF0ZSBrZXlzIHVzZWQg
dG8gc2lnbiBvd25lcnNoaXAgdm91Y2hlcnMgdGhhbiBpdCBpcyB0byANCj4gc2VjdXJlIHRoZSAo
cHJlc3VtYWJseSBoaWdobHkgYXZhaWxhYmxlLCBvbmxpbmUpIHdlbGwta25vd24gYm9vdHN0cmFw
IA0KPiBzZXJ2ZXJzLiBTbyBpdCBzZWVtcyBsaWtlIHRoZSBzeXN0ZW0gYXMgYSB3aG9sZSBjb3Vs
ZCBiZSBtb3JlIHNlY3VyZSBpZiANCj4gd2VsbC1rbm93biBib290c3RyYXAgc2VydmVycyBjb3Vs
ZCBvbmx5IHByb3ZpZGUgdW50cnVzdGVkIHJlZGlyZWN0cy4NCg0KRmlyc3QsIGxldCdzIHJlcGxh
Y2UgIm1hbnVmYWN0dXJlciIgd2l0aCAid2VsbC1rbm93biBib290c3RyYXAgc2VydmVyIg0KYWJv
dmUuICBCdXQsIHRvIHlvdXIgbWFpbiBwb2ludCwgYWJzb2x1dGVseSwgYW55IGJvb3RzdHJhcC1z
ZXJ2ZXIgY291bGQNCnJldHVybiBlaXRoZXIgcmVkaXJlY3Qgb3Igb25ib2FyZGluZyBpbmZvcm1h
dGlvbiwgYW5kIHBlcmhhcHMgaXQgaXMgYQ0KZmVhdHVyZSBmb3Igc29tZSB3ZWxsLWtub3duIGJv
b3RzdHJhcCBzZXJ2ZXJzIHRvIGRvIHNvLiAgQW5kIHllcyBhZ2FpbiwNCnRoZSBrZXlzIGZvciBh
biBvbmxpbmUgc2VydmljZSBhcmUgcG90ZW50aWFsbHkgbW9yZSBlYXNpbHkgY29tcHJvbWlzZWQs
DQpwZXJoYXBzIGEgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbiBmb3IgdGhlIHVzZSBvZiBIU01zIHNp
bWlsYXIgdG8gWzFdDQp3b3VsZCBoZWxwPyAgV2hpbGUgSSBhZ3JlZSB3aXRoIHlvdXIgY29uY2x1
c2lvbiwgaXQgYnJpbmdzIGludG8gcXVlc3Rpb24NCndoYXQgInRydXN0ZWQiIG1lYW5zLiAgV2hh
dCBhYm91dCBhbiBPQ1NQIHNlcnZlciB3aXRoIGl0cyBvbmxpbmUga2V5Pw0KSWYgdGhlIG1hbnVm
YWN0dXJlciBubyBsb25nZXIgZGVlbXMgKHRocm91Z2ggYXVkaXRzIG9yIHdoYXRldmVyKSB0aGF0
DQphIHdlbGwta25vd24gYm9vdHN0cmFwIHNlcnZlciBpcyBubyBsb25nZXIgdHJ1c3RlZCwgaXQg
Y2FuIHJldm9rZSB0aGUNCmJvb3RzdHJhcCBzZXJ2ZXIncyBjZXJ0aWZpY2F0ZS4gIEp1c3Qgd29u
ZGVyaW5nLCBpcyB0aGlzIHJlYWxseSBhIA0KcHJvYmxlbT8gIENhbiBhIFNlY3VyaXR5IENvbnNp
ZGVyYXRpb24gYmUgdXNlZCB0byBhZGRyZXNzIHRoaXMgdG8gDQp5b3VyIHNhdGlzZmFjdGlvbj8N
Cg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFuaW1hLXZvdWNo
ZXItMDcjc2VjdGlvbi03LjINCg0KDQoNCj4gSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBlcnJvciBj
YXNlcyBhcm91bmQgdGhlICJmbGFnIHRvIGVuYWJsZSB6ZXJvdG91Y2ggDQo+IGJvb3RzdHJhcHBp
bmciIGluIHNlY3Rpb24gNS4xLiBIb3cgZXhhY3RseSBpcyB0aGF0IGZsYWcgc2V0IHRvIGZhbHNl
PyBJcyANCj4gaXQgYnkgdGhlIGluaXRpYWwgY29uZmlndXJhdGlvbiBzdGVwIGluIHNlY3Rpb24g
NS42PyBJZiB0aGF0J3Mgd2hlcmUgdGhlIA0KPiBmbGFnIGlzIHNldCB0byBmYWxzZSwgd29uJ3Qg
c29tZSBvd25lcnMgZm9yZ2V0IHRvIGluY2x1ZGUgdGhhdCBpbiB0aGVpciANCj4gY29uZmlnPyBB
bHNvLCBob3cgYXRvbWljIGlzIHRoZSBhcHBsaWNhdGlvbiBvZiBpbml0aWFsIGNvbmZpZ3VyYXRp
b24/IElzIA0KPiB0aGVyZSBhbnkgcG9zc2libGUgY2FzZSBpbiB3aGljaCBzb21lIG9mIHRoZSBp
bml0aWFsIGNvbmZpZ3VyYXRpb24gY2FuIA0KPiBiZSBhcHBsaWVkIHdpdGhvdXQgdG91Y2hpbmcg
dGhlIGZsYWcsIHNvIHRoYXQgdGhlIGRldmljZSBhcHBlYXJzIHRvIGJlIA0KPiBjb3JyZWN0bHkg
Y29uZmlndXJlZCwgYnV0IHdpbGwgdHJ5IHRvIGJvb3RzdHJhcCBhZ2FpbiBvbiB0aGUgbmV4dCAN
Cj4gcmVib290PyBDb252ZXJzZWx5LCBjYW4gdGhlIGZsYWcgYmUgc2V0IHRvIGZhbHNlIHdpdGhv
dXQgdGhlIGRldmljZSANCj4gYmVpbmcgZnVsbHkgY29uZmlndXJlZD8gKEkgZG9uJ3QgdGhpbmsg
dGhhdCdzIGEgc2VjdXJpdHkgaXNzdWUsIGp1c3QgDQo+IHBvdGVudGlhbGx5IGEgbWFuYWdlbWVu
dCBoZWFkYWNoZS4pDQoNClllcywgdGhlIGluaXRpYWwtc3RlcCBpbiBTZWN0aW9uIDUuNi4gIFll
cywgc29tZSBvcGVyYXRvcnMgbWF5IGZvcmdldA0KKHRob3VnaCB0aGV5IHdpbGwgbGVhcm4pLiAg
VGhlIGNvbmZpZyBpcyBpbnRlbmRlZCB0byBlaXRoZXIgYmUgYXBwbGllZA0KY29tcGxldGVseSBv
ciBub3QgYXQgYWxsLiAgVGhlIHNlY29uZCBwYXJhZ3JhcGggaW4gc2VjdGlvbiA1LjYgc2F5cw0K
IklmIHRoZSBkZXZpY2UgZW5jb3VudGVycyBhbiBlcnJvciBhdCBhbnkgc3RlcCwgaXQgTVVTVCBO
T1QgcHJvY2VlZA0KdG8gdGhlIG5leHQgc3RlcC4iICBQZXJoYXBzIHRoZSA2dGggcGFyYWdyYXBo
IGluIHRoYXQgc2VjdGlvbiBjb3VsZA0KY291bGQgc3RhdGUgdGhhdCBhbiAiZXJyb3IiIGNvbnN0
aXR1dGVzIGFueXRoaW5nIGxlc3MgdGhhbiAxMDAlPw0KDQoNCj4gU2VjdGlvbiA5LjQgc2F5cyB0
byBhc3N1bWUgb3duZXIgY2VydGlmaWNhdGVzICJhcmUgbm90IHJldm9rYWJsZSIgaWYgDQo+IHRo
ZXJlJ3Mgbm8gYWNjdXJhdGUgY2xvY2suIElzIHRoZXJlIG5vIHZhbHVlIGluIGNoZWNraW5nIGZv
ciBhIENSTCBvciANCj4gT0NTUCByZXNwb25zZSwgZXZlbiB3aXRob3V0IHRoZSBhYmlsaXR5IHRv
IGRldGVybWluZSBpZiBpdCdzIHJlY2VudD8gSXQgDQo+IHNlZW1zIHRvIG1lIHRoYXQgY2hlY2tp
bmcgd2l0aCBhbiBhY3RpdmUgc2VydmVyIChDUkwgRGlzdHJpYnV0aW9uIFBvaW50IA0KPiBvciBP
Q1NQIHNlcnZlciwgYXMgb3Bwb3NlZCB0byBhIHN0YXBsZWQgQ1JMIG9yIE9DU1AgcmVzcG9uc2Up
IHdvdWxkIG1ha2UgDQo+IGl0IHNpZ25pZmljYW50bHkgaGFyZGVyIChub3QgaW5mZWFzaWJsZSwg
anVzdCBoYXJkZXIpIGZvciBhbiBhdHRhY2tlciB0byANCj4gdXNlIGEgcmV2b2tlZCBjZXJ0IGFn
YWluc3QgYSBkZXZpY2Ugd2l0aCBubyBjbG9jay4NCg0KT2theSwgZmFpciBwb2ludCwgYSBsaXZl
IHJlc3BvbnNlIHNvcnQgb2YgcmVmbGVjdHMgIm5vdyIsIHJlZ2FyZGxlc3MgDQp3aGF0IHRoZSBk
ZXZpY2UgY2xvY2sgc2F5cy4gIFRoYXQgc2FpZCwgd2l0aG91dCBhbiBhY2N1cmF0ZSBjbG9jaywg
dGhlDQpkZXZpY2Ugd291bGRuJ3QgYmUgYWJsZSB0byB2YWxpZGF0ZSB0aGUgc2lnbmluZyBjZXJ0
aWZpY2F0ZSBhbmQsIGlmIA0KcHJvdmlkZWQgb3ZlciBhbiBIVFRQUyB0cmFuc3BvcnQsIGl0IHdv
dWxkbid0IGJlIGFibGUgdG8gdmFsaWRhdGUgdGhlDQpzZXJ2ZXIncyBlbmQtZW50aXR5IGNlcnRp
ZmljYXRlIGVpdGhlci4gIEluIGZhY3QsIGNlcnRhaW4gZGV2aWNlIGJhZA0KY2xvY2sgdmFsdWVz
IG1pZ2h0IGFjdHVhbGx5IGJsb2NrIHRoZSBUTFMgY29ubmVjdGlvbiBkdWUgdG8gaXQgYmVpbmcN
Cm91dHNpZGUgdGhlIGVuZC1lbnRpdHkgY2VydCdzIHZhbGlkaXR5IHBlcmlvZC4gIFVnaC4gIEN1
cnJlbnRseSB0aGUgDQp0ZXh0IHNheXMgdGhhdCBkZXZpY2UgImltcGxlbWVudGF0aW9ucyBzaG91
bGQgYXNzdW1lIFt0aGluZ3NdICBhcmUgbm90IA0KcmV2b2NhYmxlIiAtIGRvIHlvdSB3YW50IHRv
IGFkZCBhIHRleHQgbGlrZSAiYnV0IE1BWSBjaGVjayAnY3VycmVudCcNCnJldm9jYXRpb24gdXNp
bmcgb24gb25saW5lIENSTCBEaXN0cmlidXRpb24gUG9pbnQgb3IgDQpPQ1NQIHNlcnZlciI/ICAN
Cg0KQlRXLCB0aGUgZW5kIG9mIHRoaXMgc2VjdGlvbiBzYXlzICJJbXBsZW1lbnRhdGlvbnMgU0hP
VUxEIE5PVCByZWx5IG9uDQpOVFAgZm9yIHRpbWUsIGFzIE5UUCBpcyBub3QgYSBzZWN1cmUgcHJv
dG9jb2wuIiAtIGFueSB0aG91Z2h0cyBvbiB0aGlzDQpzdGF0ZW1lbnQ/DQoNCg0KVGhhbmtzIGFn
YWluLCBEYXZpZC4NCg0KS2VudA0KDQoNCg0KDQoNCg==


From nobody Fri Jul 27 13:01:37 2018
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35502130EBC for ; Fri, 27 Jul 2018 13:01:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WegIyv8vPwW1 for ; Fri, 27 Jul 2018 13:01:33 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6D8130EBE for ; Fri, 27 Jul 2018 13:01:33 -0700 (PDT)
X-AuditID: 12074424-125ff70000004129-c7-5b5b7a19f4c9
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id E9.50.16681.A1A7B5B5; Fri, 27 Jul 2018 16:01:30 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w6RK1SEQ015672 for ; Fri, 27 Jul 2018 16:01:29 -0400
Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w6RK1PQg023222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 27 Jul 2018 16:01:27 -0400
Date: Fri, 27 Jul 2018 15:01:25 -0500
From: Benjamin Kaduk 
To: secdir@ietf.org
Message-ID: <20180727200125.GI12983@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUixG6noitVFR1tsOG8jsWHhQ9ZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8fmra8EJloqJhxvYGxivMncxcnJICJhITH7+hq2LkYtDSGAx k8Ta+VfYIZzjjBI9j9exgFQJCTxmkvi5EqyDRUBVounWFkYQm01ARaKh+zJYXERAWOL2wQes ILYwUHzdhl4wm1dAR+LHsZmMELagxMmZT8BmMgtoSdz495Kpi5EDyJaWWP6PAyQsKqAssbfv EPsERt5ZSDpmIemYhdCxgJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka65Xm5miV5qSukmRnAY uajsYOzu8T7EKMDBqMTDe8EmOlqINbGsuDL3EKMkB5OSKO+FAqAQX1J+SmVGYnFGfFFpTmrx IUYJDmYlEV5hFaAcb0piZVVqUT5MSpqDRUmc925NeLSQQHpiSWp2ampBahFMVoaDQ0mCd2EF UKNgUWp6akVaZk4JQpqJgxNkOA/Q8OMgNbzFBYm5xZnpEPlTjLocf95PncQsxJKXn5cqJc67 HqRIAKQoozQPbg4o/iWy99e8YhQHekuY9ztIFQ8wdcBNegW0hAlkSVwkyJKSRISUVAOjyMLN df/THLPmPtnAs3x9/edsxoWsASUcMz/pezvO89s8zXQh28ygTw94eP1XyPswTt2ltsB0hsHZ 98+nMSTb/Va8K3f78tJq/XC2x/v5ZKbJ+m6RljRV2lwee3v5RZZWjs6actdTpl4cDDJ239fc /7lX7/DinKvt/HHyDG0/3LYWy7rJiPxXYinOSDTUYi4qTgQATy74JNoCAAA=
Archived-At: 
Subject: [secdir] secdir datatracker accident
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jul 2018 20:01:35 -0000

Hi folks,

Just FYI, I had an accident with the datatracker on Wednesday and caused
like 80% of the group's mebmership to disappear from the group.  The fine
folks at the secretariat and tools team seem to have resolved it, but
please do file a ticket if you see something that looks wrong (such
as not appearing on the list at
https://datatracker.ietf.org/group/secdir/about/ if you expect to).

Tero skipped doing assignments yesterday since there wasn't much point; I
don't know if it's worth doing them today now that things look fixed.

Sorry for the mix-up,

Ben


From nobody Fri Jul 27 13:08:43 2018
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B33C130DF5; Fri, 27 Jul 2018 13:08:32 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OmjHuhWhgg8; Fri, 27 Jul 2018 13:08:29 -0700 (PDT)
Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839F9130DD1; Fri, 27 Jul 2018 13:08:29 -0700 (PDT)
Received: by mail-yw0-x243.google.com with SMTP id r3-v6so2305031ywc.5; Fri, 27 Jul 2018 13:08:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=zEidKHiD3+AOhvHPnOPhjTKodHucx018M16DkgP1BlA=; b=u6kwajy5YYulUJ6wJ+ULy7SlcMZvn0ym/n/q3r9/eDy+xCfauLf4ijfTn5PktbsiY+ fN62PsfBqu7F4DXQ8F+IZGiuncgATeQAoyR+FlH6nBaB3EGXqcTIadS0aCC61UDcXrL3 mUYtlEpUHy7BG9E9SklAgPJcHsCBIIcIV4ctJ3wOkbcJsO9nnGo+F3nNfcHad9ebQv+S H+/h/tgT01k2XM/mePWPFBBX64KWi1Sv2IpPdHv6WqYyAK41EN57fTV3pijgfTDGxj0m Uo6YrV5lpWxIq//nMp9aVWXneAUPAIAINgyCxzdpVG1sXkKrMOvrae4m7MozYLkc8PTO u/dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=zEidKHiD3+AOhvHPnOPhjTKodHucx018M16DkgP1BlA=; b=Mdfj9uFH+zMTzI9jmxTJ4oLVppAftndVOSoVYUyI3jWBxZZtVpKibzzd2GOM77U/73 UPEQoVa/EkjPxKrYnIQzgW4Z7ZmOqK6+f8LjgcBemdhmRNfEJSNAsg45iXcDoxFA3Vf9 WdVFdfv2eHcBWl8vCc22m35kup3eWnatcScF/6guSn3oeNLpnVFKeWR0Ny5zFpwJ4Y4v 5ZGGcvdwEX+qGR2qKxhepq8raaklL5CU7aY6wEm57FXZ7Ffy44HJ/iF91PaPV18HHXQF 8IhepAu2GmfbCF3QTPLv0xWfKLulHxJBxNxR3n8jvQ7hCSKpQI5CycrjuggVTdYKr11v Jb4A==
X-Gm-Message-State: AOUpUlHLEGbap6COuLtpSPxhsa3VN2nWRDWsqhF4dDm8Rp5Xz7ygh6q3 kvi5wHwp5e5589FR6CCTjcG3V5Np
X-Google-Smtp-Source: AAOMgpduvGS4j6XKtxG034rBHKAiC4p1ekkbT4vk2U6OZC3vS163+10JLmIMbkJ9KtBTgS5RdaiazQ==
X-Received: by 2002:a0d:c5c7:: with SMTP id h190-v6mr4244958ywd.421.1532722108567;  Fri, 27 Jul 2018 13:08:28 -0700 (PDT)
Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:d163:50a4:667c:87fa]) by smtp.googlemail.com with ESMTPSA id x69-v6sm3117108ywx.105.2018.07.27.13.08.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jul 2018 13:08:28 -0700 (PDT)
To: Mahesh Jethanandani 
References: <5B567AA3.1010902@gmail.com> <52B57BE1-B92E-42C2-8F7F-815A7658A903@gmail.com>
Cc: "secdir@ietf.org" , The IESG , draft-mahesh-etsi-urn.all@ietf.org
From: Chris Lonvick 
Message-ID: <5B5B7BBC.6080208@gmail.com>
Date: Fri, 27 Jul 2018 15:08:28 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <52B57BE1-B92E-42C2-8F7F-815A7658A903@gmail.com>
Content-Type: multipart/alternative; boundary="------------020006030909040503090702"
Archived-At: 
Subject: Re: [secdir] SECDIR review of draft-mahesh-etsi-urn-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jul 2018 20:08:32 -0000

This is a multi-part message in MIME format.
--------------020006030909040503090702
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Mahesh,

Thanks for setting me straight. The edits you propose look good to me.

Best regards,
Chris

On 7/24/18 4:37 PM, Mahesh Jethanandani wrote:
> Hi Chris,
>
>> On Jul 23, 2018, at 6:02 PM, Chris Lonvick > > wrote:
>>
>> Hi,
>>
>> I have reviewed this document as part of the security directorate's 
>> ongoing effort to review all IETF documents being processed by the 
>> IESG. These comments were written primarily for the benefit of the 
>> security area directors. Document editors and WG chairs should treat 
>> these comments just like any other last call comments.
>>
>> The summary of the review is Ready with Issues.
>>
>> I am not that familiar with creating and maintaining URNs so please 
>> set me straight and move on if I'm off base here.
>>
>> Section 2, "URN Specification for ETSI" contains the following:
>>
>> "ETSI will manage resource classes using the "etsi" NID and will be 
>> the authority for managing resources and associated subsequent 
>> strings. ETSI will guarantee the uniqueness of the strings 
>> themselves, or it may permit secondary responsibility for certain 
>> defined resources."
>>
>> But then says:
>>
>> "ETSI may allow for use of experimental type values for testing 
>> purposes only. Note that using experimental types may create 
>> collision as multiple users may use the same values for different 
>> resources and specific strings."
>>
>> It looks like RFC 8141 gives guidance that experimental use of URN 
>> namespaces is to be done using RFC 6963 (URNs for "Examples".) RFC 
>> 8184 does not address establishing or using namespaces under the 
>> subsequent strings for experimental use, but I could see that the 
>> registered owner of the namespace could make a designation for that 
>> purpose. That being said, I think that the two statements above are 
>> in conflict in the document and should be clarified.
>
> Not necessarily.
>
> RFC6963 says that there are three types of namespaces, formal, 
> informal and experimental. What this draft is requesting for is the 
> formal namespace. The RFC also says that experimental namespaces are 
> by definition unregistered. That there is no issuing authority for 
> experimental URNs. The owner of the NID therefore is not required to 
> keep track of experimental namespaces.
>
>>
>> Perhaps it would be better to reconstruct the second paragraph to say 
>> something like:
>>
>> "ETSI may allow for use of experimental type values for testing 
>> purposes only. Some experimentation may be controlled by ETSI within 
>> a subsequent string to ensure that there will be no namespace 
>> collisions among participants. Other experimentation may be 
>> controlled within a secondary namespace that may allow collisions, 
>> but this experimental use will be constrained. All other 
>> experimentation must follow the guidance set forth in RFC 6963.”
>
> How about this?
>
> OLD:
>
> ETSI may allow for use of experimental type values for testing 
> purposes only. Note that using experimental types may create collision 
> as multiple users may use the same values for different resources and 
> specific strings.
>
> NEW:
>
> ETSI may allow for use of experimental type values for testing 
> purposes only. Note that using experimental types may create collision 
> as multiple users may use the same values for different resources and 
> specific strings. All experimentation must follow the guidance set 
> forth in RFC 6963.
>
>>
>> Just as a nit, the Security Considerations section should be revised 
>> as it seems to be a bit unclear.
>> Current:
>>     There are no additional security considerations other than those
>>     described above, and are normally associated with the use and
>>     resolution of URNs in general, which are described in Function
>>     Requirements for URN [RFC1737 ], Uniform Resource Names (URNs)
>>     [RFC8141 ].
>>
>> Suggested:
>>     There are no additional security considerations other than those
>>     described above, and_those_  normally associated with the use and
>>     resolution of URNs in general._These a__re generally_  described in Function_al_
>>     Requirements for_Uniform Resource Names_  [RFC1737 ],_and_  Uniform Resource Names (URNs)
>>     [RFC8141 ].
> Ok.
> Thanks.
>> Best regards, Chris 
> Mahesh Jethanandani
> mjethanandani@gmail.com 

--------------020006030909040503090702
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Mahesh,

    

    Thanks for setting me straight. The edits you propose look good to
    me.

    

    Best regards,

    Chris

    

    
On 7/24/18 4:37 PM, Mahesh Jethanandani
      wrote:

    

    

      
      Hi Chris,

      


        

          
On Jul 23, 2018, at 6:02 PM, Chris Lonvick <lonvick.ietf@gmail.com>
            wrote:

          

          

            
            
 Hi,

              

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

              

              The summary of the review is Ready with Issues.

              

              I am not that familiar with creating and maintaining URNs
              so please set me straight and move on if I'm off base
              here. 

              

              Section 2, "URN Specification for ETSI" contains the
              following:

              

              "ETSI will manage resource classes using the "etsi" NID
              and will be the authority for managing resources and
              associated subsequent strings. ETSI will guarantee the
              uniqueness of the strings themselves, or it may permit
              secondary responsibility for certain defined resources."
              
              
              
              

              

              But then says:

              

              
              "ETSI may allow for use of experimental type values for
              testing purposes only. Note that using experimental types
              may create collision as multiple users may use the same
              values for different resources and specific strings."

              

              It looks like RFC
              
              8141 gives guidance that experimental use of URN
              namespaces is to be done using RFC 6963 (URNs for
              "Examples".) RFC 8184 does not address establishing or
              using namespaces under the subsequent strings for
              experimental use, but I could see that the registered
              owner of the namespace could make a designation for that
              purpose. That being said, I think that the two statements
              above are in conflict in the document and should be
              clarified.

            

          

        

        


        

        Not necessarily.

      


      

      
RFC6963 says that there are three types of namespaces,
        formal, informal and experimental. What this draft is requesting
        for is the formal namespace. The RFC also says that experimental
        namespaces are by definition unregistered. That there is no
        issuing authority for experimental URNs. The owner of the NID
        therefore is not required to keep track of experimental
        namespaces. 

      


        

          

            
 

              Perhaps it would be better to reconstruct the second
              paragraph to say something like:

              

              "ETSI may allow for use of experimental type values for
              testing purposes only. Some experimentation may be
              controlled by ETSI within a subsequent string to ensure
              that there will be no namespace collisions among
              participants. Other experimentation may be controlled
              within a secondary namespace that may allow collisions,
              but this experimental use will be constrained. All other
              experimentation must follow the guidance set forth in RFC
              6963.”

          

        

        


        

        How about this?

      


      

      
OLD:

      


      

      
ETSI
          may allow for use of experimental type values for testing
          purposes only. Note that using experimental types may create
          collision as multiple users may use the same values for
          different resources and specific strings.

      


      

      
NEW:

      


      

      
ETSI
          may allow for use of experimental type values for testing
          purposes only. Note that using experimental types may create
          collision as multiple users may use the same values for
          different resources and specific strings. All experimentation
          must follow the guidance set forth in RFC 6963.

      


        

      

        

          

            
 

              Just as a nit, the Security Considerations section should
              be revised as it seems to be a bit unclear.

              Current:

              
              
   There are no additional security considerations other than those
   described above, and are normally associated with the use and
   resolution of URNs in general, which are described in Function
   Requirements for URN [RFC1737], Uniform Resource Names (URNs)
   [RFC8141].

Suggested:
   There are no additional security considerations other than those
   described above, and those normally associated with the use and
   resolution of URNs in general. These are generally described in Functional
   Requirements for Uniform Resource Names [RFC1737], and Uniform Resource Names (URNs)
   [RFC8141].


Ok.


Thanks.



Best regards,
Chris





Mahesh Jethanandani











--------------020006030909040503090702--


From nobody Mon Jul 30 15:11:03 2018
Return-Path: 
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C7D131147; Mon, 30 Jul 2018 15:10:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Daniel Migault 
To: 
Cc: draft-ietf-core-object-security.all@ietf.org, ietf@ietf.org, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153298864768.8255.12499424928369646545@ietfa.amsl.com>
Date: Mon, 30 Jul 2018 15:10:47 -0700
Archived-At: 
Subject: [secdir] Secdir last call review of draft-ietf-core-object-security-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jul 2018 22:10:48 -0000

Reviewer: Daniel Migault
Review result: Has Issues

Hi,

Reviewer: Daniel Migault
Review result: Has Issues

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

The summary of the review is Has (small) Issues.

I am not an expert in CoAP. The document is well written, and I believe
securing objects is important. I had comments regarding the description of
security contexts. I hesitated between Nits and Issues. I do not believe these
are major design issues, and some clarifications may be sufficient. Other
comments are mostly editorial nits. Please find above my comments. I am happy
to follow up the updates.

     Object Security for Constrained RESTful Environments (OSCORE)
                   draft-ietf-core-object-security-14

1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] is a web
   transfer protocol, designed for constrained nodes and networks
   [RFC7228], and may be mapped from HTTP [RFC8075].  CoAP specifies the
   use of proxies for scalability and efficiency and references DTLS
   [RFC6347] for security.  CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to-HTTP
   proxies require DTLS or TLS [RFC5246] to be terminated at the proxy.
   The proxy therefore not only has access to the data required for
   performing the intended proxy functionality, but is also able to
   eavesdrop on, or manipulate any part of, the message payload and
   metadata in transit between the endpoints.  The proxy can also
   inject, delete, or reorder packets since they are no longer protected
   by (D)TLS.

The proxy can almost do whatever it wants as mentioned in the second sentence.
Accessing the data enables it to passively monitor the communication.  I would
thus propose some text around these lines:

OLD:
The proxy therefore not only has access to the data required for
   performing the intended proxy functionality, but is also able to
   eavesdrop on, or manipulate any part of, the message payload and
   metadata in transit between the endpoints.  The proxy can also
   inject, delete, or reorder packets since they are no longer protected
   by (D)TLS.

NEW:
The proxy therefore has access to the data required for
   performing the intended proxy functionality, and so can passively monitor
   the communications. In addition, the proxy can also inject, delete, or
   reorder packets since they are no longer protected by (D)TLS.


   This document defines the Object Security for Constrained RESTful
   Environments (OSCORE) security protocol, protecting CoAP and CoAP-
   mappable HTTP requests and responses end-to-end across intermediary
   nodes such as CoAP forward proxies and cross-protocol translators
   including HTTP-to-CoAP proxies [RFC8075].  In addition to the core
   CoAP features defined in [RFC7252], OSCORE supports Observe
   [RFC7641], Block-wise [RFC7959], No-Response [RFC7967], and PATCH and
   FETCH [RFC8132].

Maybe too many "and".


An analysis of end-to-end security for CoAP
   messages through some types of intermediary nodes is performed in
   [I-D.hartke-core-e2e-security-reqs].  OSCORE essentially protects the
   RESTful interactions; the request method, the requested resource, the
   message payload, etc. (see Section 4).  OSCORE protects neither the
   CoAP Messaging Layer nor the CoAP Token which may change between the
   endpoints, and those are therefore processed as defined in [RFC7252].
   Additionally, since the message formats for CoAP over unreliable
   transport [RFC7252] and for CoAP over reliable transport [RFC8323]
   differ only in terms of CoAP Messaging Layer, OSCORE can be applied
   to both unreliable and reliable transports (see Figure 1).

Selander, et al.        Expires January 27, 2019                [Page 4]

Internet-Draft                   OSCORE                        July 2018

               +-----------------------------------+
               |            Application            |
               +-----------------------------------+
               +-----------------------------------+  \
               |  Requests / Responses / Signaling |  |
               |-----------------------------------|  |
               |               OSCORE              |  | CoAP
               |-----------------------------------|  |
               | Messaging Layer / Message Framing |  |
               +-----------------------------------+  /
               +-----------------------------------+
               |          UDP / TCP / ...          |
               +-----------------------------------+

              Figure 1: Abstract Layering of CoAP with OSCORE

   OSCORE works in very constrained nodes and networks, thanks to its
   small message size and the restricted code and memory requirements in
   addition to what is required by CoAP.  Examples of the use of OSCORE
   are given in Appendix A.  OSCORE does not depend on underlying
   layers, and can be used with non-IP transports (e.g.,
   [I-D.bormann-6lo-coap-802-15-ie]).  OSCORE may also be used in
   different ways with HTTP.  OSCORE messages may be transported in
   HTTP, and OSCORE may also be used to protect CoAP-mappable HTTP
   messages, as described below.


I believe that "underlying layers" should be specified. My understanding is
that OSCORE requires CoAP or HTTP. If that is correct, I believe that should be
clarified in the paragraph above. 

   OSCORE is designed to protect as much information as possible while
   still allowing CoAP proxy operations (Section 10).  It works with
   existing CoAP-to-CoAP forward proxies [RFC7252], but an OSCORE-aware
   proxy will be more efficient.  HTTP-to-CoAP proxies [RFC8075] and
   CoAP-to-HTTP proxies can also be used with OSCORE, as specified in
   Section 11.  OSCORE may be used together with TLS or DTLS over one or
   more hops in the end-to-end path, e.g. transported with HTTPS in one
   hop and with plain CoAP in another hop.  The use of OSCORE does not
   affect the URI scheme and OSCORE can therefore be used with any URI
   scheme defined for CoAP or HTTP.  The application decides the
   conditions for which OSCORE is required.

   OSCORE uses pre-shared keys which may have been established out-of-
   band or with a key establishment protocol (see Section 3.2).  The
   technical solution builds on CBOR Object Signing and Encryption
   (COSE) [RFC8152], providing end-to-end encryption, integrity, replay
   protection, and binding of response to request.  A compressed version
   of COSE is used, as specified in Section 6.  The use of OSCORE is
   signaled in CoAP with a new option (Section 2), and in HTTP with a
   new header field (Section 11.1) and content type (Section 13.5).  The
   solution transforms a CoAP/HTTP message into an "OSCORE message"
   before sending, and vice versa after receiving.  The OSCORE message

Selander, et al.        Expires January 27, 2019                [Page 5]

Internet-Draft                   OSCORE                        July 2018

   is a CoAP/HTTP message related to the original message in the
   following way: the original CoAP/HTTP message is translated to CoAP
   (if not already in CoAP) and protected in a COSE object.  The
   encrypted message fields of this COSE object are transported in the
   CoAP payload/HTTP body of the OSCORE message, and the OSCORE option/
   header field is included in the message.  A sketch of an exchange of
   OSCORE messages, in the case of the original message being CoAP, is
   provided in Figure 2.

          Client                                          Server
             |      OSCORE request - POST example.com:      |
             |        Header, Token,                        |
             |        Options: {OSCORE, ...},               |
             |        Payload: COSE ciphertext              |
             +--------------------------------------------->|
             |                                              |
             |<---------------------------------------------+
             |      OSCORE response - 2.04 (Changed):       |
             |        Header, Token,                        |
             |        Options: {OSCORE, ...},               |
             |        Payload: COSE ciphertext              |
             |                                              |

                   Figure 2: Sketch of CoAP with OSCORE


Options are mentioned in {}. How these "{}" should be interpreted may be
specified in the figure.

The paragraph above mentions that OSCORE can be used both with CoAP or HTTP. It
might be helpful to split Figure 2 in to two sub figures Figure 2a) that
illustrates the use of OCSORE with CoAP and figure 2b) that illustrates the use
of OSCORE with HTTP.

My understanding is that CoAP and HTTP can easily be translated. As such it
might also be able to consider OSCORE only with CoAP and having a specific
section that deals with HTTP. Such split may avoid to deal in parallel with
HTTP and CoAP. 

   An implementation supporting this specification MAY implement only
   the client part, MAY implement only the server part, or MAY implement
   only one of the proxy parts.

1.1.  Terminology

2.  The OSCORE Option

   The OSCORE option (see Figure 3, which extends Table 4 of [RFC7252])
   indicates that the CoAP message is an OSCORE message and that it
   contains a compressed COSE object (see Sections 5 and 6).  The OSCORE
   option is critical, safe to forward, part of the cache key, and not
   repeatable.


I believe it would be clearer to specify that this section defines the OSCORE
option which is a new CoAP option.  Similarly Table 4 may also be designated by
CoAP Options or something similar. 

   +------+---+---+---+---+----------------+--------+--------+---------+
   | No.  | C | U | N | R | Name           | Format | Length | Default |
   +------+---+---+---+---+----------------+--------+--------+---------+
   | TBD1 | x |   |   |   | OSCORE         |  (*)   | 0-255  | (none)  |
   +------+---+---+---+---+----------------+--------+--------+---------+
       C = Critical,   U = Unsafe,   N = NoCacheKey,   R = Repeatable
       (*) See below.

                        Figure 3: The OSCORE Option

   The OSCORE option includes the OSCORE flag bits (Section 6), the
   Sender Sequence Number, the Sender ID, and the ID Context when these
   fields are present (Section 3).  The detailed format and length is
   specified in Section 6.  If the OSCORE flag bits are all zero (0x00)
   the Option value SHALL be empty (Option Length = 0).  An endpoint
   receiving a CoAP message without payload, that also contains an
   OSCORE option SHALL treat it as malformed and reject it.


I believe the logic for the OSCORE option is the other way around, that is: an
CoAP message with an OSCORE option with an empty CoAP payload MUST be rejected
as malformed and reject it. 

   A successful response to a request with the OSCORE option SHALL
   contain the OSCORE option.  Whether error responses contain the
   OSCORE option depends on the error type (see Section 8).

   For CoAP proxy operations, see Section 10.

3.  The Security Context

   OSCORE requires that client and server establish a shared security
   context used to process the COSE objects.  OSCORE uses COSE with an
   Authenticated Encryption with Additional Data (AEAD, [RFC5116])
   algorithm for protecting message data between a client and a server.
   In this section, we define the security context and how it is derived

Selander, et al.        Expires January 27, 2019                [Page 7]

Internet-Draft                   OSCORE                        July 2018

   in client and server based on a shared secret and a key derivation
   function (KDF).

3.1.  Security Context Definition

   The security context is the set of information elements necessary to
   carry out the cryptographic operations in OSCORE.  For each endpoint,
   the security context is composed of a "Common Context", a "Sender
   Context", and a "Recipient Context".

   The endpoints protect messages to send using the Sender Context and
   verify messages received using the Recipient Context, both contexts
   being derived from the Common Context and other data.  Clients and
   servers need to be able to retrieve the correct security context to
   use.


I believe it might be clarifying to specify that CoAP endpoints have always
bidirectional communications. If that is correct, then for each communication
each end point is both a "Sender" and a "Recipient" for its respective outbound
and inbound traffic. The 4 context are derived from a Common Context.

As security context are established to secure unidirectional communications,
maybe that would be easier to base the description on the unidirectional
communications rather than the end points. 

   An endpoint uses its Sender ID (SID) to derive its Sender Context,
   and the other endpoint uses the same ID, now called Recipient ID
   (RID), to derive its Recipient Context.  In communication between two
   endpoints, the Sender Context of one endpoint matches the Recipient
   Context of the other endpoint, and vice versa.  Thus, the two
   security contexts identified by the same IDs in the two endpoints are
   not the same, but they are partly mirrored.  Retrieval and use of the
   security context are shown in Figure 4.


"An endpoint uses its Sender ID (SID) to derive its Sender Context,"

I see the ID as mostly useful to the recipient in order to retrieve the
appropriated security context and decrypt the message. In other words, the
sender should know who it sends the message to and does not really need the SID
to match the security context.

I believe this should be clarified as the current text prevents Sender ID
collision, while collision should only be avoided on the receiver's side.


                 .-------------.           .-------------.
                 |  Common,    |           |  Common,    |
                 |  Sender,    |           |  Recipient, |
                 |  Recipient  |           |  Sender     |
                 '-------------'           '-------------'
                      Client                   Server
                         |                       |
   Retrieve context for  | OSCORE request:       |
    target resource      |   Token = Token1,     |
   Protect request with  |   kid = SID, ...      |
     Sender Context      +---------------------->| Retrieve context with
                         |                       |  RID = kid
                         |                       | Verify request with
                         |                       |  Recipient Context
                         | OSCORE response:      | Protect response with
                         |   Token = Token1, ... |  Sender Context
   Retrieve context with |<----------------------+
    Token = Token1       |                       |
   Verify request with   |                       |
    Recipient Context    |                       |

            Figure 4: Retrieval and Use of the Security Context


I might be helpful to clarify that Sender Context on both sides are not the
same context.

Security Context seems to be missing in the box.

It would also help to have in the figure, the relation between the Common
Security Context, the Sender Context and Recipient Context on both sides.


Selander, et al.        Expires January 27, 2019                [Page 8]

Internet-Draft                   OSCORE                        July 2018

   The Common Context contains the following parameters:

   o  AEAD Algorithm.  The COSE AEAD algorithm to use for encryption.

   o  Key Derivation Function.  The HMAC based HKDF [RFC5869] used to
      derive Sender Key, Recipient Key, and Common IV.

This is confusing to have a generic term such as KDF defined by a sup set of it
(HKDF). I believe that either the KDF is defined generic enough and later the
default value is set to HKDF with a specific hash function. Another alternative
could be to limited the scope of this parameter to HKDF Hash Function. 

   o  Master Secret.  Variable length, random byte string (see
      Section 12.3) used to derive traffic keys and IVs.

I believe that IVs is the Common IV.

   o  Master Salt.  Optional variable length byte string containing the
      salt used to derive traffic keys and IVs.

I believe that IVs is the Common IV.


   o  ID Context.  Optional variable length byte string providing
      additional information to identify the Common Context and to
      derive traffic keys and IVs.

   o  Common IV.  Byte string derived from Master Secret, Master Salt,
      and ID Context.  Length is determined by the AEAD Algorithm.

RFC8152 uses context IV. It is not clear to me how these two differ. I believe
some text should be added to explain how Common IV differs from the context IV.

It is unclear to me whether the Common Context is used for the two
bidirectional communications. If that is the case, I am reading that Common IV
and Sequence Number in the two directions will end up in IV collision. So Keys
needs to be unidirectional and different. 

   The Sender Context contains the following parameters:

   o  Sender ID.  Byte string used to identify the Sender Context, to
      derive traffic keys and IVs, and to assure unique nonces.  Maximum
      length is determined by the AEAD Algorithm.

   o  Sender Key. Byte string containing the symmetric key to protect
      messages to send.  Derived from Common Context and Sender ID.
      Length is determined by the AEAD Algorithm.

   o  Sender Sequence Number.  Non-negative integer used by the sender
      to protect requests and certain responses, e.g.  Observe
      notifications.  Used as 'Partial IV' [RFC8152] to generate unique
      nonces for the AEAD.  Maximum value is determined by the AEAD
      Algorithm.

   The Recipient Context contains the following parameters:

   o  Recipient ID.  Byte string used to identify the Recipient Context,
      to derive traffic keys and IVs, and to assure unique nonces.
      Maximum length is determined by the AEAD Algorithm.

   o  Recipient Key. Byte string containing the symmetric key to verify
      messages received.  Derived from Common Context and Recipient ID.
      Length is determined by the AEAD Algorithm.

   o  Replay Window (Server only).  The replay window to verify requests
      received.


Looking at the different contexts, maybe some text should be added to specify
that Sender ID and Recipient ID are equal for a given unidirectional
communication. The same occurs for Sender Key and Recipient Key.

I believe that Sender Sequence Number also needs to be present in the Recipient
Context in order to implement anti replay mechanism.

Sequence Number May be interpreted differently. I believe that interpretation
should also be part of the Common Security Context.

As mentioned above the contexts may probably be refactored with one Context per
unidirectional communication. 

Selander, et al.        Expires January 27, 2019                [Page 9]

Internet-Draft                   OSCORE                        July 2018

   All parameters except Sender Sequence Number and Replay Window are
   immutable once the security context is established.  An endpoint may
   free up memory by not storing the Common IV, Sender Key, and
   Recipient Key, deriving them when needed.  Alternatively, an endpoint
   may free up memory by not storing the Master Secret and Master Salt
   after the other parameters have been derived.

   Endpoints MAY operate as both client and server and use the same
   security context for those roles.  Independent of being client or
   server, the endpoint protects messages to send using its Sender
   Context, and verifies messages received using its Recipient Context.
   The endpoints MUST NOT change the Sender/Recipient ID when changing
   roles.  In other words, changing the roles does not change the set of
   keys to be used.

3.2.  Establishment of Security Context Parameters

   The parameters in the security context are derived from a small set
   of input parameters.  The following input parameters SHALL be pre-
   established:

   o  Master Secret

   o  Sender ID

   o  Recipient ID


I believe that Sender ID and Recipient ID could be the same value for a given
unidirectional communication. I believe that what is required her is the two
IDs used by the sessions. 

   The following input parameters MAY be pre-established.  In case any
   of these parameters is not pre-established, the default value
   indicated below is used:

   o  AEAD Algorithm

      *  Default is AES-CCM-16-64-128 (COSE algorithm encoding: 10)

   o  Master Salt

      *  Default is the empty byte string

I believe explicitly providing the string could help. There is always the
confusion with "\0" versus "". 

   o  Key Derivation Function (KDF)

      *  Default is HKDF SHA-256

   o  Replay Window Type and Size

      *  Default is DTLS-type replay protection with a window size of 32
         [RFC6347]

This section specifies Type and windows for the anti replay mechanism. This was
described as Replay Windows in the context description. 

Selander, et al.        Expires January 27, 2019               [Page 10]

Internet-Draft                   OSCORE                        July 2018

   All input parameters need to be known to and agreed on by both
   endpoints, but the replay window may be different in the two
   endpoints.  The way the input parameters are pre-established, is
   application specific.  Considerations of security context
   establishment are given in Section 12.2 and examples of deploying
   OSCORE in Appendix B.

3.2.1.  Derivation of Sender Key, Recipient Key, and Common IV

   The KDF MUST be one of the HMAC based HKDF [RFC5869] algorithms
   defined for COSE [RFC8152].

It might be better to consider HKDF instead of KDF and then just specify the
Hash function 

  HKDF SHA-256 is mandatory to implement.
   The security context parameters Sender Key, Recipient Key, and Common
   IV SHALL be derived from the input parameters using the HKDF, which
   consists of the composition of the HKDF-Extract and HKDF-Expand steps
   [RFC5869]:

      output parameter = HKDF(salt, IKM, info, L)

   where:

   o  salt is the Master Salt as defined above

   o  IKM is the Master Secret as defined above

   o  info is the serialization of a CBOR array consisting of:

      info = [
          id : bstr,
          id_context : bstr / nil,
          alg_aead : int / tstr,
          type : tstr,
          L : uint
      ]

bstr, nil, tstr are used for the first time here. Maybe a reference to 8152 may
be clarifying. 

   where:

   o  id is the Sender ID or Recipient ID when deriving keys and the
      empty byte string when deriving the Common IV.  The encoding is
      described in Section 5.

   o  id_context is the ID Context, or nil if ID Context is not
      provided.

   o  alg_aead is the AEAD Algorithm, encoded as defined in [RFC8152].

   o  type is "Key" or "IV".  The label is an ASCII string, and does not
      include a trailing NUL byte.

Selander, et al.        Expires January 27, 2019               [Page 11]

Internet-Draft                   OSCORE                        July 2018

   o  L is the size of the key/IV for the AEAD algorithm used, in bytes.

   For example, if the algorithm AES-CCM-16-64-128 (see Section 10.2 in
   [RFC8152]) is used, the integer value for alg_aead is 10, the value
   for L is 16 for keys and 13 for the Common IV.

   Note that [RFC5869] specifies that if the salt is not provided, it is
   set to a string of zeros.  For implementation purposes, not providing
   the salt is the same as setting the salt to the empty byte string.
   OSCORE sets the salt default value to empty byte string, which in
   [RFC5869] is converted to a string of zeroes (see Section 2.2 of
   [RFC5869]).


I believe that how Sender Key, Recipient Key, and Common IV are derived from
the output_parameters should be described as well.

Note that in this case I believe that Sender Key and Recipient Key are used for
the two unidirectional communications. In other words, the same key should be
used by the sender and the recipient of the same communication. The same Common
IV is used in both communications.  3.2.2.  Initial Sequence Numbers and
Replay Window

   The Sender Sequence Number is initialized to 0.  The supported types
   of replay protection and replay window length is application specific
   and depends on how OSCORE is transported, see Section 7.4.  The
   default is DTLS-type replay protection with a window size of 32
   initiated as described in Section 4.1.2.6 of [RFC6347].


This should be specified the same in the Context.


3.3.  Requirements on the Security Context Parameters

   To ensure unique Sender Keys, the quartet (Master Secret, Master
   Salt, ID Context, Sender ID) MUST be unique, i.e. the pair (ID
   Context, Sender ID) SHALL be unique in the set of all security
   contexts using the same Master Secret and Master Salt.  This means
   that Sender ID SHALL be unique in the set of all security contexts
   using the same Master Secret, Master Salt, and ID Context; such a
   requirement guarantees unique (key, nonce) pairs, which avoids nonce
   reuse.


I understand the use of SHALL and MUST as similar. If that is correct, It may
be better to use the same term throughout the document.

I believe that we would like to avoid that the same IV is being reused with the
same key. Any change in the inputs of the HMAC based KDF will result in a
different output. As such any change in the output will result in that
property. I suspect we would like to some parameters to remain wit the same
value, while some could be changed, and for that reason, we chose the Sender
ID. I believe the text could be clarified either on the reasoning behind or how
this should be operated. 

   Different methods can be used to assign Sender IDs: a protocol that
   allows the parties to negotiate locally unique identifiers, a trusted
   third party (e.g., [I-D.ietf-ace-oauth-authz]), or the identifiers
   can be assigned out-of-band.  The Sender IDs can be very short (note
   that the empty string is a legitimate value).  The maximum length of
   Sender ID in bytes equals the length of AEAD nonce minus 6.  For AES-
   CCM-16-64-128 the maximum length of Sender ID is 7 bytes.


I suspect those restriction coming from the COSE specification. If that is
correct, I believe it would be helpful to have a reference to that document.


   To simplify retrieval of the right Recipient Context, the Recipient
   ID SHOULD be unique in the sets of all Recipient Contexts used by an
   endpoint.  If an endpoint has the same Recipient ID with different
   Recipient Contexts, i.e. the Recipient Contexts are derived from
   different Common Contexts, then the endpoint may need to try multiple
   times before verifying the right security context associated to the
   Recipient ID.


Such collision could represent an attack where the attacker could in case a
collision is observed craft a packet that costs two time more computation than
a regular packet.

I might be wrong, but it seems that the ID is more important for the recipient.
Typically the sender can easily address Sender ID collision.   On the other
hand the cryptographic properties are based on the uniqueness of the Sender ID.
Maybe these could be considered with the Recipient ID in mind. 

Selander, et al.        Expires January 27, 2019               [Page 12]

Internet-Draft                   OSCORE                        July 2018

   The ID Context is used to distinguish between security contexts.  The
   methods used for assigning Sender ID can also be used for assigning
   the ID Context.  Additionally, the ID Context can be generated by the
   client (see Appendix B.2).  ID Context can be arbitrarily long.

4.  Protected Message Fields

4.1.  CoAP Options

4.1.1.  Inner Options
4.1.2.  Outer Options
4.1.3.  Special Options
4.1.3.1.  Max-Age
4.1.3.2.  Uri-Host and Uri-Port
4.1.3.3.  Proxy-Uri
4.1.3.4.  The Block Options
4.1.3.4.1.  Inner Block Options
4.1.3.4.2.  Outer Block Options
4.1.3.5.  Observe
4.1.3.5.1.  Registrations and Cancellations
4.1.3.5.2.  Notifications

   If the server accepts an Observe registration, a Partial IV MUST be
   included in all notifications (both successful and error), except for
   the first one where Partial IV MAY be omitted.  To protect against
   replay, the client SHALL maintain a Notification Number for each
   Observation it registers.  The Notification Number is a non-negative
   integer containing the largest Partial IV of the received
   notifications for the associated Observe registration.  Further
   details of replay protection of notifications are specified in
   Section 7.4.1.

   For notifications, the Inner Observe value MUST be empty (see
   Section 3.2 of [RFC7252]).  The Outer Observe in a notification is

Selander, et al.        Expires January 27, 2019               [Page 20]

Internet-Draft                   OSCORE                        July 2018

   needed for intermediary nodes to allow multiple responses to one
   request, and may be set to the value of Observe in the original CoAP
   message.  The client performs ordering of notifications and replay
   protection by comparing their Partial IVs and SHALL ignore the outer
   Observe value.

   If the client receives a response to an Observe request without an
   Inner Observe option, then it verifies the response as a non-Observe
   response, as specified in Section 8.4.  If the client receives a
   response to a non-Observe request with an Inner Observe option, then
   it stops processing the message, as specified in Section 8.4.

   A client MUST consider the notification with the highest Partial IV
   as the freshest, regardless of the order of arrival.  In order to
   support existing Observe implementations the OSCORE client
   implementation MAY set the Observe value to the three least
   significant bytes of the Partial IV; such an implementation needs to
   make sure that the Observe value for an observe notification without
   Partial IV is smaller than a notification with Partial IV.


This section discuss the behavior regarding the sequence number. While the
sequence number and the partial IV have the same value, I am wondering if it
would not be more appropriated to mention the sequence number value is provided
by the partial IV, and then use the sequence number variable to describe anti
replay. 

4.1.3.6.  No-Response
4.1.3.7.  OSCORE
4.2.  CoAP Header Fields and Payload
4.3.  Signaling Messages
5.  The COSE Object
5.1.  Kid Context
5.2.  Nonce
5.3.  Plaintext
5.4.  Additional Authenticated Data
6.  OSCORE Header Compression
6.1.  Encoding of the OSCORE Option Value
6.2.  Encoding of the OSCORE Payload
6.3.  Examples of Compressed COSE Objects
7.2.  Sequence Numbers
7.2.1.  Maximum Sequence Number
7.3.  Freshness
7.4.  Replay Protection

   In order to protect from replay of requests, the server's Recipient
   Context includes a Replay Window.  A server SHALL verify that a
   Partial IV received in the COSE object has not been received before.
   If this verification fails the server SHALL stop processing the
   message, and MAY optionally respond with a 4.01 Unauthorized error
   message.  Also, the server MAY set an Outer Max-Age option with value
   zero, to inform any intermediary that the response is not to be
   cached.  The diagnostic payload MAY contain the "Replay detected"
   string.  The size and type of the Replay Window depends on the use
   case and the protocol with which the OSCORE message is transported.
   In case of reliable and ordered transport from endpoint to endpoint,
   e.g.  TCP, the server MAY just store the last received Partial IV and
   require that newly received Partial IVs equals the last received
   Partial IV + 1.  However, in case of mixed reliable and unreliable
   transports and where messages may be lost, such a replay mechanism

Selander, et al.        Expires January 27, 2019               [Page 33]

Internet-Draft                   OSCORE                        July 2018

   may be too restrictive and the default replay window be more suitable
   (see Section 3.2.2).

I am reading the anti replay mechanism used as very specific. Incrementing
Partial IV is one way to perform anti-replay protection. It could be the way
OSCORE performs anti replay protection but this is not the only way to do. In
addition, incrementing the Partial IV result in the IV being predictible. This
condition may not be sufficient as some algorithm may require the IV being
unpredictable. I believe Anti-Replay Type shoudl be configurable, and some note
shoudl be added to comply with the encryption being used. 

   Responses (with or without Partial IV) are protected against replay
   as they are bound to the request and the fact that only a single
   response is accepted.  Note that the Partial IV is not used for
   replay protection in this case.

   The operation of validating the Partial IV and updating the replay
   protection MUST be atomic.

7.4.1.  Replay Protection of Notifications
7.5.  Losing Part of the Context State

   To prevent reuse of an AEAD nonce with the same key, or from
   accepting replayed messages, an endpoint needs to handle the
   situation of losing rapidly changing parts of the context, such as
   the request Token, Sender Sequence Number, Replay Window, and
   Notification Numbers.  These are typically stored in RAM and
   therefore lost in the case of an unplanned reboot.

   After boot, an endpoint can either use a persistently stored complete
   or partial security context, or establish a new security context with
   each endpoint it communicates with.  However, establishing a fresh
   security context may have a non-negligible cost in terms of, e.g.,
   power consumption.

   If the endpoint uses a persistently stored partial security context,
   it MUST NOT reuse a previous Sender Sequence Number and MUST NOT

Selander, et al.        Expires January 27, 2019               [Page 34]

Internet-Draft                   OSCORE                        July 2018

   accept previously received messages.  Some ways to achieve this are
   described in the following sections.

7.5.1.  Sequence Number

   To prevent reuse of Sender Sequence Numbers, an endpoint may perform
   the following procedure during normal operations:

   o  Before using a Sender Sequence Number that is evenly divisible by
      K, where K is a positive integer, store the Sender Sequence Number
      in persistent memory.  After boot, the endpoint initiates the
      Sender Sequence Number to the value stored in persistent memory +
      K.  Storing to persistent memory can be costly.  The value K gives
      a trade-off between the number of storage operations and efficient
      use of Sender Sequence Numbers.


I have hard time reading the section above. I guess K is a parameter known by
OSCORE. My understanding is that SSN=0 ... K-1 are stored in persistent memory.
After boot SSN = SSN + K.

I might be wrong but as storage in persistent memory is costly. Given K a
parameter defined by the implementation. I would rather store F = floor(SSN / K
). SSN = F.K + ssn with ssn = 0... K-1, so a storage operation happens every K.
In case of reboot, SSN = (F + 1).K + ssn.

This ends in a jump of maximum K and anti replay must be able to handle this.


7.5.2.  Replay Window
7.5.3.  Replay of Notifications
8.  Processing

   This section describes the OSCORE message processing.  Additional
   processing for Observe or Block-wise are described in subsections.

   Note that, analogously to [RFC7252] where the Token and source/
   destination pair are used to match a response with a request, both
   endpoints MUST keep the association (Token, {Security Context,

Selander, et al.        Expires January 27, 2019               [Page 35]

Internet-Draft                   OSCORE                        July 2018

   Partial IV of the request}), in order to be able to find the Security
   Context and compute the AAD to protect or verify the response.  The
   association MAY be forgotten after it has been used to successfully
   protect or verify the response, with the exception of Observe
   processing, where the association MUST be kept as long as the
   Observation is active.

8.1.  Protecting the Request

   Given a CoAP request, the client SHALL perform the following steps to
   create an OSCORE request:

   1.  Retrieve the Sender Context associated with the target resource.

   2.  Compose the Additional Authenticated Data and the plaintext, as
       described in Sections 5.3 and 5.4.

   3.  Encode the Partial IV (Sender Sequence Number in network byte
       order) and increment the Sender Sequence Number by one.

I believe this depends on the Anti-replay type.

  Compute
       the AEAD nonce from the Sender ID, Common IV, and Partial IV as
       described in Section 5.2.

   4.  Encrypt the COSE object using the Sender Key. Compress the COSE
       Object as specified in Section 6.

   5.  Format the OSCORE message according to Section 4.  The OSCORE
       option is added (see Section 4.1.2).

8.2.  Verifying the Request

   A server receiving a request containing the OSCORE option SHALL
   perform the following steps:

   1.  Discard Code and all class E options (marked in Figure 5 with 'x'
       in column E) present in the received message.  For example, an
       If-Match Outer option is discarded, but an Uri-Host Outer option
       is not discarded.

   2.  Decompress the COSE Object (Section 6) and retrieve the Recipient
       Context associated with the Recipient ID in the 'kid' parameter,
       additionally using the 'kid context', if present.  If either the
       decompression or the COSE message fails to decode, or the server
       fails to retrieve a Recipient Context with Recipient ID
       corresponding to the 'kid' parameter received, then the server
       SHALL stop processing the request.

       *  If either the decompression or the COSE message fails to
          decode, the server MAY respond with a 4.02 Bad Option error

Selander, et al.        Expires January 27, 2019               [Page 36]

Internet-Draft                   OSCORE                        July 2018

          message.  The server MAY set an Outer Max-Age option with
          value zero.  The diagnostic payload SHOULD contain the string
          "Failed to decode COSE".

       *  If the server fails to retrieve a Recipient Context with
          Recipient ID corresponding to the 'kid' parameter received,
          the server MAY respond with a 4.01 Unauthorized error message.
          The server MAY set an Outer Max-Age option with value zero.
          The diagnostic payload SHOULD contain the string "Security
          context not found".

   3.  Verify the 'Partial IV' parameter using the Replay Window, as
       described in Section 7.4.

My understanding is that the Partial IV value has not been authenticated. Thus
I believe this step mostly consists in discarding packets with irrelevant
Partial IV values. Here irrelevant are limited to repeated sequence numbers
that is too say known replayed packets. 

   4.  Compose the Additional Authenticated Data, as described in
       Section 5.4.

   5.  Compute the AEAD nonce from the Recipient ID, Common IV, and the
       'Partial IV' parameter, received in the COSE Object.

   6.  Decrypt the COSE object using the Recipient Key, as per [RFC8152]
       Section 5.3.  (The decrypt operation includes the verification of
       the integrity.)

       *  If decryption fails, the server MUST stop processing the
          request and MAY respond with a 4.00 Bad Request error message.
          The server MAY set an Outer Max-Age option with value zero.
          The diagnostic payload MAY contain the "Decryption failed"
          string.

       *  If decryption succeeds, update the Replay Window, as described
          in Section 7.

   7.  Add decrypted Code, options, and payload to the decrypted
       request.  The OSCORE option is removed.

   8.  The decrypted CoAP request is processed according to [RFC7252].

8.2.1.  Supporting Block-wise
8.3.  Protecting the Response

   If a CoAP response is generated in response to an OSCORE request, the
   server SHALL perform the following steps to create an OSCORE
   response.  Note that CoAP error responses derived from CoAP
   processing (step 8 in Section 8.2) are protected, as well as
   successful CoAP responses, while the OSCORE errors (steps 2, 3, and 6
   in Section 8.2) do not follow the processing below, but are sent as
   simple CoAP responses, without OSCORE processing.

   1.  Retrieve the Sender Context in the Security Context associated
       with the Token.

   2.  Compose the Additional Authenticated Data and the plaintext, as
       described in Sections 5.3 and 5.4.

   3.  Compute the AEAD nonce as described in Section 5.2:

       *  Either use the nonce from the request, or

       *  Encode the Partial IV (Sender Sequence Number in network byte
          order) and increment the Sender Sequence Number by one.

Again this is very specific.

I am reading that SSN is incremented after the Partial IV is generated. It
seems to me that the Partial IV should reflect the SSN, and as such being
encoded after the incrementation of the SSN. 
          Compute the AEAD nonce from the Sender ID, Common IV, and
          Partial IV.

   4.  Encrypt the COSE object using the Sender Key. Compress the COSE
       Object as specified in Section 6.  If the AEAD nonce was
       constructed from a new Partial IV, this Partial IV MUST be
       included in the message.  If the AEAD nonce from the request was
       used, the Partial IV MUST NOT be included in the message.

   5.  Format the OSCORE message according to Section 4.  The OSCORE
       option is added (see Section 4.1.2).

8.3.1.  Supporting Observe
8.4.  Verifying the Response
9.  Web Linking
10.  CoAP-to-CoAP Forwarding Proxy
11.  HTTP Operations
11.2.  CoAP-to-HTTP Mapping
11.3.  HTTP-to-CoAP Mapping
11.4.  HTTP Endpoints
11.5.  Example: HTTP Client and CoAP Server
11.6.  Example: CoAP Client and HTTP Server
12.  Security Considerations

   An overview of the security properties is given in Appendix D.

12.1.  End-to-end Protection

   In scenarios with intermediary nodes such as proxies or gateways,
   transport layer security such as (D)TLS only protects data hop-by-
   hop.  As a consequence, the intermediary nodes can read and modify
   any information.  The trust model where all intermediary nodes are
   considered trustworthy is problematic, not only from a privacy
   perspective, but also from a security perspective, as the
   intermediaries are free to delete resources on sensors and falsify
   commands to actuators (such as "unlock door", "start fire alarm",
   "raise bridge").  Even in the rare cases where all the owners of the
   intermediary nodes are fully trusted, attacks and data breaches make
   such an architecture brittle.

   (D)TLS protects hop-by-hop the entire message.  OSCORE protects end-
   to-end all information that is not required for proxy operations (see
   Section 4).  (D)TLS and OSCORE can be combined, thereby enabling end-
   to-end security of the message payload, in combination with hop-by-
   hop protection of the entire message, during transport between end-
   point and intermediary node.  In particular when OSCORE is used with

Selander, et al.        Expires January 27, 2019               [Page 47]

Internet-Draft                   OSCORE                        July 2018

   HTTP, the additional TLS protection of HTTP hops is recommended, e.g.
   between an HTTP endpoint and a proxy translating between HTTP and
   CoAP.


I see that (D)TLS provides privacy to OSCORE communication, while OSCORE
protects the data. 

   Applications need to consider that certain message fields and
   messages types are not protected end-to-end and may be spoofed or
   manipulated.  The consequences of unprotected message fields are
   analyzed in Appendix D.4.

12.2.  Security Context Establishment


Wouldn't agreement preferred to established ?


   The use of COSE_Encrypt0 and AEAD to protect messages as specified in
   this document requires an established security context.  The method
   to establish the security context described in Section 3.2 is based
   on a common Master Secret and unique Sender IDs.  The necessary input
   parameters may be pre-established or obtained using a key
   establishment protocol augmented with establishment of Sender/
   Recipient ID such as the OSCORE profile of the ACE framework
   [I-D.ietf-ace-oscore-profile].  Such a procedure must ensure that the
   requirements of the security context parameters for the intended use
   are complied with (see Section 3.3) and also in error situations.  It
   is recommended to use a key establishment protocol which provides
   forward secrecy whenever possible.  Considerations for deploying
   OSCORE with a fixed Master Secret are given in Appendix B.

12.3.  Master Secret

   OSCORE uses HKDF [RFC5869] and the established input parameters to
   derive the security context.  The required properties of the security
   context parameters are discussed in Section 3.3, in this section we
   focus on the Master Secret.  HKDF denotes in this specification the
   composition of the expand and extract functions as defined in
   [RFC5869] and the Master Secret is used as Input Key Material (IKM).

   Informally, HKDF takes as source an IKM containing some good amount
   of randomness but not necessarily distributed uniformly (or for which
   an attacker has some partial knowledge) and derive from it one or
   more cryptographically strong secret keys [RFC5869].

rfc4086 may be a usefull reference.


   Therefore, the main requirement for the OSCORE Master Secret, in
   addition to being secret, is that it is has a good amount of
   randomness.  The selected key establishment schemes must ensure that
   the necessary properties for the Master Secret are fulfilled.  For
   pre-shared key deployments and key transport solutions such as
   [I-D.ietf-ace-oscore-profile], the Master Secret can be generated
   offline using a good random number generator.

Selander, et al.        Expires January 27, 2019               [Page 48]

Internet-Draft                   OSCORE                        July 2018

12.4.  Replay Protection

   Replay attacks need to be considered in different parts of the
   implementation.  Most AEAD algorithms require a unique nonce for each
   message, for which the sender sequence numbers in the COSE message
   field 'Partial IV' is used.  If the recipient accepts any sequence
   number larger than the one previously received, then the problem of
   sequence number synchronization is avoided.

Do we have cases where the Partial IV represents the LSB of the SSN ? If that
is the case, if more then len(Partial IV) packet have been dropped. The two
peers may have hard time to resynchronize their SSN. This may happen in a
communication with a lot of notifications. In a query-response paradigm, the
sender may have some hints when the packet has been receieved or not. 

With reliable transport,
   it may be defined that only messages with sequence number which are
   equal to previous sequence number + 1 are accepted.  An adversary may
   try to induce a device reboot for the purpose of replaying a message
   (see Section 7.5).

   Note that sharing a security context between servers may open up for
   replay attacks, for example if the replay windows are not
   synchronized.

12.5.  Client Aliveness

   A verified OSCORE request enables the server to verify the identity
   of the entity who generated the message.  However, it does not verify
   that the client is currently involved in the communication, since the
   message may be a delayed delivery of a previously generated request
   which now reaches the server.  To verify the aliveness of the client
   the server may use the Echo option in the response to a request from
   the client (see [I-D.ietf-core-echo-request-tag]).

12.6.  Cryptographic Considerations

   The maximum sender sequence number is dependent on the AEAD
   algorithm.  The maximum sender sequence number is 2^40 - 1, or any
   algorithm specific lower limit, after which a new security context
   must be generated.  The mechanism to build the nonce (Section 5.2)
   assumes that the nonce is at least 56 bits, and the Partial IV is at
   most 40 bits.  The mandatory-to-implement AEAD algorithm AES-CCM-
   16-64-128 is selected for compatibility with CCM*.

   In order to prevent cryptanalysis when the same plaintext is
   repeatedly encrypted by many different users with distinct keys, the
   nonce is formed by mixing the sequence number with a secret per-
   context initialization vector (Common IV) derived along with the keys
   (see Section 3.1 of [RFC8152]), and by using a Master Salt in the key
   derivation (see [MF00] for an overview).  The Master Secret, Sender
   Key, Recipient Key, and Common IV must be secret, the rest of the
   parameters may be public.  The Master Secret must have a good amount
   of randomness (see Section 12.3).

Selander, et al.        Expires January 27, 2019               [Page 49]

Internet-Draft                   OSCORE                        July 2018

12.7.  Message Segmentation

   The Inner Block options enable the sender to split large messages
   into OSCORE-protected blocks such that the receiving endpoint can
   verify blocks before having received the complete message.  The Outer
   Block options allow for arbitrary proxy fragmentation operations that
   cannot be verified by the endpoints, but can by policy be restricted
   in size since the Inner Block options allow for secure fragmentation
   of very large messages.  A maximum message size (above which the
   sending endpoint fragments the message and the receiving endpoint
   discards the message, if complying to the policy) may be obtained as
   part of normal resource discovery.

12.8.  Privacy Considerations

   Privacy threats executed through intermediary nodes are considerably
   reduced by means of OSCORE.  End-to-end integrity protection and
   encryption of the message payload and all options that are not used
   for proxy operations, provide mitigation against attacks on sensor
   and actuator communication, which may have a direct impact on the
   personal sphere.

   The unprotected options (Figure 5) may reveal privacy sensitive
   information, see Appendix D.4.  CoAP headers sent in plaintext allow,
   for example, matching of CON and ACK (CoAP Message Identifier),
   matching of request and responses (Token) and traffic analysis.
   OSCORE does not provide protection for HTTP header fields which are
   not both CoAP-mappable and class E.  The HTTP message fields which
   are visible to on-path entity are only used for the purpose of
   transporting the OSCORE message, whereas the application layer
   message is encoded in CoAP and encrypted.

   COSE message fields, i.e. the OSCORE option, may reveal information
   about the communicating endpoints.  E.g. 'kid' and 'kid context',
   which are intended to help the server find the right context, may
   reveal information about the client.  Tracking 'kid' and 'kid
   context' to one server may be used for correlating requests from one
   client.

   Unprotected error messages reveal information about the security
   state in the communication between the endpoints.  Unprotected
   signaling messages reveal information about the reliable transport
   used on a leg of the path.  Using the mechanisms described in
   Section 7.5 may reveal when a device goes through a reboot.  This can
   be mitigated by the device storing the precise state of sender
   sequence number and replay window on a clean shutdown.

Selander, et al.        Expires January 27, 2019               [Page 50]

Internet-Draft                   OSCORE                        July 2018

   The length of message fields can reveal information about the
   message.  Applications may use a padding scheme to protect against
   traffic analysis.

13.  IANA Considerations
14.  References
Appendix A.  Scenario Examples
Appendix B.  Deployment Examples
B.1.  Master Secret Used Once

   An application may derive a security context once and use it for the
   lifetime of a device.  For many IoT deployments, a 128 bit uniformly
   random Master Key is sufficient for encrypting all data exchanged
   with the IoT device.  This specification describes techniques for
   persistent storage of the security context and synchronization of
   sequence numbers (see Section 7.5) to ensure that security is
   maintained with the existing security context.

B.2.  Master Secret Used Multiple Times

   Section 12.2 recommends the use of a key establishment protocol
   providing forward secrecy of the Master Secret.

I believe that forward secrecy is a property associated to the kex. I am
reading it as associated to the Master Secret. That said, English is not my
native language. 
   An application which does not require forward secrecy may allow
   multiple security contexts to be derived from one Master Secret.  The
   requirements on the security context parameters must be fulfilled
   (Section 3.3) even if the client or server is rebooted,
   recommissioned or in error cases.

   This section gives an example of an application allowing new security
   contexts to be derived from input parameters pre-established between
   client and server for this purpose: in particular Master Secret,
   Master Salt and Sender/Recipient ID (see Section 3.2):

   o  The client generates an ID Context which has previously not been
      used with the pre-established input parameters and derives a new
      security context.  ID context may be pseudo-random and large for

Selander, et al.        Expires January 27, 2019               [Page 62]

Internet-Draft                   OSCORE                        July 2018

      stochastic uniqueness, but care must be taken e.g. to avoid re-use
      of the same seed for random number generation.  Using this new
      security context, the client generates an OSCORE request with (kid
      context, kid) = (ID Context, Sender ID) in the OSCORE option.

   o  The server receiving such an OSCORE request with kid matching the
      Recipient ID of pre-established input parameters, but with a new
      kid context, derives the security context using ID Context = kid
      context.  If the message verifies then a new security context with
      this ID Context is stored in the server, and used in the response.
      Further requests with the same (kid context, kid) are verified
      with this security context.

   As an alternative procedure to reduce the subsequent overhead in
   requests due to kid context, the verification of a message with a new
   ID Context may trigger the server to generate a new kid to replace
   the Client Sender ID in future requests.  A client may e.g. indicate
   support for such a procedure by requesting a special well-known URI
   and receive the new kid in the response, which together with the
   input parameters and the ID context is used to derive the new
   security context which may be identified only by its kid.  The
   details are out of scope for this specification.

   The procedures may be complemented with the use of the Echo option
   for verifying the aliveness of the client requesting a new security
   context.

Appendix C.  Test Vectors
Appendix D.  Overview of Security Properties

D.1.  Supporting Proxy Operations

   CoAP is designed to work with intermediaries reading and/or changing
   CoAP message fields to perform supporting operations in constrained
   environments, e.g. forwarding and cross-protocol translations.

   Securing CoAP on transport layer protects the entire message between
   the endpoints in which case CoAP proxy operations are not possible.
   In order to enable proxy operations, security on transport layer
   needs to be terminated at the proxy in which case the CoAP message in
   its entirety is unprotected in the proxy.

   Requirements for CoAP end-to-end security are specified in
   [I-D.hartke-core-e2e-security-reqs].  The client and server are
   assumed to be honest, but proxies and gateways are only trusted to
   perform their intended operations.

I expected after 'but' something saying the proxies are not trusted, but t
seems that everyone is honest here. maybe we should replace: OLD but proxies
and gateways are only trusted to
   perform their intended operations.
NEW:
and proxies and gateways are trusted to
   perform their intended operations.

That the server is honest does not means that the node terminating the session
is the server.... 
  Forwarding is specified in
   Section 2.2.1 of [I-D.hartke-core-e2e-security-reqs].  HTTP-CoAP
   translation is specified in [RFC8075].  Intermediaries translating
   between different transport layers are intended to perform just that.

   By working at the CoAP layer, OSCORE enables different CoAP message
   fields to be protected differently, which allows message fields
   required for proxy operations to be available to the proxy while
   message fields intended for the other endpoint remain protected.  In
   the remainder of this section we analyze how OSCORE protects the
   protected message fields and the consequences of message fields
   intended for proxy operation being unprotected.

This text seems clear to me. Maybe the last paragraph could be sufficient.

D.2.  Protected Message Fields

   Protected message fields are included in the Plaintext (Section 5.3)
   and the Additional Authenticated Data (Section 5.4) of the
   COSE_Encrypt0 object and encrypted using an AEAD algorithm.

   OSCORE depends on a pre-established random Master Secret
   (Section 12.3) used to derive encryption keys, and a construction for
   making (key, nonce) pairs unique (Appendix D.3).  Assuming this is
   true, and the keys are used for no more data than indicated in
   Section 7.2.1, OSCORE should provide the following guarantees:

   o  Confidentiality: An attacker should not be able to determine the
      plaintext contents of a given OSCORE message or determine that
      different plaintexts are related (Section 5.3).

Selander, et al.        Expires January 27, 2019               [Page 74]

Internet-Draft                   OSCORE                        July 2018

   o  Integrity: An attacker should not be able to craft a new OSCORE
      message with protected message fields different from an existing
      OSCORE message which will be accepted by the receiver.

   o  Request-response binding: An attacker should not be able to make a
      client match a response to the wrong request.

   o  Non-replayability: An attacker should not be able to cause the
      receiver to accept a message which it has previously received and
      accepted.

   In the above, the attacker is anyone except the endpoints, e.g. a
   compromised intermediary.  Informally, OSCORE provides these
   properties by AEAD-protecting the plaintext with a strong key and
   uniqueness of (key, nonce) pairs.  AEAD encryption [RFC5116] provides
   confidentiality and integrity for the data.  Response-request binding
   is provided by including the kid and Partial IV of the request in the
   AAD of the response.  Non-replayability of requests and notifications
   is provided by using unique (key, nonce) pairs and a replay
   protection mechanism (application dependent, see Section 7.4).

   OSCORE is susceptible to a variety of traffic analysis attacks based
   on observing the length and timing of encrypted packets.  OSCORE does
   not provide any specific defenses against this form of attack but the
   application may use a padding mechanism to prevent an attacker from
   directly determine the length of the padding.  However, information
   about padding may still be revealed by side-channel attacks observing
   differences in timing.

D.3.  Uniqueness of (key, nonce)

   In this section we show that (key, nonce) pairs are unique as long as
   the requirements in Sections 3.3 and 7.2.1 are followed.

   Fix a Common Context (Section 3.1) and an endpoint, called the
   encrypting endpoint.  An endpoint may alternate between client and
   server roles, but each endpoint always encrypts with the Sender Key
   of its Sender Context.  Sender Keys are (stochastically) unique since
   they are derived with HKDF using unique Sender IDs, so messages
   encrypted by different endpoints use different keys.  It remains to
   prove that the nonces used by the fixed endpoint are unique.

   Since the Common IV is fixed, the nonces are determined by a Partial
   IV (PIV) and the Sender ID of the endpoint generating that Partial IV
   (ID_PIV).  The nonce construction (Section 5.2) with the size of the
   ID_PIV (S) creates unique nonces for different (ID_PIV, PIV) pairs.
   There are two cases:

Selander, et al.        Expires January 27, 2019               [Page 75]

Internet-Draft                   OSCORE                        July 2018

   A.  For requests, and responses with Partial IV (e.g.  Observe
   notifications):

   o  ID_PIV = Sender ID of the encrypting endpoint

   o  PIV = current Partial IV of the encrypting endpoint

   Since the encrypting endpoint steps the Partial IV for each use, the
   nonces used in case A are all unique as long as the number of
   encrypted messages is kept within the required range (Section 7.2.1).

   B.  For responses without Partial IV (e.g. single response to a
   request):

   o  ID_PIV = Sender ID of the endpoint generating the request

   o  PIV = Partial IV of the request

   Since the Sender IDs are unique, ID_PIV is different from the Sender
   ID of the encrypting endpoint.  Therefore, the nonces in case B are
   different compared to nonces in case A, where the encrypting endpoint
   generated the Partial IV.  Since the Partial IV of the request is
   verified for replay (Section 7.4) associated to this Recipient
   Context, PIV is unique for this ID_PIV, which makes all nonces in
   case B distinct.

D.4.  Unprotected Message Fields

   This section lists and discusses issues with unprotected message
   fields.

D.4.1.  CoAP Header Fields

   o  Version.  The CoAP version [RFC7252] is not expected to be
      sensitive to disclose.  Currently there is only one CoAP version
      defined.  A change of this parameter is potentially a denial-of-
      service attack.  Future versions of CoAP need to analyze attacks
      to OSCORE protected messages due to an adversary changing the CoAP
      version.

   o  Token/Token Length.  The Token field is a client-local identifier
      for differentiating between concurrent requests [RFC7252].  An
      eavesdropper reading the token can match requests to responses
      which can be used in traffic analysis.  In particular this is true
      for notifications, where multiple responses are matched with one
      request.  CoAP proxies are allowed to change Token and Token
      Length between UDP hops.  However, modifications of Token and
      Token Length during a UDP hop may become a denial-of-service

Selander, et al.        Expires January 27, 2019               [Page 76]

Internet-Draft                   OSCORE                        July 2018

      attack, since it may prevent the client to identify to which
      request the response belongs or to find the correct information to
      verify integrity of the response.

I am reading the text as. When the attacker is on-path, a long Token does not
prevents the attack based on a spoofed response. However, for an attacker that
is not on path, the attacker needs to guess the Token, and this can be
mitigated (partially) by increasing the Token size.  Note that in the latest
case, a long Token should not be seen as a replacement for cryptographic
protection of the message. 

   o  Code.  The Outer CoAP Code of an OSCORE message is POST or FETCH
      for requests with corresponding response codes.  The use of FETCH
      reveals no more than what is revealed by the Outer Observe option.
      Changing the Outer Code may be a denial-of-service attack by
      causing errors in the proxy processing.

   o  Type/Message ID.  The Type/Message ID fields [RFC7252] reveal
      information about the UDP transport binding, e.g. an eavesdropper
      reading the Type or Message ID gain information about how UDP
      messages are related to each other.  CoAP proxies are allowed to
      change Type and Message ID.  These message fields are not present
      in CoAP over TCP [RFC8323], and does not impact the request/
      response message.  A change of these fields in a UDP hop is a
      denial-of-service attack.  By sending an ACK, an attacker can make
      the endpoint believe that the other endpoint received the previous
      message.  By sending a RST, an attacker may be able to cancel an
      observation, make one endpoint believe the other endpoint is
      alive, or make one endpoint endpoint believe that the other
      endpoint is missing some context.  By changing a NON to a CON, the
      attacker can cause the receiving endpoint to respond to messages
      for which no response was requested.

   o  Length.  This field contain the length of the message [RFC8323]
      which may be used for traffic analysis.  These message fields are
      not present in CoAP over UDP, and does not impact the request/
      response message.  A change of Length is a denial-of-service
      attack similar to changing TCP header fields.

D.4.2.  CoAP Options

   o  Max-Age. The Outer Max-Age is set to zero to avoid unnecessary
      caching of OSCORE error responses.  Changing this value thus may
      cause unnecessary caching.  No additional information is carried
      with this option.

   o  Proxy-Uri/Proxy-Scheme.  These options are used in forward proxy
      deployments.  With OSCORE, the Proxy-Uri option does not contain
      the Uri-Path/Uri-Query parts of the URI.  The other parts of
      Proxy-Uri cannot be protected since they are allowed to be changed
      by a forward proxy.  The server can verify what scheme is used in
      the last hop, but not what was requested by the client or what was
      used in previous hops.

Selander, et al.        Expires January 27, 2019               [Page 77]

Internet-Draft                   OSCORE                        July 2018

   o  Uri-Host/Uri-Port.  In forward proxy deployments, the Uri-Host/
      Uri-Port may be changed by an adversary, and the application needs
      to handle the consequences of that (see Section 4.1.3.2).  The
      Uri-Host may either be omitted, reveal information equivalent to
      that of the IP address or more privacy-sensitive information,
      which is discouraged.

   o  Observe.  The Outer Observe option is intended for a proxy to
      support forwarding of Observe messages, but is ignored by the
      endpoints since the Inner Observe determines the processing in the
      endpoints.  Since the Partial IV provides absolute ordering of
      notifications it is not possible for an intermediary to spoof
      reordering (see Section 4.1.3.5).  The absence of Partial IV,
      since only allowed for the first notification, does not prevent
      correct ordering of notifications.  The size and distributions of
      notifications over time may reveal information about the content
      or nature of the notifications.  Cancellations (Section 4.1.3.5.1)
      are not bound to the corresponding registrations in the same way
      responses are bound to requests in OSCORE (see Appendix D.2), but
      that does not open up for attacks based on mismatched
      cancellations, since [RFC7641] specifies that for cancellations to
      be accepted, all options except for ETags MUST be the same (see
      Section 3.6 of [RFC7641]).  For different target resources, the
      OSCORE option is different, and even if the Token is modified to
      match a different observation, such a cancellation would not be
      accepted.

   o  Block1/Block2/Size1/Size2.  The Outer Block options enables
      fragmentation of OSCORE messages in addition to segmentation
      performed by the Inner Block options.  The presence of these
      options indicates a large message being sent and the message size
      can be estimated and used for traffic analysis.  Manipulating
      these options is a potential denial-of-service attack, e.g.
      injection of alleged Block fragments.  The specification of a
      maximum size of message, MAX_UNFRAGMENTED_SIZE
      (Section 4.1.3.4.2), above which messages will be dropped, is
      intended as one measure to mitigate this kind of attack.

   o  No-Response.  The Outer No-Response option is used to support
      proxy functionality, specifically to avoid error transmissions
      from proxies to clients, and to avoid bandwidth reduction to
      servers by proxies applying congestion control when not receiving
      responses.  Modifying or introducing this option is a potential
      denial-of-service attack against the proxy operations, but since
      the option has an Inner value its use can be securely agreed
      between the endpoints.  The presence of this option is not
      expected to reveal any sensitive information about the message
      exchange.

Selander, et al.        Expires January 27, 2019               [Page 78]

Internet-Draft                   OSCORE                        July 2018

   o  OSCORE.  The OSCORE option contains information about the
      compressed COSE header.  Changing this field may cause OSCORE
      verification to fail.

D.4.3.  Error and Signaling Messages

   Error messages occurring during CoAP processing are protected end-to-
   end.  Error messages occurring during OSCORE processing are not
   always possible to protect, e.g. if the receiving endpoint cannot
   locate the right security context.  For this setting, unprotected
   error messages are allowed as specified to prevent extensive
   retransmissions.  Those error messages can be spoofed or manipulated,
   which is a potential denial-of-service attack.

   Signaling messages used in CoAP over TCP [RFC8323] are intended to be
   hop-by-hop; spoofing signaling messages can be used as a denial-of-
   service attack of a TCP connection.

D.4.4.  HTTP Message Fields

   In contrast to CoAP, where OSCORE does not protect header fields to
   enable CoAP-CoAP proxy operations, the use of OSCORE with HTTP is
   restricted to transporting a protected CoAP message over an HTTP hop.
   Any unprotected HTTP message fields may reveal information about the
   transport of the OSCORE message and enable various denial-of-service
   attacks.  It is recommended to additionally use TLS [RFC5246] for
   HTTP hops, which enables encryption and integrity protection of
   headers, but still leaves some information for traffic analysis.

Appendix E.  CDDL Summary



From nobody Tue Jul 31 10:10:10 2018
Return-Path: 
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AB6130F17; Tue, 31 Jul 2018 10:09:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Matthew Miller 
To: 
Cc: tls@ietf.org, ietf@ietf.org, draft-ietf-tls-tls13-vectors.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153305699627.3135.8054434413462324752@ietfa.amsl.com>
Date: Tue, 31 Jul 2018 10:09:56 -0700
Archived-At: 
Subject: [secdir] Secdir last call review of draft-ietf-tls-tls13-vectors-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jul 2018 17:09:57 -0000

Reviewer: Matthew Miller
Review result: Ready

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

Document:
Reviewer: Matthew A. Miller
Review Date: 2018-07-31
IETF LC End Date: 2018-07-24
IESG Telechat date: 2018-08-02

Summary:

This document provides example handshakes for TLS 1.3, including
 private keys where necessary, making it suitable for testing.

This document is ready to be published as an Informational draft.

Major Issues: N/A

Minor Issues: N/A

Nits: N/A



From nobody Tue Jul 31 11:14:40 2018
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E16A130E75 for ; Tue, 31 Jul 2018 11:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGFmEmJ2f8OW for ; Tue, 31 Jul 2018 11:14:11 -0700 (PDT)
Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CE0130E69 for ; Tue, 31 Jul 2018 11:14:08 -0700 (PDT)
X_CMAE_Category: , ,
X-CNFS-Analysis: v=2.2 cv=e9pEcuh/ c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=R9QF1RCXAYgA:10 a=bmmO2AaSJ7QA:10 a=48vgC7mUAAAA:8 a=BTUBnpS-AAAA:8 a=Q13zCtEZr0PcJ8oDU30A:9 a=UGXY1L0UN8mkivnQ:21 a=xrNhwdIWsu1O4nMh:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=pblkFgjdBCuYZ9-HdJ6i:22
X-CM-Score: 0
X-Scanned-by: Cloudmark Authority Engine
X-Authed-Username: ZHNlb21uQHJjbi5jb20=
Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=david+work@mandelberg.org; sender-id=neutral
Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=david+work@mandelberg.org; spf=neutral; sender-id=neutral
Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN)
Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.43.168 is neither permitted nor denied by domain of mandelberg.org)
Received: from [209.6.43.168] ([209.6.43.168:54186] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384)  id FF/1B-18484-EE6A06B5; Tue, 31 Jul 2018 14:14:06 -0400
Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 383C01C6093; Tue, 31 Jul 2018 14:14:05 -0400 (EDT)
To: Kent Watsen , "draft-ietf-netconf-zerotouch.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" 
References: <361393b0-6666-08ff-bdf4-3ba3bf4323c7@mandelberg.org> <47EEE9B6-5BC2-4A1F-ABB2-2ACB1C494545@juniper.net>
From: David Mandelberg 
Message-ID: <4579f9bf-0ead-a6af-dc80-a841527414eb@mandelberg.org>
Date: Tue, 31 Jul 2018 14:14:02 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <47EEE9B6-5BC2-4A1F-ABB2-2ACB1C494545@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [secdir] secdir review of draft-ietf-netconf-zerotouch-22
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jul 2018 18:14:14 -0000

On 07/26/2018 10:42 PM, Kent Watsen wrote:
> Hi David,
> 
> Thank you for your review!
> Please find comments below.
> 
> Kent
> 
> 
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These comments were written primarily for the benefit of the
>> security area directors.  Document editors and WG chairs should treat
>> these comments just like any other last call comments.
>>
>> The summary of the review is Almost ready.
>>
>> Is there any protection against old signed Zero Touch Information? I see
>> that Ownership Vouchers and Owner Certificates both have mechanisms for
>> expiration (and for certs, revocation), but I don't see anything
>> comparable for redirect or onboarding information. If an owner creates a
>> valid redirect or onboarding object and discovers a bug in it, is there
>> any way for the owner to make that object no-longer-valid without
>> getting an entirely new owner certificate and revoking the old cert? Is
>> that intentional?
> 
> No, as you say, it is not possible to revoke signed data, other than
> to revoke the Owner Certificate associated with the private key that
> signed it.
> 
> I wouldn't say that this was/is intentional, other than note that
> it seems consistent with assumptions made when the bootstrapping
> device obtains unsigned data from a trusted bootstrap server, in
> that the data is only protected by the bootstrap server's TLS
> certificate; the device can check that the certificate hasn't been
> revoked, but that doesn't say anything about the current validity
> of the data.

I think the TLS case and the case of signed objects transmitted over 
insecure channels/mediums are different, because of TLS's replay protection.


> Do you think a Security Consideration would cover it?  Something
> like:
> 
>     Zerotouch information, regardless of how obtained or how
>     trusted, does not have a validity assertion beyond the PKI
>     used to authenticate it.  Zerotouch information neither
>     expires nor can be revoked.  When provided by a trusted
>     bootstrap server, the validity of the zerotouch information
>     is implied by its availability.  However, when zerotouch
>     information is provided outside the purview of a bootstrap
>     server (i.e., signed data on a removable storage device),

I'd suggest adding a word to make that "a trusted bootstrap server". 
(Bootstrap servers can be untrusted, right?)

>     its current validity is less certain.  Operators are advised
>     to ensure only accurate zerotouch information is ever
>     published.  In case inaccurate zerotouch information is
>     published, or otherwise deemed no longer valid, and it is
>     deemed a security risk, the signing certificate SHOULD be
>     revoked and a new one created having a chain to trust
>     leading to the same 'pinned-domain-certificate' provided
>     in the Ownership Voucher for the device.  However, doing
>     so, will necessarily affect the validity of any other
>     previously published zerotouch information artifacts
>     signed using the just-revoked certificate.  It the need
>     to do this is fairly common, operators can define an
>     Owner Certificate per device.

Owner certs can be valid for years, right? My intuition (which might be 
wrong) is that it's hard enough to remember every old configuration used 
in the past few years, that operators won't really know if any of the 
old configurations should be "deemed a security risk". You probably have 
a better understanding of the operational environments this protocol 
will be used in though. If you don't think there's a significant 
operational security risk from this, then I'm happy with your text.


>> It seems like this protocol places more trust in device manufacturers
>> than was previously required, but I don't see any discussion of that in
>> the security considerations. If necessary, is there any way to disable
>> zero touch, and configure a device manually? E.g., if the supply chain
>> is presumed-secure, but the manufacturer's well-known bootstrap server
>> is compromised, is there any way to securely provision a new device?
> 
> Regarding placing more trust in device manufacturers, and a
> potential Security Considerations statement, I'm trying to
> determine what statements you're looking for.
> 
> But first, I think you mean "well-known bootstrap servers" more
> so than "manufacturers".  AFAIK, the draft never says in normative
> text that the well-known bootstrap servers are hosted by the
> manufacturer (though entirely possible and somewhat likely).

Correct, sorry for the assumption.


> So maybe a couple Security Consideration statements related to:
> 
> 1) the security issue that the well-known bootstrap server may have
>     been compromised.  Though, it seems that this is a statement that
>     any TLS-protected resource could make.
> 
> 2) the privacy issue that the information provided to the well-known
>     bootstrap service may be visible to others (e.g., admins of the
>     bootstrap server) if not encrypted.
> 
> Are these what you had in mind?  If not, can you please jot down a
> few lines capturing what you hope to see?

Those are part of what I had in mind, but I'm looking for something at a 
higher level. It seems that the nature of this protocol is to shift some 
control of initial configuration away from the owner and towards the 
manufacturer (or whoever picks the list of well-known bootstrap servers) 
and/or the well-known bootstrap server operators. That's not a problem 
at all, it would just be nice to see some discussion of that shift in 
control. It would be even greater to see a discussion of how that shift 
in control matches up with a threat model.

Does that make sense? I'm not sure how much that's in scope for this 
particular document, it just seems like there's some major stuff going 
on with owners needing to trust others more in ways that they did not 
without zerotouch, so it would be good to see an explanation of the 
extent of that somewhere.


> Regarding "is there any way to disable zero touch, and configure a
> device manually", I think that this is outside the scope of the
> document.  Some vendors may lock down a device such that it can
> only activate thru the bootstrapping process, while other devices
> simultaneously enable console access.

ACK. I think those have significant effects on security, but it's fine 
if it's out of scope.


> Regarding "is there any way to securely provision a new device"
> when a well-known bootstrap server is known to be compromised.  My
> first thought is, if it's known to be compromised, then it's also
> likely patched.  But let's say the issue is more like an operator
> not trusting a particular well-known bootstrap server for some
> other reason, and would like to never allow devices to obtain
> bootstrapping data there...then the options are slim, an external
> firewall policy blocking access to that bootstrap server may be
> needed.

That type of remedy sounds out of scope, but to my initial point above, 
I think it might be worth saying something along the lines of "this 
system assumes that owners trust all pre-configured well-known bootstrap 
servers to configure their devices".


>> Section 3.4 mentions a device identify certificate. I assume the
>> public keys in those certificates are unique per-device? If not,
>> I want to think a bit more about possible attacks where the
>> attacker correlates encrypted artifacts without being able to
>> decrypt them.
> 
> Yes, probabilistically/cryptographically unique keys per device.

ACK, I have no concern here then.


>> Section 5.4 says what to do "if the revocation status is not
>> attainable". What does that mean precisely? E.g., I assume failure to
>> download a CRL, absence of a CRL in the CMS data, and failure to contact
>> an OCSP server all count. But what if the device acquires a valid CRL
>> that is stale (nextUpdate < now)?
> 
> Yes, exactly, it meant to cover those cases, as well as the "stale"
> case, though I admit the text doesn't exactly say it.  How about this?
> 
>    OLD
>       if the revocation status is not attainable
>    NEW
>       if suitably-fresh revocation status is not attainable

Looks good.


>> If I'm understanding correctly, the intent of well-known bootstrap
>> servers is that the manufacturer can redirect devices to customer
>> bootstrap servers that have the actual onboarding information. But I
>> also don't see any reason that a (potentially compromised) trusted
>> manufacturer's bootstrap server couldn't provide the onboarding
>> information directly. It's probably easier to secure the (potentially
>> offline) private keys used to sign ownership vouchers than it is to
>> secure the (presumably highly available, online) well-known bootstrap
>> servers. So it seems like the system as a whole could be more secure if
>> well-known bootstrap servers could only provide untrusted redirects.
> 
> First, let's replace "manufacturer" with "well-known bootstrap server"
> above.  But, to your main point, absolutely, any bootstrap-server could
> return either redirect or onboarding information, and perhaps it is a
> feature for some well-known bootstrap servers to do so.  And yes again,
> the keys for an online service are potentially more easily compromised,
> perhaps a Security Consideration for the use of HSMs similar to [1]
> would help?  While I agree with your conclusion, it brings into question
> what "trusted" means.  What about an OCSP server with its online key?
> If the manufacturer no longer deems (through audits or whatever) that
> a well-known bootstrap server is no longer trusted, it can revoke the
> bootstrap server's certificate.  Just wondering, is this really a
> problem?  Can a Security Consideration be used to address this to
> your satisfaction?
> 
> [1] https://tools.ietf.org/html/draft-ietf-anima-voucher-07#section-7.2

Since it's intentional that a well-known bootstrap server can return 
onboarding information, then I think this is just another part the high 
level discussion of the shift in control that I asked for above.


>> I don't understand the error cases around the "flag to enable zerotouch
>> bootstrapping" in section 5.1. How exactly is that flag set to false? Is
>> it by the initial configuration step in section 5.6? If that's where the
>> flag is set to false, won't some owners forget to include that in their
>> config? Also, how atomic is the application of initial configuration? Is
>> there any possible case in which some of the initial configuration can
>> be applied without touching the flag, so that the device appears to be
>> correctly configured, but will try to bootstrap again on the next
>> reboot? Conversely, can the flag be set to false without the device
>> being fully configured? (I don't think that's a security issue, just
>> potentially a management headache.)
> 
> Yes, the initial-step in Section 5.6.  Yes, some operators may forget
> (though they will learn).  The config is intended to either be applied
> completely or not at all.  The second paragraph in section 5.6 says
> "If the device encounters an error at any step, it MUST NOT proceed
> to the next step."  Perhaps the 6th paragraph in that section could
> could state that an "error" constitutes anything less than 100%?

Do you think it's worth adding a warning to operators somewhere to 
remind them to change the flag? Or maybe the "device SHOULD report a 
warning if the bootstrapping completes successfully but zerotouch 
bootstrapping is still enabled"?

I think it's already clear what an error in paragraph 6 is. What I found 
unclear was what to do with errors in paragraphs 6 or 7. Yes, don't go 
on to the next step, but what about: In paragraph 6, should the device 
rollback any partial config update if there's an error? In paragraph 7, 
should the device rollback all config from paragraph 6 if there's an error?


>> Section 9.4 says to assume owner certificates "are not revokable" if
>> there's no accurate clock. Is there no value in checking for a CRL or
>> OCSP response, even without the ability to determine if it's recent? It
>> seems to me that checking with an active server (CRL Distribution Point
>> or OCSP server, as opposed to a stapled CRL or OCSP response) would make
>> it significantly harder (not infeasible, just harder) for an attacker to
>> use a revoked cert against a device with no clock.
> 
> Okay, fair point, a live response sort of reflects "now", regardless
> what the device clock says.  That said, without an accurate clock, the
> device wouldn't be able to validate the signing certificate and, if
> provided over an HTTPS transport, it wouldn't be able to validate the
> server's end-entity certificate either.  In fact, certain device bad
> clock values might actually block the TLS connection due to it being
> outside the end-entity cert's validity period.  Ugh.  Currently the
> text says that device "implementations should assume [things]  are not
> revocable" - do you want to add a text like "but MAY check 'current'
> revocation using on online CRL Distribution Point or
> OCSP server"?

Good points. I'm not sure what the right answer is, so I'll defer to you 
on this.


> BTW, the end of this section says "Implementations SHOULD NOT rely on
> NTP for time, as NTP is not a secure protocol." - any thoughts on this
> statement?

I know very little about the security of time synchronization, sorry.


-- 
https://david.mandelberg.org/


From nobody Tue Jul 31 11:53:57 2018
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9605C130E60 for ; Tue, 31 Jul 2018 11:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g74jfHVHLNtc for ; Tue, 31 Jul 2018 11:53:47 -0700 (PDT)
Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007C3130E73 for ; Tue, 31 Jul 2018 11:53:45 -0700 (PDT)
X_CMAE_Category: , ,
X-CNFS-Analysis: v=2.2 cv=Jaj+lgCV c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=GVRjdqUUgS0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=R9QF1RCXAYgA:10 a=bmmO2AaSJ7QA:10 a=BTUBnpS-AAAA:8 a=iiazv-oawmH03g7Men8A:9 a=QEXdDO2ut3YA:10 a=pblkFgjdBCuYZ9-HdJ6i:22
X-CM-Score: 0
X-Scanned-by: Cloudmark Authority Engine
X-Authed-Username: ZHNlb21uQHJjbi5jb20=
Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=david+work@mandelberg.org; sender-id=neutral
Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=david+work@mandelberg.org; spf=neutral; sender-id=neutral
Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN)
Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 209.6.43.168 is neither permitted nor denied by domain of mandelberg.org)
Received: from [209.6.43.168] ([209.6.43.168:54196] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384)  id E7/9D-48830-830B06B5; Tue, 31 Jul 2018 14:53:44 -0400
Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id D01A71C6093; Tue, 31 Jul 2018 14:53:43 -0400 (EDT)
To: draft-ietf-regext-allocation-token.all@ietf.org, iesg@ietf.org, secdir@ietf.org
From: David Mandelberg 
Message-ID: <2e0dddb7-539c-7a80-6cdc-39fbb2d42c28@mandelberg.org>
Date: Tue, 31 Jul 2018 14:53:41 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [secdir] secdir review of draft-ietf-regext-allocation-token-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jul 2018 18:53:49 -0000

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

The summary of the review is Ready with nits.

Section 2.1 says "The server MUST have the Allocation Token for each 
object to match against the Allocation Token passed by the client to 
authorize the allocation of the object." Does it make sense for a server 
to have salted+hashed tokens instead of the tokens themselves? Or to 
otherwise cryptographically verify tokens without storing the tokens?

I think there's a typo in section 7, bullet 6, and I'm not sure what the 
intent of that sentence is.

-- 
https://david.mandelberg.org/


From nobody Tue Jul 31 12:34:52 2018
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805A8130E2A; Tue, 31 Jul 2018 12:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-Pc5fxvZf9e; Tue, 31 Jul 2018 12:34:39 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (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 165ED130DF7; Tue, 31 Jul 2018 12:34:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2796; q=dns/txt; s=VRSN; t=1533065679; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=Y1qz3cISa0TUvmmXDMmtEvoGvLaEZbaHlUlbEdKNgjU=; b=KdWJIfm2jSqR2I4OgjlWQmqp2O1EMPUXi36UKhbUGQXxjatCnOiqmXQC Pqc+rD6g+q7Q+gf5Satlm8ACcr7ShQjih8sxp3LUUMJh+MfTB/9Ofpr3q wWhxSYccK//Q+i+FfZ2ml2Vch34HgcAz3dlqmA8IYCJ+gF9hcZTdYOpX+ eYC8xrSIlfow7zd9eNcGCp/lT2uEg/yZ2HiUcrGLJWOzV7PqXloKsCkIe dXDL0FoDeUykSLkiM5TsKIc+AwE2lV+pLzBtOEVQ7wCbQLRXPU3mha327 C8zU+yT+L7bKLZha+VXmKl8H46BMPKAwTf9cj6jKWGTRvwGwLUSS22TFx Q==;
X-IronPort-AV: E=Sophos;i="5.51,428,1526356800";  d="scan'208";a="5230043"
IronPort-PHdr: =?us-ascii?q?9a23=3AiwOqWRIsJJzNZi5yhdmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgXKPX9rarrMEGX3/hxlliBBdydt6oazbKO+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZLebxlJiTanfb9+MAi9oBnMuMURnYZsMLs6xAHTontPde?= =?us-ascii?q?RWxGdoKkyWkh3h+Mq+/4Nt/jpJtf45+MFOTav1f6IjTbxFFzsmKHw65NfqtRbY?= =?us-ascii?q?UwSC4GYXX3gMnRpJBwjF6wz6Xov0vyDnuOdxxDWWMMvrRr0yRD+s7bpkSAXwhS?= =?us-ascii?q?kHKTA37X3XhMJzgqJVoh2uqR1/zJLbbo6aL/d+YrjSfdYGSWZdRMtcVSpMCZ68?= =?us-ascii?q?YYsVCOoBOP5Vo4f8qVsJsBu+ARSjCPvywTFMnHD22LM10/8vHQrb2wEgHd0OsH?= =?us-ascii?q?PJrNXxKagfSv61w7fSzTXCdPNW2Dj96I7Sfh89pvGMWKt9fMzMwkchEAPFi0+f?= =?us-ascii?q?qY3jPz6NyOQCrXKb7+t7VeKuhG4nrQBxoj6zycs2lobJgYcVxkjB9SpjxoY6OM?= =?us-ascii?q?O3SEpgbtG6CptQuDuWN4xsQsMtRWxjpSU0yqUetJKmYCQG0okryhzRZvCdboSF?= =?us-ascii?q?4hzuWPyeLDp8nH5pZa6ziwyv/UWi1uHwTNS43VlJoyZfj9XBtWgB1xLN5cWEVv?= =?us-ascii?q?dw+0Ks1iyM2g3X8e5JJE45mbTGJJMgx7M/jZ4evEXBEyLzlkj7gq2beVgi9+O1?= =?us-ascii?q?8eroeK/mqYWZN4JsjwH+NbkhldKnDOQjNwgOQ3Cb+eOh1L3/5UH5QKtFjvkxkq?= =?us-ascii?q?TBrZ3UOdwVqrO5DAFN3Ygs6gqzAym83NQGgXYHK0hFeAqdg4fzJl7COu74De2k?= =?us-ascii?q?g1Sqijtk2/fGPrj5DpXMKHjMjqvhcK5g50JA0gY/0NJS6pxOBr0cIP/+VFX9ud?= =?us-ascii?q?PcAxMhNgy72efnCNFz1oMEXmKPB7eUMKHdsV+P++IvJ/SDaZQLuDnjMfgl5uXu?= =?us-ascii?q?jX42mV8bZ6WmwZwXaHWgEvR8P0qZeWbsgssGEWoSowUxVvLqiFyfXjJUaXeyWL?= =?us-ascii?q?g85jIgBYKjF4jDQJ2ij6KF3CigAJJWfG9GBkqLEXfyeIWOQ+0MZz6KIs99jjwE?= =?us-ascii?q?UqCsRJI71R60ug/616NrLuvK9S0Eu5LvzcJ16PPclR4s+j10E92R3HuJT2FwmW?= =?us-ascii?q?MHWyU53Lx+oUx6zFePyLR4g/tbFdNN4fNFSB01NZrYz+FhCtD9RB7BftmTRFah?= =?us-ascii?q?WNWmDik7TsgtzN8Wf0Z9B9KigwjC3yW0GL8VmKeGBJ0q/aLA0Xj9PcF9y2zJ1K?= =?us-ascii?q?M5lVkpXtNPNXG6hq547wXTHJDGnFmEmKarb6QRxy/N+3mfzWqApk1YVxRwUaqW?= =?us-ascii?q?FUwYM2ffs9X1rmbLSbOjDb4qKAQJncKLNKpGKcLul1ZuQf7lNNnaaW+rlCG3Hx?= =?us-ascii?q?negvvGYJDjdXlY3SjBBg0eng8e7WrDPAw6ASyov2PZCnlyElHiZQXl9e1WqX6n?= =?us-ascii?q?QAkz1Q7AJxltzbO75lsUiOCSDuke0b8UpGIorzFzF1+h3tXQTsaHpAdnOqxYZf?= =?us-ascii?q?s87UtJk2XDuFo5dtahIrttrl8TbwoxuFnhnV0jC4hbnuAroW8kig1oJvTcmBla?= =?us-ascii?q?ejiU3IrYO7DLJC/15h/lI/rN11rS0cy++6oT5rI/sVq17y+zEU93uVpgzt1Zlz?= =?us-ascii?q?O+75DHF0BaBZD+VVsz+zBkqqvbeSgy4cXf0ng6Yvr8iSPLx998XLht8R2nZdoK?= =?us-ascii?q?aK4=3D?=
X-IPAS-Result: =?us-ascii?q?A2HaCQA6uWBb/zGZrQpYAx0BAQUBCwGEMYEnCoN0ljODYZI?= =?us-ascii?q?cgT87CxMMD4ECgzwCF4M2NhYBAgEBAQEBAQIBAQKBBQyCNSIRSy8IATEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBCAIIByQjARoGIxFVAgEIGgI?= =?us-ascii?q?mAgICMBUQAgQBEoMgAa94gS6KS4ELiBCBQj6BEicME4JMhGgWFwomgjoxgiQCm?= =?us-ascii?q?hUDBgKGFYsujACKU4RZAYJnAgQCBAUCFIFIDIF4cBVlAYI+CYV4hRSFPm8NJI0?= =?us-ascii?q?jK4EBgRsBAQ?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1466.3; Tue, 31 Jul 2018 15:34:37 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1466.003; Tue, 31 Jul 2018 15:34:37 -0400
From: "Gould, James" 
To: David Mandelberg , "draft-ietf-regext-allocation-token.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" 
Thread-Topic: [EXTERNAL] secdir review of draft-ietf-regext-allocation-token-08
Thread-Index: AQHUKP/RrhuIExg0xUi9EzDFrK4PqKSpuQiA
Date: Tue, 31 Jul 2018 19:34:37 +0000
Message-ID: 
References: <2e0dddb7-539c-7a80-6cdc-39fbb2d42c28@mandelberg.org>
In-Reply-To: <2e0dddb7-539c-7a80-6cdc-39fbb2d42c28@mandelberg.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.e.1.180613
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <3D63D79AC5AA06478A2CBC8A3ED6D9A3@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [secdir] secdir review of draft-ietf-regext-allocation-token-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jul 2018 19:34:42 -0000

RGF2aWQsDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcgYW5kIGZlZWRiYWNrLiAgTXkgcmVz
cG9uc2VzIGFyZSBpbmNsdWRlZCBiZWxvdy4gIA0KDQogIA0K4oCUDQogDQpKRw0KDQoNCg0KSmFt
ZXMgR291bGQNCkRpc3Rpbmd1aXNoZWQgRW5naW5lZXINCmpnb3VsZEBWZXJpc2lnbi5jb20NCg0K
NzAzLTk0OC0zMjcxDQoxMjA2MSBCbHVlbW9udCBXYXkNClJlc3RvbiwgVkEgMjAxOTANCg0KVmVy
aXNpZ24uY29tIDxodHRwOi8vdmVyaXNpZ25pbmMuY29tLz4gDQoNCu+7v09uIDcvMzEvMTgsIDI6
NTMgUE0sICJEYXZpZCBNYW5kZWxiZXJnIiA8ZGF2aWQrd29ya0BtYW5kZWxiZXJnLm9yZz4gd3Jv
dGU6DQoNCiAgICBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBz
ZWN1cml0eSBkaXJlY3RvcmF0ZSdzDQogICAgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJ
RVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQogICAgSUVTRy4gIFRoZXNlIGNv
bW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZQ0KICAg
IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJz
IHNob3VsZCB0cmVhdA0KICAgIHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFz
dCBjYWxsIGNvbW1lbnRzLg0KICAgIA0KICAgIFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXMg
UmVhZHkgd2l0aCBuaXRzLg0KICAgIA0KICAgIFNlY3Rpb24gMi4xIHNheXMgIlRoZSBzZXJ2ZXIg
TVVTVCBoYXZlIHRoZSBBbGxvY2F0aW9uIFRva2VuIGZvciBlYWNoIA0KICAgIG9iamVjdCB0byBt
YXRjaCBhZ2FpbnN0IHRoZSBBbGxvY2F0aW9uIFRva2VuIHBhc3NlZCBieSB0aGUgY2xpZW50IHRv
IA0KICAgIGF1dGhvcml6ZSB0aGUgYWxsb2NhdGlvbiBvZiB0aGUgb2JqZWN0LiIgRG9lcyBpdCBt
YWtlIHNlbnNlIGZvciBhIHNlcnZlciANCiAgICB0byBoYXZlIHNhbHRlZCtoYXNoZWQgdG9rZW5z
IGluc3RlYWQgb2YgdGhlIHRva2VucyB0aGVtc2VsdmVzPyBPciB0byANCiAgICBvdGhlcndpc2Ug
Y3J5cHRvZ3JhcGhpY2FsbHkgdmVyaWZ5IHRva2VucyB3aXRob3V0IHN0b3JpbmcgdGhlIHRva2Vu
cz8NCiAgICANCkpHIC0gVGhhdCBzZW50ZW5jZSB3YXMgbW9kaWZpZWQgYmFzZWQgb24gdGhlIGZl
ZWRiYWNrIGZyb20gQWRhbSBSb2FjaCB0byBjaGFuZ2UgdGhlIE1VU1QgdG8gYSBNQVksIHNpbmNl
IGRyYWZ0LWlldGYtcmVnZXh0LWFsbG9jYXRpb24tdG9rZW4gZG9lcyBub3QgcHJlZGVmaW5lIHRo
ZSBtYWtldXAgb2YgdGhlIGFsbG9jYXRpb24gdG9rZW4gKGUuZy4sIHByZS1nZW5lcmF0ZWQgb3Ig
bm90KS4gIFRoZXJlIGFyZSBtYW55IGFwcHJvYWNoZXMgdGhhdCBtYXkgYmUgdGFrZW4gd2l0aCB0
aGUgZ2VuZXJhdGlvbiBhbmQgdmFsaWRhdGlvbiBvZiB0aGUgYWxsb2NhdGlvbiB0b2tlbiwgd2hl
cmUgZHJhZnQtaWV0Zi1yZWdleHQtYWxsb2NhdGlvbi10b2tlbiBwcm92aWRlcyB0aGUgY29uZHVp
dCB0byBwYXNzIHRoZW0gb3ZlciBFUFAuICANCg0KICAgIEkgdGhpbmsgdGhlcmUncyBhIHR5cG8g
aW4gc2VjdGlvbiA3LCBidWxsZXQgNiwgYW5kIEknbSBub3Qgc3VyZSB3aGF0IHRoZSANCiAgICBp
bnRlbnQgb2YgdGhhdCBzZW50ZW5jZSBpcy4NCiANCkpHIC0gQWRhbSBSb2FjaCBhbHNvIGNhdWdo
dCB0aGlzLiAgVGhlIGZpcnN0ICJzaG91bGQiIG5lZWRzIHRvIGJlIGNoYW5nZWQgdG8gYSAidGhh
dCIsIHNvIGl0IHJlYWRzICIgQW4gQWxsb2NhdGlvbiBUb2tlbiB0aGF0IGlzIHNpZ25lZCBYTUwg
c2hvdWxkIGJlIGVuY29kZWQgKGUuZy4sIGJhc2U2NCBbUkZDNDY0OF0pIHRvIG1pdGlnYXRlIHNl
cnZlciB2YWxpZGF0aW9uIGlzc3VlcyIuICBUaGlzIGNvcnJlY3Rpb24gd2lsbCBiZSByZWZsZWN0
ZWQgaW4gZHJhZnQtaWV0Zi1yZWdleHQtYWxsb2NhdGlvbi10b2tlbi0xMC4NCiAgIA0KICAgIC0t
IA0KICAgIGh0dHBzOi8vZGF2aWQubWFuZGVsYmVyZy5vcmcvDQogICAgDQoNCg==


From nobody Tue Jul 31 12:44:45 2018
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5694F130E5F for ; Tue, 31 Jul 2018 12:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDnvy3IjNnHL for ; Tue, 31 Jul 2018 12:44:35 -0700 (PDT)
Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3827130E6C for ; Tue, 31 Jul 2018 12:44:32 -0700 (PDT)
X_CMAE_Category: , ,
X-CNFS-Analysis: v=2.2 cv=Jaj+lgCV c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=R9QF1RCXAYgA:10 a=bmmO2AaSJ7QA:10 a=BTUBnpS-AAAA:8 a=OWztEDCSwSlAc_ImmsgA:9 a=QEXdDO2ut3YA:10 a=pblkFgjdBCuYZ9-HdJ6i:22
X-CM-Score: 0
X-Scanned-by: Cloudmark Authority Engine
X-Authed-Username: ZHNlb21uQHJjbi5jb20=
Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=david+work@mandelberg.org; spf=neutral; sender-id=neutral
Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=david+work@mandelberg.org; sender-id=neutral
Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN)
Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 209.6.43.168 is neither permitted nor denied by domain of mandelberg.org)
Received: from [209.6.43.168] ([209.6.43.168:54208] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384)  id 5D/81-48830-F1CB06B5; Tue, 31 Jul 2018 15:44:31 -0400
Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id CD14F1C6093; Tue, 31 Jul 2018 15:44:30 -0400 (EDT)
To: "Gould, James" , "draft-ietf-regext-allocation-token.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" 
References: <2e0dddb7-539c-7a80-6cdc-39fbb2d42c28@mandelberg.org> 
From: David Mandelberg 
Message-ID: 
Date: Tue, 31 Jul 2018 15:44:28 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [secdir] secdir review of draft-ietf-regext-allocation-token-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jul 2018 19:44:36 -0000

On 07/31/2018 03:34 PM, Gould, James wrote:
> On 7/31/18, 2:53 PM, "David Mandelberg"  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.
>      
>      The summary of the review is Ready with nits.
>      
>      Section 2.1 says "The server MUST have the Allocation Token for each
>      object to match against the Allocation Token passed by the client to
>      authorize the allocation of the object." Does it make sense for a server
>      to have salted+hashed tokens instead of the tokens themselves? Or to
>      otherwise cryptographically verify tokens without storing the tokens?
>      
> JG - That sentence was modified based on the feedback from Adam Roach to change the MUST to a MAY, since draft-ietf-regext-allocation-token does not predefine the makeup of the allocation token (e.g., pre-generated or not).  There are many approaches that may be taken with the generation and validation of the allocation token, where draft-ietf-regext-allocation-token provides the conduit to pass them over EPP.

Sounds good.


>      I think there's a typo in section 7, bullet 6, and I'm not sure what the
>      intent of that sentence is.
>   
> JG - Adam Roach also caught this.  The first "should" needs to be changed to a "that", so it reads " An Allocation Token that is signed XML should be encoded (e.g., base64 [RFC4648]) to mitigate server validation issues".  This correction will be reflected in draft-ietf-regext-allocation-token-10.

That makes more sense.

-- 
https://david.mandelberg.org/


From nobody Tue Jul 31 20:01:15 2018
Return-Path: 
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88925130FB5; Tue, 31 Jul 2018 19:52:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1533091944; bh=V68iMdjrrZ0Mn6gviodqqo7QR2ELU73T2s3JARCqaCA=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=X6OVdj0iOMz9DfRbwHLrKhT2XZlqLuR2ZXoM/qAsAoM5jJKtcmyoD90vODMX6WaJ8 WN+FVocENaLKaqCpofBs/Yhn7vyv7HgNRvNeFvw7etx1ScCU9HjCc1BTgSd2Awk86L taFEzRBOQd0bUSMRiuw4oRUntFwypHjSyIOQqEcU=
X-Mailbox-Line: From new-work-bounces@ietf.org  Tue Jul 31 19:52:24 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C6F130FA5; Tue, 31 Jul 2018 19:52:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1533091944; bh=V68iMdjrrZ0Mn6gviodqqo7QR2ELU73T2s3JARCqaCA=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=X6OVdj0iOMz9DfRbwHLrKhT2XZlqLuR2ZXoM/qAsAoM5jJKtcmyoD90vODMX6WaJ8 WN+FVocENaLKaqCpofBs/Yhn7vyv7HgNRvNeFvw7etx1ScCU9HjCc1BTgSd2Awk86L taFEzRBOQd0bUSMRiuw4oRUntFwypHjSyIOQqEcU=
X-Original-To: new-work@ietfa.amsl.com
Delivered-To: new-work@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAAEC130E1D for ; Tue, 31 Jul 2018 19:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.674
X-Spam-Level: 
X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[HK_RANDOM_ENVFROM=0.626, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZeTZRyi0bZd for ; Tue, 31 Jul 2018 19:52:19 -0700 (PDT)
Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07AF4130FA9 for ; Tue, 31 Jul 2018 19:52:19 -0700 (PDT)
Received: from [42.100.11.22] (helo=[192.168.1.2]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1fkhFJ-0007ts-GB for new-work@ietf.org; Wed, 01 Aug 2018 02:52:17 +0000
To: new-work@ietf.org
From: Xueyuan 
Message-ID: <88960bb5-f106-c98f-bd61-a768c70b2a27@w3.org>
Date: Wed, 1 Aug 2018 10:52:14 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Language: en-US
Archived-At: 
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: new-work-bounces@ietf.org
Sender: "new-work" 
Archived-At: 
X-Mailman-Approved-At: Tue, 31 Jul 2018 20:01:13 -0700
Subject: [secdir] [new-work] Proposed W3C Charter: Chinese Web Community (CWC) Interest Group (until 2018-08-29)
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Aug 2018 02:52:26 -0000

CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj
ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgQ2hpbmVz
ZSBXZWIgQ29tbXVuaXR5IChDV0MpIEludGVyZXN0IApHcm91cDoKCkVuZ2xpc2g6wqAgaHR0cHM6
Ly93M2MuZ2l0aHViLmlvL2NoaW5lc2UtaWctY2hhcnRlci8KQ2hpbmVzZTogaHR0cHM6Ly93M2Mu
Z2l0aHViLmlvL2NoaW5lc2UtaWctY2hhcnRlci9pbmRleC56aC5odG1sCgpBcyBwYXJ0IG9mIGVu
c3VyaW5nIHRoYXQgdGhlIGNvbW11bml0eSBpcyBhd2FyZSBvZiBwcm9wb3NlZCB3b3JrCmF0IFcz
QywgdGhpcyBkcmFmdCBjaGFydGVyIGlzIHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5CkNvbW1p
dHRlZSByZXZpZXcgcGVyaW9kLgoKVzNDIGludml0ZXMgcHVibGljIGNvbW1lbnRzIHRocm91Z2gg
MjAxOC0wOC0yOSBvbiB0aGUKcHJvcG9zZWQgY2hhcnRlci4gUGxlYXNlIHNlbmQgY29tbWVudHMg
dG8KcHVibGljLW5ldy13b3JrQHczLm9yZywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiDC
oCBodHRwOi8vbGlzdHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpP
dGhlciB0aGFuIGNvbW1lbnRzIHNlbnQgaW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNv
cnkKQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNw
b25zZSB0bwpjb21tZW50cy4gSWYgeW91IHdvcmsgZm9yIGEgVzNDIE1lbWJlciBbMV0sIHBsZWFz
ZSBjb29yZGluYXRlCnlvdXIgY29tbWVudHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBS
ZXByZXNlbnRhdGl2ZS4gRm9yCmV4YW1wbGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBj
b21tZW50cyB2aWEgdGhpcyBsaXN0IGFuZApoYXZlIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJl
cHJlc2VudGF0aXZlIHJlZmVyIHRvIGl0IGZyb20gaGlzCm9yIGhlciBmb3JtYWwgcmV2aWV3IGNv
bW1lbnRzLgoKSWYgeW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVy
IGluZm9ybWF0aW9uLCBwbGVhc2UKY29udGFjdCBGdXFpYW8gWHVlIDx4ZnFAdzMub3JnPiwgb3Ig
WHVleXVhbiBKaWEgPHh1ZXl1YW5AdzMub3JnPi4KClRoYW5rIHlvdSwKClh1ZXl1YW4gSmlhLCBX
M0MgTWFya2V0aW5nICYgQ29tbXVuaWNhdGlvbnMKClsxXSBodHRwOi8vd3d3LnczLm9yZy9Db25z
b3J0aXVtL01lbWJlci9MaXN0CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK