From nobody Wed Aug 5 12:03:20 2020 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 104C83A0EA2 for ; Wed, 5 Aug 2020 12:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 DvovywwxA9RU for ; Wed, 5 Aug 2020 12:03:13 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E613A1259 for ; Wed, 5 Aug 2020 12:02:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 04D1E300B87 for ; Wed, 5 Aug 2020 15:02:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id C9LWD9Gj41iF for ; Wed, 5 Aug 2020 15:02:07 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 6FA16300B22; Wed, 5 Aug 2020 15:02:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <15F09F0E-4C56-4B88-8F78-8135B94A5C7C@vigilsec.com> Date: Wed, 5 Aug 2020 15:02:06 -0400 Cc: IETF SecDir , lwip@ietf.org, draft-ietf-lwig-curve-representations.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <75EBE692-89AC-4394-9519-DEF58243EAAC@vigilsec.com> References: <157479110201.13605.6894641490219218764@ietfa.amsl.com> <5caff1bf-4e7b-f139-2328-2132df415cc8@gmail.com> <15F09F0E-4C56-4B88-8F78-8135B94A5C7C@vigilsec.com> To: Rene Struik X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-lwig-curve-representations-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 19:03:16 -0000 With IETF 108 behind me, I was about to take a look at = draft-ietf-lwig-curve-representations-11. It resolves all of the = comments that I had on the previous version. Russ > On Jul 14, 2020, at 2:59 PM, Russ Housley = wrote: >=20 > Rene: >=20 > It is not a gatekeeper of any sort. >=20 > I will not be able to another review for a couple of weeks. You have = asked at a particularly busy time for me. >=20 > Russ >=20 >=20 >> On Jul 14, 2020, at 1:45 PM, Rene Struik = wrote: >>=20 >> Hi Russ: >>=20 >> It has been a while that you provided your early SecDir review = comments. I do not know whether such early reviews are a gate keeper for = sealing off the lwig curve draft. Nevertheless, it may be good to know = if you are reasonably happy for this to move forward. >>=20 >> For some details on how I tried to take your comments into account, = please see my March 10th email below, where the mailing list link is >> = https://mailarchive.ietf.org/arch/msg/lwip/P8kfrso7lvcbf4bpxJjcEpDxjNU/# >>=20 >> For the current draft, see >> = https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/ >>=20 >> I am looking forward hearing back from you. >>=20 >> Best regards, Rene >>=20 >> On 2020-03-10 11:19 a.m., Rene Struik wrote: >>> Hi Russ: >>>=20 >>> I tried to take into account your comments with = draft-ietf-lwig-curve-representations-09. >>>=20 >>> I will send out a separate email to the list highlighting main = changes. >>>=20 >>> Below, I will explain how I tried and accommodate your previous = comments on the 08-draft, now that the new draft is out. >>>=20 >>> Important note: >>> As you know from offline communications, I did include = Curve448-related material with the 09 version. I tried to do this in a = way that would create the least editorial upheaval and would not take = away from the main objectives of the document: to this end, I only = introduced Curve448-related material in Section 4.4 [thereby avoiding = having to sprinkle in curve448-related language in each section and = blurring the message of the document]. The only other sections where = Curve448 plays a role is IANA Section 10 and the appendices that give = the parameters and test vectors for the Curve448 family members. {Note: = I probably should have added a note on ECDSA448 in the security = consideration section, though (I made a note on this and will fix).} >>>=20 >>>=20 >>> Best regards, Rene >>>=20 >>> On 11/26/2019 5:21 PM, Rene Struik wrote: >>>> Hi Russ: >>>>=20 >>>> Thanks. >>>>=20 >>>> On 11/26/2019 4:10 PM, Russ Housley wrote: >>>>>=20 >>>>>> On Nov 26, 2019, at 2:54 PM, Rene Struik = wrote: >>>>>>=20 >>>>>> Dear Russ: >>>>>>=20 >>>>>> Thanks for your review (and speedy turn-around). >>>>>>=20 >>>>>> Please find below feedback on how I intend to address all but = your last remarks (I will reflect on your suggestion as to introductory = text with the appendices when looking over Daniel Migault's earlier = "guidance of the reader" remarks). >>>>>>=20 >>>>>> Best regards, Rene >>>>>>=20 >>>>>> On 11/26/2019 12:58 PM, Russ Housley via Datatracker wrote: >>>>>>> Reviewer: Russ Housley >>>>>>> Review result: Has Issues >>>>>>>=20 >>>>>>> I reviewed this document as part of the Security Directorate's = ongoing >>>>>>> effort to review all IETF documents being processed by the IESG. = These >>>>>>> comments were written primarily for the benefit of the Security = Area >>>>>>> Directors. Document authors, document editors, and WG chairs = should >>>>>>> treat these comments just like any other IETF Last Call = comments. >>>>>>>=20 >>>>>>> Document: draft-ietf-lwig-curve-representations-08 >>>>>>> Reviewer: Russ Housley >>>>>>> Review Date: 2019-11-26 >>>>>>> IETF LC End Date: unknown >>>>>>> IESG Telechat date: unknown >>>>>>>=20 >>>>>>> Summary: Has Issues >>>>>>>=20 >>>>>>>=20 >>>>>>> Major Concerns: >>>>>>>=20 >>>>>>> I am confused by the first paragraph in Section 10. It says = that "An >>>>>>> object identifier is requested ...", but then code points for = COSE >>>>>>> and JOSE (not object identifiers) are requested in the = subsection. >>>>>>>=20 >>>>>>> I am confused by the second paragraph in Section 10. It says = that >>>>>>> "There is *currently* no further IANA action required ...". = Please >>>>>>> delete this paragraph. >>>>>> RS>> If I remember this correctly, I borrowed this from another = draft (but perhaps was somewhat ignorant here about proper formulation). = I intend to change the first para to "code points are requested for = ....". As to the second para, I believe it has some merit to keep this = in, in slightly altered form, e.g., as "New object identifiers would be = required in case one wishes to specify one or more of the "offspring" = protocols exemplified in Section 4.4. Specification hereof is, however, = outside scope of the current document." >>>>>>=20 >>>>>> <>>>> I do not see how the second paragraph gives any direction = regarding the IANA registries. >>>>=20 >>>> RS>> The requested algorithm registrations are for co-factor ECDH = (Example 4.1) and ECDSA (Example 4.3), where the second para is more a = reminder that one would need more registrations if one would like other = spin-offs (so it was more to keep parallelism with Example 4.4). As = example, one could instantiate e.g., Wei25519 plus, say, MQV (which NIST = SP 800-56a + new curve W25519 in draft SP 186 would enable) and, e.g., = Wei25519+MQV, Wei25519 + impl cert (for V2V; see IACR 2019-157), etc., = but I did not wish to go over the top and that could be to be defined = elsewhere. =46rom a Spartan writing perspective, it could indeed be = argued that one could guess this oneself. <>>=20 >>> RS1>> Since I added Curve448-related material, I divided the IANA = section into two subsections, where the first one requests for code = points for Wei25519 and the second one requests for code points for = Wei448. The reason for this organization is that it shows clearly the = edits w.r.t. the 08 version. Due to the additional request for code = points for Wei448, I changed the language in the preamble of the IANA = section as follows: >>>=20 >>> Code points are requested for curve Wei25519 and Wei448 and its use = with ECDSA and co-factor ECDH, using the representation conventions of = this document. >>> New code points would be required in case one wishes to specify one = or more other "offspring" protocols beyond those exemplified in Section = 4.4. Specification hereof is, however, outside scope of the current = document. >>>=20 >>> <>>=20 >>>>=20 >>>>>=20 >>>>>>> Minor Concerns: >>>>>>>=20 >>>>>>> Requirements Language section is out of date. It should = reference >>>>>>> RFC 8174 in addition to RFC 2119, as follows: >>>>>>>=20 >>>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", >>>>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", = "MAY", and >>>>>>> "OPTIONAL" in this document are to be interpreted as = described in >>>>>>> BCP 14 [RFC2119] [RFC8174] when, and only when, they appear = in all >>>>>>> capitals, as shown here. >>>>>> RS>> will do. As minor point (from a non-native speaker's = perspective): shouldn't the last part of the above sentence read "if, = and only if, these appear...."? <>>>> RFC 8174 calls for this exact text. >>>> RS>> My remark above was more a "Strunk and White" remark. <>> RS1>> Changed, as requested. <>>>>=20 >>>>>>> Section 2 says: "... reuse of existing generic code ..."; I do = not know >>>>>>> what is meant by "generic". It either needs to be defined, = reworded, or >>>>>>> dropped. I note that elsewhere in the document "existing code" = is used. >>>>>> RS>> I will add a sentence to that effect, e.g., "(Here, generic = code refers to an implementation that does not depend on hardcoded = domain parameters (see also Section 6).)" <>>>> Thanks. >>>>>=20 >>>>>>> I expected Section 9 to say something about public keys being = unique >>>>>>> identifiers of the private key holder. >>>>>> RS>> I will add an extra paragraph to this effect, e.g., "Use of = a public key in any protocol for which successful execution evidences = knowledge of the corresponding private key implicitly indicates the = entity holding this private key. Reuse of this public key with more than = one protocol or more than one protocol instantiation may, therefore, = allow traceability of this entity." <>>>> Also, using the same public key with different addresses allows an = observer to correlate them. >>>> RS>> Indeed, one can correlate more stuff from meta-info that = includes the public key as a common data element (even if the observer = would not be able to check whether those are technically bound to this, = this would often work in practice). <>>=20 >>> RS1>>The added text now reads as follows: >>>=20 >>> Use of a public key in any protocol for which successful execution = evidences knowledge of the corresponding private key implicitly = indicates the entity holding this private key. Reuse of this public key = with more than one protocol or more than one protocol instantiation may, = therefore, allow traceability of this entity. It may also allow = correlation of meta-data communicated with this common data element = (e.g., different addressing information), even if an observer cannot = technically verify the binding of this meta-data. >>>=20 >>> <>>=20 >>>>>=20 >>>>>>> Some introduction text at the beginning of each Appendix would = be very >>>>>>> helpful. Please tell the reader what they will learn by delving = into >>>>>>> the subsections of the appendix. >>>>>> RS>> I will reflect on this somewhat more (while also considering = "guidance to the reader" remarks in Daniel Migault's Early IoTDir = review). Broadly speaking, though, inclusion of all these appendices = makes the entire docment self-contained, including arithmetic, = representations, how-to-convert details, etc. <>>>> Yes, I understand that. Some of the appendicies have introductory = text, but other do not. I think they all should have introductory text. >>>=20 >>> RS1>> I added some introductory text to each appendix. >>>=20 >>> <>>=20 >>>>>=20 >>>>>>> Nits: >>>>>>>=20 >>>>>>> Section 4.2 says: "... at the end of hereof ...". This does not = tell >>>>>>> me anything useful. I suggest deleting this phrase. >>>>>> RS>> I will change this to "at the end hereof" (i.e., will remove = "of" - a glitch). Here, one can only recover the y-coordinate at the end = of the Montgomery ladder, since one needs the x-coordinates of k*G and = (k+1)*G to make this work. <>>>> I think it would be better to say: ... at the end of the = Montgomery ladder ..." >>> RS1>> Changed as suggested. <>>>>=20 >>>>> Russ >>>>>=20 >>>>=20 >>>=20 >>=20 >> --=20 >> email: rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 >>=20 >=20 From nobody Thu Aug 6 12:07:55 2020 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 59BA83A0E03 for ; Thu, 6 Aug 2020 12:07:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <159674087275.14891.3151929846963640209@ietfa.amsl.com> Date: Thu, 06 Aug 2020 12:07:53 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 19:07:53 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-08-13 Reviewer LC end Draft Valery Smyslov 2020-03-31 draft-ietf-core-resource-directory-25 For telechat 2020-08-27 Reviewer LC end Draft Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-08 Last calls: Reviewer LC end Draft Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-08 Daniel Gillmor 2020-06-12 draft-ietf-pce-stateful-pce-lsp-scheduling-22 Dan Harkins None draft-ietf-rtgwg-policy-model-03 David Mandelberg 2020-07-14 draft-ietf-idr-rfc8203bis-06 Kathleen Moriarty 2020-07-20 draft-ietf-ace-oscore-profile-11 Russ Mundy 2020-07-20 draft-ietf-ace-dtls-authorize-12 Sandra Murphy None draft-ietf-netconf-keystore-19 Yoav Nir None draft-ietf-netconf-trust-anchors-12 Derrell Piper 2020-08-19 draft-ietf-mpls-base-yang-14 Tirumaleswar Reddy.K 2020-08-18 draft-ietf-roll-turnon-rfc8138-10 Vincent Roca 2020-04-23 draft-ietf-detnet-ip-over-mpls-06 Kyle Rose 2020-08-14 draft-ietf-cbor-date-tag-05 Joseph Salowey 2020-08-14 draft-ietf-regext-rdap-partial-response-13 Rich Salz 2020-08-14 draft-ietf-suit-architecture-11 Yaron Sheffer 2020-08-14 draft-ietf-cbor-7049bis-14 Rifaat Shekh-Yusef 2020-08-13 draft-ietf-regext-rdap-sorting-and-paging-15 Valery Smyslov 2020-03-31 draft-ietf-core-resource-directory-25 Robert Sparks 2020-08-10 draft-ietf-lamps-cms-update-alg-id-protect-02 Samuel Weiler 2020-06-11 draft-ietf-trill-multilevel-single-nickname-13 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-09 Paul Wouters 2020-05-25 draft-ietf-capport-architecture-08 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Early review requests: Reviewer Due Draft Magnus Nystrom 2020-08-06 draft-ietf-netconf-keystore-19 Next in the reviewer rotation: Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi Tina Tsou Sean Turner Mališa Vučinić Carl Wallace Samuel Weiler Brian Weis From nobody Sun Aug 9 13:22:47 2020 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 52DC73A0C23; Sun, 9 Aug 2020 13:22:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: last-call@ietf.org, draft-ietf-regext-rdap-sorting-and-paging.all@ietf.org, regext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159700455794.3835.2617295222782861901@ietfa.amsl.com> Reply-To: Rifaat Shekh-Yusef Date: Sun, 09 Aug 2020 13:22:38 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-regext-rdap-sorting-and-paging-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2020 20:22:39 -0000 Reviewer: Rifaat Shekh-Yusef Review result: Ready This document updates the existing Registration Data Access Protocol (RDAP) by adding new RDAP query extensions that allow clients to specify their preferences for sorting and paging result sets. The security considerations section of the document points to RFC7481 which discusses all security aspect of the RDAP, and discusses the risks associated with search queries and potential mitigation for these risks. From nobody Sun Aug 9 13:59:40 2020 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 25F2D3A0DC5 for ; Sun, 9 Aug 2020 13:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 mqGCDkXtkfjZ for ; Sun, 9 Aug 2020 13:59:33 -0700 (PDT) Received: from 7.mo178.mail-out.ovh.net (7.mo178.mail-out.ovh.net [46.105.58.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6873A0DC3 for ; Sun, 9 Aug 2020 13:59:33 -0700 (PDT) Received: from player761.ha.ovh.net (unknown [10.108.42.239]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id 52212AB652 for ; Sun, 9 Aug 2020 22:59:31 +0200 (CEST) Received: from mediaarea.net (unknown [62.147.199.69]) (Authenticated sender: jerome@mediaarea.net) by player761.ha.ovh.net (Postfix) with ESMTPSA id 999481522FF20; Sun, 9 Aug 2020 20:59:24 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-105G006bb29af51-604f-4982-904c-c52165724f13, 608671285ED90489EBE68BEB245C4D25BF85EF76) smtp.auth=jerome@mediaarea.net To: Michael Richardson , Liang Xia Cc: last-call@ietf.org, draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org, secdir@ietf.org References: <159537782564.14553.11293321898516651562@ietfa.amsl.com> <21179.1595526609@localhost> From: Jerome Martinez Message-ID: Date: Sun, 9 Aug 2020 22:59:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <21179.1595526609@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 7183804356546007064 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrkeeigdduheehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpeekhfdvgfeuhffggefhfffhtdehfffhudeuveejtdfgjefgleelueejheetfffgjeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedtrddtrddtrddtpdeivddrudegjedrudelledrieelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrjeeiuddrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvthdprhgtphhtthhopehsvggtughirhesihgvthhfrdhorhhg Archived-At: Subject: Re: [secdir] [Cellar] Secdir last call review of draft-ietf-cellar-ffv1-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2020 20:59:35 -0000 Hi, On 23/07/2020 19:50, Michael Richardson wrote: > Liang Xia via Datatracker wrote: > > But about my one question, I have not seen any response or actions: "Issues for > > clarification: In Security Considerations, besides the DoS attacks brought by > > the malicious payloads, is there any other kinds of attack possibly? For > > example, virus or worm are hidden in the malicious payloads to attack the > > system for more damages? Does it make sense and what's the consideration?" > > Hi, thank you for the review comments. > Aside from possible buffer-overflow attacks that would attempt to smash the > stack of a process, none of the content carried in ffv1 is intended to be executable. > > A virus or worm hidden in the payload would be rendered as if it was visual > data by normal software processing. > > Clearly, a malicious system could use the ffv1 format in an attempt to disquise > itself, but that would take a co-consipirator to extract that content. I second Michael on the lack of attack implying hidden content, as the expected output is only visual content. I added a pull request on the spec for adding an explicit mention of the lack of content intended to be executed at https://github.com/FFmpeg/FFV1/pull/224 , in addition to fixes of issues found during last call review at https://github.com/FFmpeg/FFV1/pull/223 Jérôme From nobody Sun Aug 9 22:29:48 2020 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 9A6563A08EB; Sun, 9 Aug 2020 22:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seC9NNj9d-MK; Sun, 9 Aug 2020 22:29:45 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 3E83C3A08A2; Sun, 9 Aug 2020 22:29:42 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id 93so6399091otx.2; Sun, 09 Aug 2020 22:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dq91Agw6cvbDrJOQhUAvccQn7gL8Zwpg4Vp3uTT8+1U=; b=fT7sb//PNmdnkTVYL1ohrH2Fp6lmqdSeBAK8Wp1kEM0njVoueUKzBOL6QgR+GCE/8c bCEMdielLQccz9SREu2hhRLBh7DLlPUqg0xlXpVc3KhwY/vx5v8Z4YcaLAG6ShVt2iAZ haq2RfRFbw/G9UrSvYysB9AHAc5r+RI8WNzM9fAO6KKjqLiWam1lP/gV7XOIbIDgKQQv CzRe4Wa5FVz8X5ZyFnxqhodDojXH00qcFYdaswEwhD5qF3pE3kcSVfHcqy///GhFyDaP Nv1J8RKIAw/PaymtomVMZUfZ141dt7N7w835IiWyx+8ez2RkQiPfXA8GFkv95YP5FCYR hdxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dq91Agw6cvbDrJOQhUAvccQn7gL8Zwpg4Vp3uTT8+1U=; b=GNYEXpy5IXmUSNAPKbMi3cVqnztqQJCLQVJmkxFI1Cw6iXa92L75Sh8+j82yqvetyA Ur274mu7cgXIGHi2IrSQtkjWgFzlqoYGAwgOxc9dEWRnfbbYp2hvBWqLrr7sUu+D3AEm nwNMXrFKuypM7Xxjc9lUn2O4ygzdMA+H16J1kXnARMUrfztXYNq0gnv7LW3Y6qj5F2/9 +Uy1I96lKVeQnoRdiGQ89tNEEC6T/GysntX0vQF12OuttXJLeLHU/4/roBxOyrOr2S6w 2FzrdRToVNyldDNFOmwszChHYlUHFXDGdFEjG29wzVYFs4S+SFQ9U23Y4Xg1B7cDr19n d8Zw== X-Gm-Message-State: AOAM532e+nwUDcbVCom0H+gzKGTGsygWyp2Hq+42fqZnAcPuXy0NT1yf IzKWLj2tHiGkAUsZ1jU+3PMdU7PTxQBNH/CzTKpt8bCl X-Google-Smtp-Source: ABdhPJytCssruFZmREgbQ3f0L7OQr859PcwhNW6Q3DlGLzVbPjnrCpq6k8GEbqOFOBvOlnX8SVyOFBxyFpleoUGbrUM= X-Received: by 2002:a9d:2203:: with SMTP id o3mr20639489ota.149.1597037381358; Sun, 09 Aug 2020 22:29:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Sun, 9 Aug 2020 22:29:32 -0700 Message-ID: To: secdir@ietf.org, draft-ietf-netconf-keystore@ietf.org Content-Type: multipart/alternative; boundary="000000000000cf17ef05ac7f3d1b" Archived-At: Subject: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 05:29:47 -0000 --000000000000cf17ef05ac7f3d1b Content-Type: text/plain; charset="UTF-8" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a new YANG model for centralized configuration of cryptographic keys in the context of NETCONF and RESTCONF. Section 4 describes a process to encrypt all "private" keys in a configuration. It is unclear if this refers only to the asymmetric keys in the configuration (as "private keys" normally refer to asymmetric keys) or also symmetric keys. It appears to apply to all cryptographic keys, and it therefore seems better to replace this usage of "private" with "symmetric and asymmetric private keys." Likewise, the use of the term "root key" is a bit unclear. A "root key" normally refers to an asymmetric key, but in this text it could be either. More broadly, it may be advantageous to consider a hierarchy, where a key encryption key is used to encrypt all keys in a configuration and this key encryption key in turn is protected by a root (or master) key. This way, two instances only need to share the key encryption key and there's no need for shared root keys (which may present an issue). Likewise, one can rotate or renew the key encryption key if desired, whereas this usually is harder for root keys. Section 5.2 first states: "The NACM "default-deny-all" extension has not been set for any data nodes defined in this module," ostensibly because "none of the readable data notes ... are considered sensitive." I note here that meta-data about keys oftentimes can provide valuable information about those keys and suggest considering if the default-deny-all extension should be set by default after all. *Editorial:* ( A few nits that I found ) Section 1: - Substitute "Trusted Protection Module" with "Trusted Platform Module" - The term "HSM" is used without explanation - Last sentence (starting: "It is also possible...") is garbled Section 1.1: - Sentence starting "Links the each" is garbled Section 3: - Second sentence starts "Built-in built-in keys..." /M --000000000000cf17ef05ac7f3d1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div class=3D"gmail_quote">
I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG. These= comments were written primarily for the benefit of the security area direc= tors.=C2=A0 Document editors and WG chairs should treat these comments just= like any other last call comments.

This document describes a new YANG model for centralize= d configuration of cryptographic keys in the context of NETCONF and RESTCON= F.
    Section 4 describes a process to encrypt = all "private" keys in a configuration. It is unclear if this refe= rs only to the asymmetric keys in the configuration (as "private keys&= quot; normally refer to asymmetric keys) or also symmetric keys. It appears= to apply to all cryptographic keys, and it therefore seems better to repla= ce this usage of "private" with "symmetric and asymmetric pr= ivate keys."

    Likewise, the use of the term &qu= ot;root key" is a bit unclear. A "root key" normally refers = to an asymmetric key, but in this text it could be either.

    More broadly, it may be advantageous to consider a hierarchy, where a k= ey encryption key is used to encrypt all keys in a configuration and this k= ey encryption key in turn is protected by a root (or master) key. This way,= two instances only need to share the key encryption key and there's no= need for shared root keys (which may present an issue). Likewise, one can = rotate or renew the key encryption key if desired, whereas this usually is = harder for root keys.

    =
    Section 5.2 first states: &qu= ot;The NACM "default-deny-all" extension has not been set for a= ny data nodes defined in this module," ostensibly because "none= of the readable data notes ... are considered sensitive." I note here= that meta-data about keys oftentimes can provide valuable information abou= t those keys and suggest considering if the default-deny-all extension shou= ld be set by default after all.

    Editorial:

    ( A few nits that I found )

    S= ection 1:
    • Substit= ute "Trusted Protection Module" with "Trusted Platform Modul= e"
    • The term "HSM" is used without explanation
      • Last sentence (starting: "It is also possible...") is garbled
    Section 1.1:
    • Sentence starting "Links the each" is garbled
      • =
    Section 3:
    • Second sentence starts "Built-i= n built-in keys..."
    /M
    =
    --000000000000cf17ef05ac7f3d1b-- From nobody Sun Aug 9 23:47:34 2020 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 F357D3A141A; Sun, 9 Aug 2020 23:47:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: Cc: core@ietf.org, draft-ietf-core-resource-directory.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159704204394.11310.18005109400419971010@ietfa.amsl.com> Reply-To: Valery Smyslov Date: Sun, 09 Aug 2020 23:47:23 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-core-resource-directory-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 06:47:24 -0000 Reviewer: Valery Smyslov Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The -24 version of this draft was reviewed by Adam Montville. I looked over his review and I think that the issue he raised about possible mitigation of DDoS amplification attacks has been addressed in this version. I personally think that sentences describing how DNS and NTP are vulnerable to amplification attacks are redundant in this document, but that's a matter of taste and doesn't hurt. It is my impression, that Security Considerations were mostly written having in mind that (D)TLS is always used, however it is only "SHOULD" in this draft (or even "MAY" if we look at RFC6690 which Security Considerations this draft refers to). I think that adding a few words describing which consequences for security not using (D)TLS would have and in which cases it is allowed will make the Security Considerations more consistent. From nobody Mon Aug 10 02:01:05 2020 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 1D1893A1414; Mon, 10 Aug 2020 02:00:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: cbor@ietf.org, last-call@ietf.org, draft-ietf-cbor-7049bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159705005508.2366.4819563096010229406@ietfa.amsl.com> Reply-To: Yaron Sheffer Date: Mon, 10 Aug 2020 02:00:55 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 09:00:55 -0000 Reviewer: Yaron Sheffer Review result: Has Nits This is an editorial, fully compatible update of RFC 7049 (the CBOR encoding). The Security Considerations have been significantly expanded, and they make sense to me. However, while the prose is all sensible, it doesn't seem like the best practical guidance for implementers. I would have appreciated a bullet list of potential implementation pitfalls, as well as a bullet list of decoder validation capabilities, such as are alluded to by the last sentence of the section. Upon a quick read, it is not even clear to me which parts of Sec. 5 are required/expected in a validating-mode decoder. From nobody Mon Aug 10 11:47:56 2020 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 6D3F33A0B10; Mon, 10 Aug 2020 11:47:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose via Datatracker To: Cc: draft-ietf-cbor-date-tag.all@ietf.org, last-call@ietf.org, cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159708526736.13725.2565339809870274299@ietfa.amsl.com> Reply-To: Kyle Rose Date: Mon, 10 Aug 2020 11:47:47 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-cbor-date-tag-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 18:47:48 -0000 Reviewer: Kyle Rose Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready with nits. I see no issues of interest to the security directorate. I do have three comments, however: * In the security considerations section, a better example might be the potential inappropriateness of using an imprecise mechanism for specifying certificate expiration. * It's not clear how this is intended to work for dates prior to the start of the Gregorian calendar in 1582. What do negative integer values mean when they imply a date before 15-Oct-1582? Is the Gregorian calendar defined for all time? In a brief investigation, I've been unable to find the answer to this. * In a very gross sense, this specification *is* actually tied to the prevailing timescale, leap seconds and all: if the whole world were to transition from UTC to TAI and stop adding leap seconds, presumably implementations would continue to generate dates for this specification by truncating the local timestamp to the date, which would cause it to drift along with TAI away from UTC over time. There wouldn't be a huge practical effect here given how little they are expected to diverge over the foreseeable future, but it would mean that dates encoded in this format today would not carry enough information to precisely indicate a date in the far future even if the target timescale were understood throughout since the source timescale isn't part of the encoding. From nobody Mon Aug 10 12:07:02 2020 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 5173E3A0B86; Mon, 10 Aug 2020 12:07:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Derrell Piper via Datatracker To: Cc: draft-ietf-mpls-base-yang.all@ietf.org, last-call@ietf.org, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159708642029.26538.15187840253454108442@ietfa.amsl.com> Reply-To: Derrell Piper Date: Mon, 10 Aug 2020 12:07:00 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mpls-base-yang-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:07:00 -0000 Reviewer: Derrell Piper Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. This is a minor update which adds only an Informative Reference. From nobody Mon Aug 10 12:25:03 2020 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 8DCE23A0C35 for ; Mon, 10 Aug 2020 12:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 zG4gcDxESMGN for ; Mon, 10 Aug 2020 12:24:56 -0700 (PDT) Received: from p3plsmtpa09-01.prod.phx3.secureserver.net (p3plsmtpa09-01.prod.phx3.secureserver.net [173.201.193.230]) (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 A8B703A0C1C for ; Mon, 10 Aug 2020 12:24:56 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 5DPjkCbls3pta5DPkk3dLg; Mon, 10 Aug 2020 12:24:56 -0700 X-CMAE-Analysis: v=2.3 cv=ea1DgIMH c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=48vgC7mUAAAA:8 a=83biogrR7TfdnlKm6MUA:9 a=CjuIK1q_8ugA:10 a=-lDN3miqRCKsXIsiMS0A:9 a=RqEnPhNPTZkw_uGG:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_ACC591DB-889D-4050-85EF-D388D1BE4D85" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 10 Aug 2020 12:24:55 -0700 In-Reply-To: <159705005508.2366.4819563096010229406@ietfa.amsl.com> Cc: secdir@ietf.org, cbor@ietf.org, draft-ietf-cbor-7049bis.all@ietf.org, last-call@ietf.org To: Yaron Sheffer References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfIbeHPiwZF4IonxJzsDM5rW5WvhFRTxqsxC1OmatxkGRbpK2MBUz0nES+hvuLzV+XZB1Fma0L4kyXgYdBqrCNuTAvLSrR41SyvYB7Leu4vdplKVnF0VI dGc1bOsXG/n6pPmavKKj92SRJMloZuUz9FSQZpNQN9Ze0D1/+e6nw6wr/puhxggTkPWzsbIy0u+a+t5Q0u1jdwfLOS2EL9yoG+aF6NLcIu2q0qXmBGtatZHZ GCnWgc5GWxjlzKasHSy3bOMZJxyozBFrpzBU8OWUxGy8StwAOmgWRgNPbbIhs//hUdJXNYl+bVApGyb50A6N8Q== Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:24:58 -0000 --Apple-Mail=_ACC591DB-889D-4050-85EF-D388D1BE4D85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 10, 2020, at 2:00 AM, Yaron Sheffer via Datatracker = wrote: >=20 > Upon a quick read, it is not even clear to me which parts of Sec. 5 > are required/expected in a validating-mode decoder. A generic decoder can do as little or as much validity checking as it = wants to. What is required is that it documents what validity checking = it does not do and that it does not prevent the user of the generic = decoder from doing the validity checks. The reason for this is that some validity checking is expensive for a = CBOR decoder and is inexpensive for the consumer of the data. Checking = the validity of UTF-8 or MIME-encoded messages are examples of this. LL= --Apple-Mail=_ACC591DB-889D-4050-85EF-D388D1BE4D85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Aug 10, 2020, at 2:00 AM, Yaron Sheffer via Datatracker <noreply@ietf.org> = wrote:

    Upon a quick read, it is not = even clear to me which parts of Sec. 5
    are required/expected in a validating-mode = decoder.

    A = generic decoder can do as little or as much validity checking as it = wants to. What is required is that it documents what validity checking = it does not do and that it does not prevent the user of the generic = decoder from doing the validity checks.

    The reason for this is that some = validity checking is expensive for a CBOR decoder and is inexpensive for = the consumer of the data. Checking the validity of UTF-8 or MIME-encoded = messages are examples of this.

    LL
    = --Apple-Mail=_ACC591DB-889D-4050-85EF-D388D1BE4D85-- From nobody Mon Aug 10 12:26:13 2020 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 3E09F3A0C36; Mon, 10 Aug 2020 12:26:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: last-call@ietf.org, draft-ietf-lamps-cms-update-alg-id-protect.all@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159708756719.15053.15537532147789441272@ietfa.amsl.com> Reply-To: Robert Sparks Date: Mon, 10 Aug 2020 12:26:07 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lamps-cms-update-alg-id-protect-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 19:26:07 -0000 Reviewer: Robert Sparks 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. This document is ready for publication as Proposed Standard RFC. >From the abstract: > This document updates the Cryptographic Message Syntax (CMS) > specified in RFC 5652 to ensure that algorithm identifiers in signed- > data and authenticated-data content types are adequately protected. I sent minor nits directly to the editor. From nobody Mon Aug 10 13:24:58 2020 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 B64143A0D2B; Mon, 10 Aug 2020 13:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.573, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Og2E5w1YjSrW; Mon, 10 Aug 2020 13:24:48 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 408563A0D23; Mon, 10 Aug 2020 13:24:48 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id a5so9404428wrm.6; Mon, 10 Aug 2020 13:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=AKfSvr1qGuFtK9wmI2mKX+3hnGeItBCCnnZZ5gyPh7o=; b=GxXvMXUpWoreJTJkb4lUz29qZk0tGszqmL3hqjPnTnwuZScpXHSIYzaZacNKQ9C6n2 eEsqwWuaGLD9KMfmJLXUomJWk1hC1cbpc2JO5VSSTX5JWNr0jMVWxUbqVrGnMLZD+3LD JVjCUFzrvFSih2QR58ptBy1VHuj6GXs8Vms5pHC0lA8Qgh0Rh3A4NhpffDIWiKSMLJse pAt1oHbgpApWbzp2sN/O3XdizodWmH/p6k2TA/0SaIInpdjAlqtsK8Z7n76vcxCZcvwy 9z9DejuQLIFlzrUoIf6bTIBMBoFdg/uns8wXEh+6W3MZXjYZV06QC0OTcbilasHq/Mmt H7Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=AKfSvr1qGuFtK9wmI2mKX+3hnGeItBCCnnZZ5gyPh7o=; b=QV/P9hDAtZA9YEBriPBnP0Uijtd2759Ff2AdWGlj0O56qEXgnypqJuG9vT+O3CGdVC w67FNtOD+1yTuUdTRi4DOaAAbDtA3/h+8wEKkLFj8LqrWex1qHqCSkqJquapl9Ei7/Mf qzWS7+mUYbBTIAXiEGBcneSXEybasOcB1/wtumGn2u60ASn5HHrecpmraTWU0hBywo6A Vkg9CW25FXb3WATamTKzXWpjZE1TxOXRXNfc5bY5plANQJnnl/i5MSBt4CSqtGGh2/oh wyWcPN6UL2cQRxSCjjGI2Z+9YUlTMDLDbPxE6V1Lr08bzzZ2yuBnWkiITYi6BFD9DHbR Eifw== X-Gm-Message-State: AOAM530JsGjYYIahYBYejryhRArJ3yDhdwiYiS6NXhIGo6RNSjr6MqVL oeWeRgYIPsvPYZA4NNPTV3M= X-Google-Smtp-Source: ABdhPJykGYa+NKNrPKOTSnvnPIOSZWtcrIFZUCqJap+PdQlCWE5m+IX3F5OTyl+1e5kI+2MoQR1ioA== X-Received: by 2002:a5d:400e:: with SMTP id n14mr2911146wrp.75.1597091086812; Mon, 10 Aug 2020 13:24:46 -0700 (PDT) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id p6sm21626062wru.33.2020.08.10.13.24.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2020 13:24:46 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Mon, 10 Aug 2020 23:24:44 +0300 From: Yaron Sheffer To: Laurence Lundblade CC: , , , Message-ID: Thread-Topic: [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3679946685_595924970" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 20:24:50 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3679946685_595924970 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On Aug 10, 2020, at 2:00 AM, Yaron Sheffer via Datatracker wrote: =20 Upon a quick read, it is not even clear to me which parts of Sec. 5 are required/expected in a validating-mode decoder. =20 A generic decoder can do as little or as much validity checking as it wants= to. What is required is that it documents what validity checking it does no= t do and that it does not prevent the user of the generic decoder from doing= the validity checks. =20 The reason for this is that some validity checking is expensive for a CBOR = decoder and is inexpensive for the consumer of the data. Checking the validi= ty of UTF-8 or MIME-encoded messages are examples of this. =20 LL =20 I understand that, but realistically, without a list of (potential) validit= y checks in the RFC, there will be wide variance in what is documented by de= coders =E2=80=93 if any. In fact I checked a few implementations just now, and mos= t of them do not document what validity checks they perform. Those that docu= ment something are hard to compare. If you make a canonical list, people wou= ld have a starting point. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron --B_3679946685_595924970 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

    On Aug 10, 2020, at 2:00 AM, Yaron Sheffer via Dat= atracker <noreply@ietf.org> wrot= e:

     

    Upon a quick read, it is not even= clear to me which parts of Sec. 5
    are required/expected in a validating-= mode decoder.

     

    A generic decoder can do as = little or as much validity checking as it wants to. What is required is that= it documents what validity checking it does not do and that it does not pre= vent the user of the generic decoder from doing the validity checks.

     

    The reason for this is that some validity checking is expensive = for a CBOR decoder and is inexpensive for the consumer of the data. Checking= the validity of UTF-8 or MIME-encoded messages are examples of this.

     

    LL

     

    I understand that, but realistically, without a list of (potent= ial) validity checks in the RFC, there will be wide variance in what is docu= mented by decoders =E2=80=93 if any. In fact I checked a few implementations just = now, and most of them do not document what validity checks they perform. Tho= se that document something are hard to compare. If you make a canonical list= , people would have a starting point.

    =  

    Thanks,

    = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

    --B_3679946685_595924970-- From nobody Mon Aug 10 13:33:46 2020 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 54B243A0D45 for ; Mon, 10 Aug 2020 13:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 u4HgFDSH18Bg for ; Mon, 10 Aug 2020 13:33:41 -0700 (PDT) Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4805D3A0D3A for ; Mon, 10 Aug 2020 13:33:41 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 5ES5khEwTIGql5ES5kTCjl; Mon, 10 Aug 2020 13:31:26 -0700 X-CMAE-Analysis: v=2.3 cv=DMrxHBFb c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=LrfFbBZ_wH084i7_Up0A:9 a=QEXdDO2ut3YA:10 a=-RC9aWaX5pnV8SCgf80A:9 a=FkYPizaky_nWIz-_:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0F3FBFC2-638C-4BCC-B7FB-140628B61867" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 10 Aug 2020 13:31:25 -0700 In-Reply-To: Cc: secdir@ietf.org, cbor@ietf.org, draft-ietf-cbor-7049bis.all@ietf.org, last-call@ietf.org To: Yaron Sheffer References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfKN/6HdOYYBE+KfQcZObCH+tvjgMdeoFo8uPNc8ZdjbzNH/yF0EU2G2E7c6sErcBvJOjFzD8vZzEMULk3qtUlJvGYVR8r0NRys7mS44H0YMQg8s+Pyzy GvNIiKcbTIdF4GQuR0PSpeGnkxHgBwhFzHIE0eLyfLtoGbolzHOMYaWQGUDP6Y9fiNwdnirSNVL9iBd3RrrrNGFtbjal/OGzTTT+mOQE4ccpR+Y0oBdhB2vk vFvTtRxe19PUkN+1/IhjdZsbvyLNcB6RGT7B1wzueVD/sicNfdqvYDTrQtkl1aEhht7241sgzoy7y/34J7mbsw== Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 20:33:42 -0000 --Apple-Mail=_0F3FBFC2-638C-4BCC-B7FB-140628B61867 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 10, 2020, at 1:24 PM, Yaron Sheffer = wrote: >=20 > On Aug 10, 2020, at 2:00 AM, Yaron Sheffer via Datatracker = > wrote: >> =20 >> Upon a quick read, it is not even clear to me which parts of Sec. 5 >> are required/expected in a validating-mode decoder. >=20 > =20 > A generic decoder can do as little or as much validity checking as it = wants to. What is required is that it documents what validity checking = it does not do and that it does not prevent the user of the generic = decoder from doing the validity checks. > =20 > The reason for this is that some validity checking is expensive for a = CBOR decoder and is inexpensive for the consumer of the data. Checking = the validity of UTF-8 or MIME-encoded messages are examples of this. > =20 > LL > =20 > I understand that, but realistically, without a list of (potential) = validity checks in the RFC, there will be wide variance in what is = documented by decoders =E2=80=93 if any. In fact I checked a few = implementations just now, and most of them do not document what validity = checks they perform. Those that document something are hard to compare. = If you make a canonical list, people would have a starting point. Having made a few crude lists of validity checks myself to try to = understand what was what, such a list seems reasonable to me. LL --Apple-Mail=_0F3FBFC2-638C-4BCC-B7FB-140628B61867 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

    On Aug 10, 2020, at 1:24 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

    On Aug 10, 2020, at 2:00 = AM, Yaron Sheffer via Datatracker <noreply@ietf.org> wrote:
     
    Upon a = quick read, it is not even clear to me which parts of Sec. 5
    are required/expected in a validating-mode = decoder.
     
    A generic decoder can do as little or = as much validity checking as it wants to. What is required is that it = documents what validity checking it does not do and that it does not = prevent the user of the generic decoder from doing the validity = checks.
     
    The reason for this is that some = validity checking is expensive for a CBOR decoder and is inexpensive for = the consumer of the data. Checking the validity of UTF-8 or MIME-encoded = messages are examples of this.
     
    LL
     
    I understand that, but = realistically, without a list of (potential) validity checks in the RFC, = there will be wide variance in what is documented by decoders =E2=80=93 = if any. In fact I checked a few implementations just now, and most of = them do not document what validity checks they perform. Those that = document something are hard to compare. If you make a canonical list, = people would have a starting = point.

    Having made a few crude lists of validity checks = myself to try to understand what was what, such a list seems reasonable = to me.

    LL


    = --Apple-Mail=_0F3FBFC2-638C-4BCC-B7FB-140628B61867-- From nobody Mon Aug 10 15:45:45 2020 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 8E45C3A0DCD; Mon, 10 Aug 2020 15:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muF9-6YiCddL; Mon, 10 Aug 2020 15:45:32 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7A23A0DCC; Mon, 10 Aug 2020 15:45:31 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BQWJP1DWVzyX6; Tue, 11 Aug 2020 00:45:25 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 11 Aug 2020 00:45:24 +0200 Cc: Laurence Lundblade , cbor@ietf.org, draft-ietf-cbor-7049bis.all@ietf.org, last-call@ietf.org, secdir@ietf.org X-Mao-Original-Outgoing-Id: 618792324.550929-fcd412e65053451cdfda2e66f3582eb2 Content-Transfer-Encoding: quoted-printable Message-Id: <6A1090D8-D012-4A04-BC4A-9CF23E791DA2@tzi.org> References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 22:45:35 -0000 On 2020-08-10, at 22:24, Yaron Sheffer wrote: >=20 > I understand that, but realistically, without a list of (potential) = validity checks in the RFC, there will be wide variance in what is = documented by decoders =E2=80=93 if any. In fact I checked a few = implementations just now, and most of them do not document what validity = checks they perform. Those that document something are hard to compare. = If you make a canonical list, people would have a starting point. To be fair, you probably checked RFC 7049 implementations, and RFC 7049 = didn=E2=80=99t have such a requirement (improving the discussion of = validity was one of the major work items in 7049bis, see Appendix G.3). One point to keep in mind is that, with CBOR, most validity processing = happens in the processing of tags, and that is an extension point. So a = list in 7049bis will never be complete. Even if it only covers base = CBOR and the tags registered in 7049/7049bis, a detailed version is = likely to be tedious and highly dependent of specific implementation = approaches. Trying to imagine the outcome of this exercise, my visual image right = now is a PICS Proforma, so I think I=E2=80=99ll better stop here... Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 10 17:53:04 2020 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 89C433A0E6B; Mon, 10 Aug 2020 17:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 gvYkRNgRFhEZ; Mon, 10 Aug 2020 17:53:01 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 222183A0E6C; Mon, 10 Aug 2020 17:53:00 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07B0quax027088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Aug 2020 20:52:58 -0400 Date: Mon, 10 Aug 2020 17:52:55 -0700 From: Benjamin Kaduk To: Alexey Melnikov Cc: "secdir@ietf.org" , draft-ietf-mmusic-msrp-usage-data-channel.all@ietf.org Message-ID: <20200811005255.GY92412@kduck.mit.edu> 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: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-mmusic-msrp-usage-data-channel-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 00:53:03 -0000 Hi Alexey, Thanks for this review -- I agree that the RFC 5547 security considerations are quite important, and it's good to mention the SIP considerations as well (even if they are technically optional). Christer, thanks for the updates -- I balloted No Objection. -Ben On Mon, Jul 20, 2020 at 01:46:42PM +0100, Alexey Melnikov wrote: > Reviewer: Alexey Melnikov > Review result: Ready with Nits > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > The subject matter is outside my area of expertise and proper > understanding of the document requires reading of several referenced > documents. But I think I got the gist of what the document is trying to do. > > The Security Consideration talks about data channels providing > confidentiality, integrity and source authentication for MSRP traffic, > which is good. It also points out to discussion of MSRP message > attribution in RFC 4975. > > However, session setup is done over SIP, which has different security > considerations and nothing is mentioned about that. In particular, one > of normatively referenced documents RFC 5547 has very good Security > Considerations section (section 10) that talks about possible attacks on > file transfer negotiation. I think this should be referenced in the > document. > > I also feel that more can be said about possible use of MSRP for > transferring of malicious files/images. > > In Section 6: > > o The gateway SHALL use CEMA towards the non-data channel endpoint. > > Please explain and/or add a reference for CEMA. > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Mon Aug 10 18:26:12 2020 Return-Path: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@amazonses.watsen.net> 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 5FFCB3A0E96; Mon, 10 Aug 2020 18:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.775 X-Spam-Level: X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MPART_ALT_DIFF_COUNT=1.112, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 F6M-AWu_gD6B; Mon, 10 Aug 2020 18:26:05 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7065E3A0E90; Mon, 10 Aug 2020 18:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1597109162; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=+pu/ICJW+qXIqb1sBpeYmdw/d3D1GaQQF9OCyh14zjM=; b=OLqvdlFntFKpEsCfsTiDv54UP03g+GLCNTJwUfnaOZwVFSqa1GxLJfrA4O28pZ49 ahi0mGcSFjw4iBRDd3Y9C0gwuhedxecHaMQTNRoqp6Z661rcGKeTRycrQ5JX5MIWAn9 3xwecuDDaC2MWWoME1/wsnM1zYF4W+V9fVX5dcsQ= From: Kent Watsen Message-ID: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_518AADA0-8A96-4313-A9A2-A4525C31C72F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 11 Aug 2020 01:26:00 +0000 In-Reply-To: Cc: secdir@ietf.org, draft-ietf-netconf-keystore@ietf.org, "netconf-chairs@ietf.org" To: =?utf-8?Q?Magnus_Nystr=C3=B6m?= References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.11-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 01:26:11 -0000 --Apple-Mail=_518AADA0-8A96-4313-A9A2-A4525C31C72F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [CC-ing netconf-chairs] Hi Magnus, Thank you for the review. Below are some comments, as well as a link to = the GitHub commit, and an updated plain-text version of the draft. Thanks, Kent > On Aug 10, 2020, at 1:29 AM, Magnus Nystr=C3=B6m = wrote: >=20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > This document describes a new YANG model for centralized configuration = of cryptographic keys in the context of NETCONF and RESTCONF. > Section 4 describes a process to encrypt all "private" keys in a = configuration. It is unclear if this refers only to the asymmetric keys = in the configuration (as "private keys" normally refer to asymmetric = keys) or also symmetric keys. It appears to apply to all cryptographic = keys, and it therefore seems better to replace this usage of "private" = with "symmetric and asymmetric private keys." Good catch. r/all the private keys/both the symmetric and asymmetric = keys/ > Likewise, the use of the term "root key" is a bit unclear. A "root = key" normally refers to an asymmetric key, but in this text it could be = either. >=20 > More broadly, it may be advantageous to consider a hierarchy, where a = key encryption key is used to encrypt all keys in a configuration and = this key encryption key in turn is protected by a root (or master) key. = This way, two instances only need to share the key encryption key and = there's no need for shared root keys (which may present an issue). = Likewise, one can rotate or renew the key encryption key if desired, = whereas this usually is harder for root keys. What you say is the intention, but the terminology used seems to be off. = The alignment needed is: Root key =E2=80=94> Master Encryption Key (MEK) Shared root key =E2=80=94> Key Encryption Key (KEK) > Section 5.2 first states: "The NACM "default-deny-all" extension has = not been set for any data nodes defined in this module," ostensibly = because "none of the readable data notes ... are considered sensitive." = I note here that meta-data about keys oftentimes can provide valuable = information about those keys and suggest considering if the = default-deny-all extension should be set by default after all. I think there is a subtly you may be missing. The keystore module uses = the key definitions defined in the crypt-types draft. In that draft, = the key data *is* flagged with the =E2=80=9Cnacm:default-deny-all=E2=80=9D= extension. So the key data itself (e.g., an ECPrivateKey or AESKey, in = OpenSSL parlance) is protected. Is that sufficient to protect the key = metadata mentioned...or are you concerned about the =E2=80=9Ckey-format=E2= =80=9D and/or =E2=80=9Cpublic-key=E2=80=9D nodes being readable? > Editorial: >=20 > ( A few nits that I found ) >=20 > Section 1:=20 > Substitute "Trusted Protection Module" with "Trusted Platform Module" > The term "HSM" is used without explanation Both fixed in my local copy - thanks! > Last sentence (starting: "It is also possible...") is garbled Now reads: "It is also possible that a=20 system implementing this module possesses a multiplicity of operating system level keystore utilities and/or HSMs." Better? > Section 1.1: > Sentence starting "Links the each" is garbled > Section 3: > Second sentence starts "Built-in built-in keys..." Both fixed in my local copy - thanks! The GitHub commit enacting the updates is here: = https://github.com/netconf-wg/keystore/commit/5b3b9f3db0d6b7027ddf5f0e983a= b958e8802251 = The plain-text version of the updated draft is attached. Thanks again! Kent > /M --Apple-Mail=_518AADA0-8A96-4313-A9A2-A4525C31C72F Content-Type: multipart/mixed; boundary="Apple-Mail=_2BD894E7-8F93-499E-9519-B4271E11B9F2" --Apple-Mail=_2BD894E7-8F93-499E-9519-B4271E11B9F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    [CC-ing netconf-chairs]


    Hi Magnus,

    Thank you for the = review.  Below are some comments, as well as a link to the GitHub = commit, and an updated plain-text version of the draft.

    Thanks,
    Kent


    On Aug 10, 2020, at 1:29 AM, Magnus Nystr=C3=B6= m <magnusn@gmail.com> wrote:

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

    This document = describes a new YANG model for centralized configuration of = cryptographic keys in the context of NETCONF and RESTCONF.
      Section 4 describes a = process to encrypt all "private" keys in a configuration. It is unclear = if this refers only to the asymmetric keys in the configuration (as = "private keys" normally refer to asymmetric keys) or also symmetric = keys. It appears to apply to all cryptographic keys, and it therefore = seems better to replace this usage of "private" with "symmetric and = asymmetric private keys."

      Good catch.  r/all the private keys/both the = symmetric and asymmetric keys/


      Likewise, the use of the = term "root key" is a bit unclear. A "root key" normally refers to an = asymmetric key, but in this text it could be either.

      More broadly, it may be = advantageous to consider a hierarchy, where a key encryption key is used = to encrypt all keys in a configuration and this key encryption key in = turn is protected by a root (or master) key. This way, two instances = only need to share the key encryption key and there's no need for shared = root keys (which may present an issue). Likewise, one can rotate or = renew the key encryption key if desired, whereas this usually is harder = for root keys.

      What you say is the intention, but the terminology = used seems to be off.   The alignment needed is:

        Root key =E2=80=94> Master Encryption = Key (MEK)
        Shared root key =E2=80=94> Key Encryption = Key (KEK)



      Section 5.2 first states: = "The NACM "default-deny-all" extension has not been set for any data = nodes defined in this module," ostensibly because "none of the = readable data notes ... are considered sensitive." I note here that = meta-data about keys oftentimes can provide valuable information about = those keys and suggest considering if the default-deny-all extension = should be set by default after = all.

      I think there is a subtly you may be missing. =  The keystore module uses the key definitions defined in the = crypt-types draft.  In that draft, the key data *is* flagged with = the =E2=80=9Cnacm:default-deny-all=E2=80=9D extension.  So the key = data itself (e.g., an ECPrivateKey or AESKey, in OpenSSL parlance) is = protected.  Is that sufficient to protect the key metadata = mentioned...or are you concerned about the =E2=80=9Ckey-format=E2=80=9D = and/or =E2=80=9Cpublic-key=E2=80=9D nodes being readable?


      Editorial:

      ( A few nits that I found = )

      Section 1:
      • Substitute "Trusted Protection Module" with "Trusted Platform = Module"
      • The term "HSM" is used without = explanation
      Both = fixed in my local copy - thanks!

      • Last sentence (starting: "It is also possible...") is = garbled

      Now reads:

                "It is also = possible that a 
              =   system implementing this module possesses = a multiplicity of
              =   operating system level keystore utilities = and/or HSMs."

      Better?



      Section 1.1:
      • Sentence starting "Links the each" is = garbled
      Section 3:
      • Second sentence starts "Built-in built-in = keys..."
      <= div>
      Both fixed in my local copy - = thanks!




        The = plain-text version of the updated draft is attached.

        Thanks again!
        Kent


        /M


        = --Apple-Mail=_2BD894E7-8F93-499E-9519-B4271E11B9F2 Content-Disposition: attachment; filename=draft-ietf-netconf-keystore-20.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-netconf-keystore-20.txt" Content-Transfer-Encoding: quoted-printable NETCONF Working Group K. Watsen Internet-Draft Watsen Networks Intended status: Standards Track 10 August 2020 Expires: 11 February 2021 A YANG Data Model for a Keystore draft-ietf-netconf-keystore-20 Abstract This document defines a YANG 1.1 module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted. Asymmetric keys may be associated with certificates. Notifications are sent when certificates are about to expire. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "CCCC" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * "2020-08-10" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Watsen Expires 11 February 2021 [Page 1] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 11 February 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relation to other RFCs . . . . . . . . . . . . . . . . . 4 1.2. Specification Language . . . . . . . . . . . . . . . . . 5 1.3. Adherence to the NMDA . . . . . . . . . . . . . . . . . . 5 2. The "ietf-keystore" Module . . . . . . . . . . . . . . . . . 5 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 12 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 23 3. Support for Built-in Keys . . . . . . . . . . . . . . . . . . 31 4. Encrypting Keys in Configuration . . . . . . . . . . . . . . 34 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 5.1. Data at Rest . . . . . . . . . . . . . . . . . . . . . . 38 5.2. The "ietf-keystore" YANG Module . . . . . . . . . . . . . 38 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 6.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 39 6.2. The "YANG Module Names" Registry . . . . . . . . . . . . 39 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.1. Normative References . . . . . . . . . . . . . . . . . . 39 7.2. Informative References . . . . . . . . . . . . . . . . . 40 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 42 Watsen Expires 11 February 2021 [Page 2] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 42 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 42 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 42 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 42 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 43 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 43 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 43 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 43 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 43 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 44 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 44 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 44 A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 45 A.14. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 45 A.15. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 45 A.16. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 45 A.17. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 45 A.18. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 46 A.19. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 46 A.20. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 46 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 46 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 46 1. Introduction This document defines a YANG 1.1 [RFC7950] module called "ietf- keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted. Asymmetric keys may be associated with certificates. Notifications are sent when certificates are about to expire. The "ietf-keystore" module defines many "grouping" statements intended for use by other modules that may import it. For instance, there are groupings that defined enabling a key to be either configured locally (within the defining data model) or be a reference to a key in the Keystore. Special consideration has been given for systems that have cryptographic hardware, such as a Trusted Platform Module (TPM). These systems are unique in that the cryptographic hardware hides the secret key values. To support such hardware, symmetric keys may have the value "hidden-key" and asymmetric keys may have the value "hidden-private-key". While how such keys are created or destroyed is outside the scope of this document, the Keystore can contain entries for such keys, enabling them to be referenced by other configuration elements. Watsen Expires 11 February 2021 [Page 3] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 It is not required that a system has an operating system level keystore utility, with or without HSM (hardware security module) backing, to implement this module. It is also possible that a system implementing this module possesses a multiplicity of operating system level keystore utilities and/or HSMs. 1.1. Relation to other RFCs This document presents one or more YANG modules [RFC7950] that are part of a collection of RFCs that work together to define configuration modules for clients and servers of both the NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. The modules have been defined in a modular fashion to enable their use by other efforts, some of which are known to be in progress at the time of this writing, with many more expected to be defined in time. The relationship between the various RFCs in the collection is presented in the below diagram. The labels in the diagram represent the primary purpose provided by each RFC. Links to each RFC are provided below the diagram. crypto-types ^ ^ / \ / \ truststore keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Watsen Expires 11 February 2021 [Page 4] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 +-----------------------+-------------------------------------------+ | Label in Diagram | Originating RFC | +-----------------------+-------------------------------------------+ | crypto-types | [I-D.ietf-netconf-crypto-types] | +-----------------------+-------------------------------------------+ | truststore | [I-D.ietf-netconf-trust-anchors] | +-----------------------+-------------------------------------------+ | keystore | [I-D.ietf-netconf-keystore] | +-----------------------+-------------------------------------------+ | tcp-client-server | [I-D.ietf-netconf-tcp-client-server] | +-----------------------+-------------------------------------------+ | ssh-client-server | [I-D.ietf-netconf-ssh-client-server] | +-----------------------+-------------------------------------------+ | tls-client-server | [I-D.ietf-netconf-tls-client-server] | +-----------------------+-------------------------------------------+ | http-client-server | [I-D.ietf-netconf-http-client-server] | +-----------------------+-------------------------------------------+ | netconf-client-server | [I-D.ietf-netconf-netconf-client-server] | +-----------------------+-------------------------------------------+ |restconf-client-server | [I-D.ietf-netconf-restconf-client-server] | +-----------------------+-------------------------------------------+ Table 1: Label to RFC Mapping 1.2. Specification Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.3. Adherence to the NMDA This document in compliant with Network Management Datastore Architecture (NMDA) [RFC8342]. For instance, keys and associated certificates installed during manufacturing (e.g., for an IDevID [Std-802.1AR-2009] certificate) are expected to appear in (see Section 3). 2. The "ietf-keystore" Module This section defines a YANG 1.1 [RFC7950] module that defines a "keystore" and groupings supporting downstream modules to reference the keystore or have locally-defined definitions. 2.1. Data Model Overview Watsen Expires 11 February 2021 [Page 5] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 2.1.1. Features The following diagram lists all the "feature" statements defined in the "ietf-keystore" module: Features: +-- keystore-supported +-- local-definitions-supported 2.1.2. Typedefs The following diagram lists the "typedef" statements defined in the "ietf-keystore" module: Typedefs: leafref +-- symmetric-key-ref +-- asymmetric-key-ref Comments: * All of the typedefs defined in the "ietf-keystore" module extend the base "leafref" type defined in [RFC7950]. * The leafrefs refer to symmetric and asymmetric keys in the keystore. These typedefs are provided primarily as an aid to downstream modules that import the "ietf-keystore" module. 2.1.3. Groupings The following diagram lists all the "grouping" statements defined in the "ietf-keystore" module: Groupings: +-- encrypted-by-choice-grouping +-- asymmetric-key-certificate-ref-grouping +-- local-or-keystore-symmetric-key-grouping +-- local-or-keystore-asymmetric-key-grouping +-- local-or-keystore-asymmetric-key-with-certs-grouping +-- local-or-keystore-end-entity-cert-with-key-grouping +-- keystore-grouping Each of these groupings are presented in the following subsections. 2.1.3.1. The "encrypted-by-choice-grouping" Grouping The following tree diagram [RFC8340] illustrates the "encrypted-by- choice-grouping" grouping: Watsen Expires 11 February 2021 [Page 6] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 | The grouping's name is intended to be parsed "(encrypted-by)- | (choice-grouping)", not as "(encrypted)-(by- | choice)-(grouping)". grouping encrypted-by-choice-grouping +-- (encrypted-by-choice) +--:(symmetric-key-ref) | +-- symmetric-key-ref? | -> /keystore/symmetric-keys/symmetric-key/name +--:(asymmetric-key-ref) +-- asymmetric-key-ref? -> /keystore/asymmetric-keys/asymmetric-key/name Comments: * This grouping defines a "choice" statement with options to reference either a symmetric or an asymmetric key configured in the keystore. 2.1.3.2. The "asymmetric-key-certificate-ref-grouping" Grouping The following tree diagram [RFC8340] illustrates the "asymmetric-key- certificate-ref-grouping" grouping: grouping asymmetric-key-certificate-ref-grouping +-- asymmetric-key? ks:asymmetric-key-ref +-- certificate? leafref Comments: * This grouping defines a reference to a certificate in two parts: the first being the name of the asymmetric key the certificate is associated with, and the second being the name of the certificate itself. 2.1.3.3. The "local-or-keystore-symmetric-key-grouping" Grouping The following tree diagram [RFC8340] illustrates the "local-or- keystore-symmetric-key-grouping" grouping: grouping local-or-keystore-symmetric-key-grouping +-- (local-or-keystore) +--:(local) {local-definitions-supported}? | +-- local-definition | +---u ct:symmetric-key-grouping +--:(keystore) {keystore-supported}? +-- keystore-reference? ks:symmetric-key-ref Watsen Expires 11 February 2021 [Page 7] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 Comments: * The "local-or-keystore-symmetric-key-grouping" grouping is provided soley as convenience to downstream modules that wish to offer an option as to if an symmetric key is defined locally or as a reference to a symmetric key in the keystore. * A "choice" statement is used to expose the various options. Each option is enabled by a "feature" statement. Additional "case" statements MAY be augmented in if, e.g., there is a need to reference a symmetric key in an alternate location. * For the "local-definition" option, the defintion uses the "symmetric-key-grouping" grouping discussed in Section 2.1.3.2 of [I-D.ietf-netconf-crypto-types]. * For the "keystore" option, the "keystore-reference" is an instance of the "symmetric-key-ref" discussed in Section 2.1.2. 2.1.3.4. The "local-or-keystore-asymmetric-key-grouping" Grouping The following tree diagram [RFC8340] illustrates the "local-or- keystore-asymmetric-key-grouping" grouping: grouping local-or-keystore-asymmetric-key-grouping +-- (local-or-keystore) +--:(local) {local-definitions-supported}? | +-- local-definition | +---u ct:asymmetric-key-pair-grouping +--:(keystore) {keystore-supported}? +-- keystore-reference? ks:asymmetric-key-ref Comments: * The "local-or-keystore-asymmetric-key-grouping" grouping is provided soley as convenience to downstream modules that wish to offer an option as to if an asymmetric key is defined locally or as a reference to a asymmetric key in the keystore. * A "choice" statement is used to expose the various options. Each option is enabled by a "feature" statement. Additional "case" statements MAY be augmented in if, e.g., there is a need to reference a asymmetric key in an alternate location. * For the "local-definition" option, the defintion uses the "asymmetric-key-pair-grouping" grouping discussed in Section 2.1.3.4 of [I-D.ietf-netconf-crypto-types]. Watsen Expires 11 February 2021 [Page 8] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 * For the "keystore" option, the "keystore-reference" is an instance of the "asymmetric-key-ref" typedef discussed in Section 2.1.2. 2.1.3.5. The "local-or-keystore-asymmetric-key-with-certs-grouping" Grouping The following tree diagram [RFC8340] illustrates the "local-or- keystore-asymmetric-key-with-certs-grouping" grouping: grouping local-or-keystore-asymmetric-key-with-certs-grouping +-- (local-or-keystore) +--:(local) {local-definitions-supported}? | +-- local-definition | +---u ct:asymmetric-key-pair-with-certs-grouping +--:(keystore) {keystore-supported}? +-- keystore-reference? ks:asymmetric-key-ref Comments: * The "local-or-keystore-asymmetric-key-with-certs-grouping" grouping is provided soley as convenience to downstream modules that wish to offer an option as to if an asymmetric key is defined locally or as a reference to a asymmetric key in the keystore. * A "choice" statement is used to expose the various options. Each option is enabled by a "feature" statement. Additional "case" statements MAY be augmented in if, e.g., there is a need to reference a asymmetric key in an alternate location. * For the "local-definition" option, the defintion uses the "asymmetric-key-pair-with-certs-grouping" grouping discussed in Section 2.1.3.10 of [I-D.ietf-netconf-crypto-types]. * For the "keystore" option, the "keystore-reference" is an instance of the "asymmetric-key-ref" typedef discussed in Section 2.1.2. 2.1.3.6. The "local-or-keystore-end-entity-cert-with-key-grouping" Grouping The following tree diagram [RFC8340] illustrates the "local-or- keystore-end-entity-cert-with-key-grouping" grouping: Watsen Expires 11 February 2021 [Page 9] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 grouping local-or-keystore-end-entity-cert-with-key-grouping +-- (local-or-keystore) +--:(local) {local-definitions-supported}? | +-- local-definition | +---u ct:asymmetric-key-pair-with-cert-grouping +--:(keystore) {keystore-supported}? +-- keystore-reference +---u asymmetric-key-certificate-ref-grouping Comments: * The "local-or-keystore-end-entity-cert-with-key-grouping" grouping is provided soley as convenience to downstream modules that wish to offer an option as to if an symmetric key is defined locally or as a reference to a symmetric key in the keystore. * A "choice" statement is used to expose the various options. Each option is enabled by a "feature" statement. Additional "case" statements MAY be augmented in if, e.g., there is a need to reference a symmetric key in an alternate location. * For the "local-definition" option, the defintion uses the "asymmetric-key-pair-with-certs-grouping" grouping discussed in Section 2.1.3.10 of [I-D.ietf-netconf-crypto-types]. * For the "keystore" option, the "keystore-reference" uses the "asymmetric-key-certificate-ref-grouping" grouping discussed in Section 2.1.3.2. 2.1.3.7. The "keystore-grouping" Grouping The following tree diagram [RFC8340] illustrates the "keystore- grouping" grouping: grouping keystore-grouping +-- asymmetric-keys | +-- asymmetric-key* [name] | +-- name? string | +---u ct:asymmetric-key-pair-with-certs-grouping +-- symmetric-keys +-- symmetric-key* [name] +-- name? string +---u ct:symmetric-key-grouping Comments: Watsen Expires 11 February 2021 [Page 10] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 * The "keystore-grouping" grouping is defines a keystore instance as being composed of symmetric and asymmetric keys. The stucture for the symmetric and asymmetric keys is essentially the same, being a "list" inside a "container". * For asymmetric keys, each "asymmetric-key" uses the "asymmetric- key-pair-with-certs-grouping" grouping discussed Section 2.1.3.10 of [I-D.ietf-netconf-crypto-types]. * For symmetric keys, each "symmetric-key" uses the "symmetric-key- grouping" grouping discussed Section 2.1.3.2 of [I-D.ietf-netconf-crypto-types]. 2.1.4. Protocol-accessible Nodes The following diagram lists all the protocol-accessible nodes defined in the "ietf-keystore" module: module: ietf-keystore +--rw keystore +--rw asymmetric-keys | +--rw asymmetric-key* [name] | +--rw name string | +--rw public-key-format identityref | +--rw public-key binary | +--rw private-key-format? identityref | +--rw (private-key-type) | | +--:(cleartext-private-key) | | | +--rw cleartext-private-key? binary | | +--:(hidden-private-key) | | | +--rw hidden-private-key? empty | | +--:(encrypted-private-key) | | +--rw encrypted-private-key | | +--rw encrypted-by | | | +--rw (encrypted-by-choice) | | | +--:(symmetric-key-ref) | | | | +--rw symmetric-key-ref? leafref | | | +--:(asymmetric-key-ref) | | | +--rw asymmetric-key-ref? leafref | | +--rw encrypted-value binary | +--rw certificates | | +--rw certificate* [name] | | +--rw name string | | +--rw cert-data end-entity-cert-cms | | +---n certificate-expiration | | +-- expiration-date yang:date-and-time | +---x generate-certificate-signing-request | {certificate-signing-request-generation}? Watsen Expires 11 February 2021 [Page 11] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 | +---w input | | +---w csr-info ct:csr-info | +--ro output | +--ro certificate-signing-request ct:csr +--rw symmetric-keys +--rw symmetric-key* [name] +--rw name string +--rw key-format? identityref +--rw (key-type) +--:(cleartext-key) | +--rw cleartext-key? binary +--:(hidden-key) | +--rw hidden-key? empty +--:(encrypted-key) +--rw encrypted-key +--rw encrypted-by | +--rw (encrypted-by-choice) | +--:(symmetric-key-ref) | | +--rw symmetric-key-ref? leafref | +--:(asymmetric-key-ref) | +--rw asymmetric-key-ref? leafref +--rw encrypted-value binary Comments: * Protocol-accessible nodes are those nodes that are accessible when the module is "implemented", as described in Section 5.6.5 of [RFC7950]. * For the "ietf-keystore" module, the protcol-accessible nodes are an instance of the "keystore-grouping" discussed in Section 2.1.3.7 grouping. Note that, in this diagram, all the used groupings have been expanded, enabling the keystore's full structure to be seen. * The reason for why "keystore-grouping" exists separate from the protocol-accessible nodes definition is so as to enable instances of the keystore to be instantiated in other locations, as may be needed or desired by some modules. 2.2. Example Usage The examples in this section are encoded using XML, such as might be the case when using the NETCONF protocol. Other encodings MAY be used, such as JSON when using the RESTCONF protocol. Watsen Expires 11 February 2021 [Page 12] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 2.2.1. A Keystore Instance The following example illustrates keys in . Please see Section 3 for an example illustrating built-in values in . =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NOTE: '\' line wrapping = per RFC 8792 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D cleartext-symmetric-key ct:octet-string-key-format base64encodedvalue=3D=3D hidden-symmetric-key encrypted-symmetric-key ct:encrypted-one-symmetric-key-format hidden-asymmetric-key base64encodedvalue=3D=3D ssh-rsa-key ct:ssh-public-key-format base64encodedvalue=3D=3D ct:rsa-private-key-format base64encodedvalue=3D=3D Watsen Expires 11 February 2021 [Page 13] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 ssh-rsa-key-with-cert ct:subject-public-key-info-format base64encodedvalue=3D=3D ct:rsa-private-key-format base64encodedvalue=3D=3D ex-rsa-cert2 base64encodedvalue=3D=3D raw-private-key ct:subject-public-key-info-format base64encodedvalue=3D=3D ct:rsa-private-key-format base64encodedvalue=3D=3D rsa-asymmetric-key ct:subject-public-key-info-format base64encodedvalue=3D=3D ct:rsa-private-key-format base64encodedvalue=3D=3D ex-rsa-cert base64encodedvalue=3D=3D Watsen Expires 11 February 2021 [Page 14] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 ec-asymmetric-key ct:subject-public-key-info-format base64encodedvalue=3D=3D ct:ec-private-key-format base64encodedvalue=3D=3D ex-ec-cert base64encodedvalue=3D=3D hidden-asymmetric-key ct:subject-public-key-info-format base64encodedvalue=3D=3D builtin-idevid-cert base64encodedvalue=3D=3D my-ldevid-cert base64encodedvalue=3D=3D encrypted-asymmetric-key ct:subject-public-key-info-format base64encodedvalue=3D=3D ct:encrypted-one-asymmetric-key-format Watsen Expires 11 February 2021 [Page 15] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 encrypted-symmetric-key base64encodedvalue=3D=3D 2.2.2. A Certificate Expiration Notification The following example illustrates a "certificate-expiration" notification for a certificate associated with a key configured in the keystore. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NOTE: '\' line wrapping = per RFC 8792 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2018-05-25T00:01:00Z hidden-asymmetric-key my-ldevid-cert 2018-08-05T14:18:53-05:00 2.2.3. The "Local or Keystore" Groupings This section illustrates the various "local-or-keystore" groupings defined in the "ietf-keystore" module, specifically the "local-or- keystore-symmetric-key-grouping" (Section 2.1.3.3), "local-or- keystore-asymmetric-key-grouping" (Section 2.1.3.4), "local-or- keystore-asymmetric-key-with-certs-grouping" (Section 2.1.3.5), and "local-or-keystore-end-entity-cert-with-key-grouping" (Section 2.1.3.6) groupings. Watsen Expires 11 February 2021 [Page 16] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 The following non-normative module is defined to illustrate these groupings: module ex-keystore-usage { yang-version 1.1; namespace "http://example.com/ns/example-keystore-usage"; prefix "eku"; import ietf-keystore { prefix ks; reference "RFC CCCC: A YANG Data Model for a Keystore"; } organization "Example Corporation"; contact "Author: YANG Designer "; description "This module illustrates notable groupings defined in the 'ietf-keystore' module."; revision "2020-08-10" { description "Initial version"; reference "RFC CCCC: A YANG Data Model for a Keystore"; } container keystore-usage { description "An illustration of the various keystore groupings."; list symmetric-key { key name; leaf name { type string; description "An arbitrary name for this key."; } uses ks:local-or-keystore-symmetric-key-grouping; description "An symmetric key that may be configured locally or be a reference to a symmetric key in the keystore."; } Watsen Expires 11 February 2021 [Page 17] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 list asymmetric-key { key name; leaf name { type string; description "An arbitrary name for this key."; } uses ks:local-or-keystore-asymmetric-key-grouping; description "An asymmetric key, with no certs, that may be configured locally or be a reference to an asymmetric key in the keystore. The intent is to reference just the asymmetric key, not any certificates that may also be associated with the asymmetric key."; } list asymmetric-key-with-certs { key name; leaf name { type string; description "An arbitrary name for this key."; } uses ks:local-or-keystore-asymmetric-key-with-certs-grouping; description "An asymmetric key and its associated certs, that may be configured locally or be a reference to an asymmetric key (and its associated certs) in the keystore."; } list end-entity-cert-with-key { key name; leaf name { type string; description "An arbitrary name for this key."; } uses ks:local-or-keystore-end-entity-cert-with-key-grouping; description "An end-entity certificate, and its associated private key, that may be configured locally or be a reference to a specific certificate (and its associated private key) in the keystore."; } } } Watsen Expires 11 February 2021 [Page 18] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 The tree diagram [RFC8340] for this example module follows: module: ex-keystore-usage +--rw keystore-usage +--rw symmetric-key* [name] | +--rw name string | +--rw (local-or-keystore) | +--:(local) {local-definitions-supported}? | | +--rw local-definition | | +--rw key-format? identityref | | +--rw (key-type) | | +--:(cleartext-key) | | | +--rw cleartext-key? binary | | +--:(hidden-key) | | | +--rw hidden-key? empty | | +--:(encrypted-key) | | +--rw encrypted-key | | +--rw encrypted-by | | +--rw encrypted-value binary | +--:(keystore) {keystore-supported}? | +--rw keystore-reference? ks:symmetric-key-ref +--rw asymmetric-key* [name] | +--rw name string | +--rw (local-or-keystore) | +--:(local) {local-definitions-supported}? | | +--rw local-definition | | +--rw public-key-format identityref | | +--rw public-key binary | | +--rw private-key-format? identityref | | +--rw (private-key-type) | | +--:(cleartext-private-key) | | | +--rw cleartext-private-key? binary | | +--:(hidden-private-key) | | | +--rw hidden-private-key? empty | | +--:(encrypted-private-key) | | +--rw encrypted-private-key | | +--rw encrypted-by | | +--rw encrypted-value binary | +--:(keystore) {keystore-supported}? | +--rw keystore-reference? ks:asymmetric-key-ref +--rw asymmetric-key-with-certs* [name] | +--rw name string | +--rw (local-or-keystore) | +--:(local) {local-definitions-supported}? | | +--rw local-definition | | +--rw public-key-format | | | identityref | | +--rw public-key binary Watsen Expires 11 February 2021 [Page 19] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 | | +--rw private-key-format? | | | identityref | | +--rw (private-key-type) | | | +--:(cleartext-private-key) | | | | +--rw cleartext-private-key? binary | | | +--:(hidden-private-key) | | | | +--rw hidden-private-key? empty | | | +--:(encrypted-private-key) | | | +--rw encrypted-private-key | | | +--rw encrypted-by | | | +--rw encrypted-value binary | | +--rw certificates | | | +--rw certificate* [name] | | | +--rw name string | | | +--rw cert-data | | | | end-entity-cert-cms | | | +---n certificate-expiration | | | +-- expiration-date yang:date-and-time | | +---x generate-certificate-signing-request | | {certificate-signing-request-generation}? | | +---w input | | | +---w csr-info ct:csr-info | | +--ro output | | +--ro certificate-signing-request ct:csr | +--:(keystore) {keystore-supported}? | +--rw keystore-reference? ks:asymmetric-key-ref +--rw end-entity-cert-with-key* [name] +--rw name string +--rw (local-or-keystore) +--:(local) {local-definitions-supported}? | +--rw local-definition | +--rw public-key-format | | identityref | +--rw public-key binary | +--rw private-key-format? | | identityref | +--rw (private-key-type) | | +--:(cleartext-private-key) | | | +--rw cleartext-private-key? binary | | +--:(hidden-private-key) | | | +--rw hidden-private-key? empty | | +--:(encrypted-private-key) | | +--rw encrypted-private-key | | +--rw encrypted-by | | +--rw encrypted-value binary | +--rw cert-data? | | end-entity-cert-cms | +---n certificate-expiration Watsen Expires 11 February 2021 [Page 20] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 | | +-- expiration-date yang:date-and-time | +---x generate-certificate-signing-request | {certificate-signing-request-generation}? | +---w input | | +---w csr-info ct:csr-info | +--ro output | +--ro certificate-signing-request ct:csr +--:(keystore) {keystore-supported}? +--rw keystore-reference +--rw asymmetric-key? ks:asymmetric-key-ref +--rw certificate? leafref The following example provides two equivalent instances of each grouping, the first being a reference to a keystore and the second being locally-defined. The instance having a reference to a keystore is consistent with the keystore defined in Section 2.2.1. The two instances are equivalent, as the locally-defined instance example contains the same values defined by the keystore instance referenced by its sibling example. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NOTE: '\' line wrapping = per RFC 8792 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D example 1a cleartext-symmetric-key example 1b ct:octet-string-key-format base64encodedvalue=3D=3D example 2a Watsen Expires 11 February 2021 [Page 21] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 rsa-asymmetric-key example 2b ct:subject-public-key-info-format base64encodedvalue=3D=3D ct:rsa-private-key-format base64encodedvalue=3D=3D example 3a rsa-asymmetric-key example 3b ct:subject-public-key-info-format base64encodedvalue=3D=3D ct:rsa-private-key-format base64encodedvalue=3D=3D a locally-defined cert base64encodedvalue=3D=3D Watsen Expires 11 February 2021 [Page 22] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 example 4a rsa-asymmetric-key ex-rsa-cert example 4b ct:subject-public-key-info-format base64encodedvalue=3D=3D ct:rsa-private-key-format base64encodedvalue=3D=3D base64encodedvalue=3D=3D 2.3. YANG Module This YANG module has normative references to [RFC8341] and [I-D.ietf-netconf-crypto-types]. file "ietf-keystore@2020-08-10.yang" module ietf-keystore { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-keystore"; prefix ks; import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control Model"; } import ietf-crypto-types { Watsen Expires 11 February 2021 [Page 23] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 prefix ct; reference "RFC AAAA: YANG Data Types and Groupings for Cryptography"; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: Author: Kent Watsen "; description "This module defines a Keystore to centralize management of security credentials. Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC CCCC (https://www.rfc-editor.org/info/rfcCCCC); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2020-08-10 { description "Initial version"; reference "RFC CCCC: A YANG Data Model for a Keystore"; } /****************/ /* Features */ /****************/ Watsen Expires 11 February 2021 [Page 24] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 feature keystore-supported { description "The 'keystore-supported' feature indicates that the server supports the Keystore."; } feature local-definitions-supported { description "The 'local-definitions-supported' feature indicates that the server supports locally-defined keys."; } /****************/ /* Typedefs */ /****************/ typedef symmetric-key-ref { type leafref { path "/ks:keystore/ks:symmetric-keys/ks:symmetric-key" + "/ks:name"; } description "This typedef enables modules to easily define a reference to a symmetric key stored in the Keystore."; } typedef asymmetric-key-ref { type leafref { path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" + "/ks:name"; } description "This typedef enables modules to easily define a reference to an asymmetric key stored in the Keystore."; } /*****************/ /* Groupings */ /*****************/ grouping encrypted-by-choice-grouping { description "A grouping that defines a choice enabling references to other keys."; choice encrypted-by-choice { nacm:default-deny-write; mandatory true; description Watsen Expires 11 February 2021 [Page 25] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 "A choice amongst other symmetric or asymmetric keys."; case symmetric-key-ref { leaf symmetric-key-ref { type leafref { path "/ks:keystore/ks:symmetric-keys/" + "ks:symmetric-key/ks:name"; } description "Identifies the symmetric key used to encrypt this key."; } } case asymmetric-key-ref { leaf asymmetric-key-ref { type leafref { path "/ks:keystore/ks:asymmetric-keys/" + "ks:asymmetric-key/ks:name"; } description "Identifies the asymmetric key used to encrypt this key."; } } } } grouping asymmetric-key-certificate-ref-grouping { description "This grouping defines a reference to a specific certificate associated with an asymmetric key stored in the Keystore."; leaf asymmetric-key { nacm:default-deny-write; type ks:asymmetric-key-ref; must '../certificate'; description "A reference to an asymmetric key in the Keystore."; } leaf certificate { nacm:default-deny-write; type leafref { path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key[ks:" + "name =3D = current()/../asymmetric-key]/ks:certificates" + "/ks:certificate/ks:name"; } must '../asymmetric-key'; description "A reference to a specific certificate of the asymmetric key in the Keystore."; } } Watsen Expires 11 February 2021 [Page 26] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 // local-or-keystore-* groupings grouping local-or-keystore-symmetric-key-grouping { description "A grouping that expands to allow the symmetric key to be either stored locally, within the using data model, or be a reference to a symmetric key stored in the Keystore."; choice local-or-keystore { nacm:default-deny-write; mandatory true; description "A choice between an inlined definition and a definition that exists in the Keystore."; case local { if-feature "local-definitions-supported"; container local-definition { description "Container to hold the local key definition."; uses ct:symmetric-key-grouping; } } case keystore { if-feature "keystore-supported"; leaf keystore-reference { type ks:symmetric-key-ref; description "A reference to an symmetric key that exists in the Keystore."; } } } } grouping local-or-keystore-asymmetric-key-grouping { description "A grouping that expands to allow the asymmetric key to be either stored locally, within the using data model, or be a reference to an asymmetric key stored in the Keystore."; choice local-or-keystore { nacm:default-deny-write; mandatory true; case local { if-feature "local-definitions-supported"; container local-definition { description "Container to hold the local key definition."; uses ct:asymmetric-key-pair-grouping; } Watsen Expires 11 February 2021 [Page 27] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 } case keystore { if-feature "keystore-supported"; leaf keystore-reference { type ks:asymmetric-key-ref; description "A reference to an asymmetric key that exists in the Keystore. The intent is to reference just the asymmetric key without any regard for any certificates that may be associated with it."; } } description "A choice between an inlined definition and a definition that exists in the Keystore."; } } grouping local-or-keystore-asymmetric-key-with-certs-grouping { description "A grouping that expands to allow an asymmetric key and its associated certificates to be either stored locally, within the using data model, or be a reference to an asymmetric key (and its associated certificates) stored in the Keystore."; choice local-or-keystore { nacm:default-deny-write; mandatory true; case local { if-feature "local-definitions-supported"; container local-definition { description "Container to hold the local key definition."; uses ct:asymmetric-key-pair-with-certs-grouping; } } case keystore { if-feature "keystore-supported"; leaf keystore-reference { type ks:asymmetric-key-ref; description "A reference to an asymmetric-key (and all of its associated certificates) in the Keystore."; } } description "A choice between an inlined definition and a definition that exists in the Keystore."; } Watsen Expires 11 February 2021 [Page 28] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 } grouping local-or-keystore-end-entity-cert-with-key-grouping { description "A grouping that expands to allow an end-entity certificate (and its associated private key) to be either stored locally, within the using data model, or be a reference to a specific certificate in the Keystore."; choice local-or-keystore { nacm:default-deny-write; mandatory true; case local { if-feature "local-definitions-supported"; container local-definition { description "Container to hold the local key definition."; uses ct:asymmetric-key-pair-with-cert-grouping; } } case keystore { if-feature "keystore-supported"; container keystore-reference { uses asymmetric-key-certificate-ref-grouping; description "A reference to a specific certificate (and its associated private key) in the Keystore."; } } description "A choice between an inlined definition and a definition that exists in the Keystore."; } } grouping keystore-grouping { description "Grouping definition enables use in other contexts. If ever done, implementations SHOULD augment new 'case' statements into local-or-keystore 'choice' statements to supply leafrefs to the new location."; container asymmetric-keys { nacm:default-deny-write; description "A list of asymmetric keys."; list asymmetric-key { key "name"; description "An asymmetric key."; Watsen Expires 11 February 2021 [Page 29] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 leaf name { type string; description "An arbitrary name for the asymmetric key."; } uses ct:asymmetric-key-pair-with-certs-grouping; } } container symmetric-keys { nacm:default-deny-write; description "A list of symmetric keys."; list symmetric-key { key "name"; description "A symmetric key."; leaf name { type string; description "An arbitrary name for the symmetric key."; } uses ct:symmetric-key-grouping; } } } // grouping keystore-grouping /*********************************/ /* Protocol accessible nodes */ /*********************************/ container keystore { description "The Keystore contains a list of symmetric keys and a list of asymmetric keys."; nacm:default-deny-write; uses keystore-grouping { augment "symmetric-keys/symmetric-key/key-type/encrypted-key/" + "encrypted-key/encrypted-by" { description "Augments in a choice statement enabling the encrypting key to be any other symmetric or asymmetric key in the keystore."; uses encrypted-by-choice-grouping; } augment "asymmetric-keys/asymmetric-key/private-key-type/" + "encrypted-private-key/encrypted-private-key/" Watsen Expires 11 February 2021 [Page 30] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 + "encrypted-by" { description "Augments in a choice statement enabling the encrypting key to be any other symmetric or asymmetric key in the keystore."; uses encrypted-by-choice-grouping; } } } } 3. Support for Built-in Keys In some implementations, a server may support built-in keys. Built- in keys MAY be set during the manufacturing process or be dynamically generated the first time the server is booted or a particular service (e.g., SSH) is enabled. The key characteristic of the built-in keys is that they are provided by the system, as opposed to configuration. As such, they are present in . The example below illustrates what the keystore in might look like for a server in its factory default state. Manufacturer-Generated Hidden Key ct:subject-public-key-info-format base64encodedvalue=3D=3D Manufacturer-Generated IDevID Cert base64encodedvalue=3D=3D Watsen Expires 11 February 2021 [Page 31] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 In order for the built-in keys (and/or their associated built-in certificates) to be referenced by configuration, the referenced keys MUST first be copied into . The keys SHOULD be copied into using the same "key" values, so that the server can bind the references to the built-in entries. Built-in "hidden" keys cannot be copied into other parts of the configuration because their private parts are hidden, and therefore impossible to replicate. Built-in "encrypted" keys MAY be copied into other parts of the configuration so long as they maintain their reference to the other built-in key that encrypted them. Only the referenced keys need to be copied; that is, the keys in MAY be a subset of the built-in keys define in . No keys may be added or changed (with exception to associating additional certificates to a built-in key); that is, the keys in MUST be a subset (which includes the whole of the set) of the built-in keys define in . A server MUST reject attempts to modify any aspect of built-in keys, with exception to associating additional certificates to a built-in key. That these keys are "configured" in is an illusion, as they are strictly a read-only subset of that which must already exist in . The following example illustrates how a single built-in key definition from the previous example has been propagated to : Watsen Expires 11 February 2021 [Page 32] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 Manufacturer-Generated Hidden Key ct:subject-public-key-info-format base64encodedvalue=3D=3D Manufacturer-Generated IDevID Cert base64encodedvalue=3D=3D Deployment-Specific LDevID Cert base64encodedvalue=3D=3D After the above configuration is applied, should appear as follows: Watsen Expires 11 February 2021 [Page 33] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 Manufacturer-Generated Hidden Key ct:subject-public-key-info-format base64encodedvalue=3D=3D Manufacturer-Generated IDevID Cert base64encodedvalue=3D=3D Deployment-Specific LDevID Cert base64encodedvalue=3D=3D 4. Encrypting Keys in Configuration This section describes an approach that enables both the symmetric and asymmetric keys on a server to be encrypted, such that traditional backup/restore procedures can be used without concern for the keys being compromised when in transit. 4.1. Key Encryption Key The ability to encrypt configured keys is predicated on the existence of a "key encryption key" (KEK). The KEK, by its namesake, is a key that is used to encrypt other keys. The KEK MAY be either a symmetric key or an asymmetric key. If the KEK is a symmetric key, then the server MUST provide an API for administrators to encrypt other keys without needing to know the symmetric key's value. If the KEK is an asymmetric key, then the server MAY provide an API enabling the encryption of other keys or, alternatively, let the administrators do so themselves using the asymmetric key's public half. Watsen Expires 11 February 2021 [Page 34] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 A server MUST possess (or be able to possess) the KEK's cleartext value so that it can decrypt the other keys in the configurion at runtime. 4.2. Configuring Encrypted Keys Each time a new key is configured, it SHOULD be encrypted by the KEK. In "ietf-crypto-types" [I-D.ietf-netconf-crypto-types], the format for an encrypted symmetric key is described by the "encrypted-one- symmetric-key-format" identity, while the format for an encrypted asymmetric key is described by the "encrypted-one-asymmetric-key- format" identity Implementations SHOULD provide an API that simultaneously generates and encrypts a key (symmetric or asymmetric) using the KEK. Thusly newly generated key cleartext values are never known to the administrators generating the keys. In case the server implementation does not provide such an API, then the generating and encrypting steps MAY be performed outside the server, e.g., by an administrator with special access control rights (e.g., an organization's crypto officer). In either case, the encrypted key can be configured into the Keystore using either the "encrypted-key" (for symmetric keys) or the "encrypted-private-key" (for asymmetric keys) nodes. These two nodes contain both the encrypted value as well as a reference to the KEK that encrypted the key. 4.3. Migrating Configuration to Another Server When a KEK is used to encrypt other keys, migrating the configuration to another server is only possible if the second server has the same KEK. How the second server comes to have the same KEK is discussed in this section. In some deployments, mechanisms outside the scope of this document may be used to migrate the root key from one server to another. That said, beware that the ability to do so typically entails having access to the first server but, in many RMA scenarios, the first server may no longer be operational. In other deployments, an organization's crypto officer, posessing the KEK's cleartext value, configures the same KEK on the second server, presumably as a hidden key so that the cleartext value is not Watsen Expires 11 February 2021 [Page 35] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 disclosed to regular administrators. However, this approach creates high-coupling to and dependency on the crypto officers that doesn't scale in production environments. In order to decouple the crypto officers from the regular administrators, a second KEK, called the "master encryption key" (MEK), is used. A MEK is commonly a globally-unique built-in (see Section 3) asymmetric key for which the private key is hidden and the public key is contained in an identity certificate (e.g., IDevID). Assuming the servers has a MEK, the MEK can be used to encrypt a "shared KEK", which is then used to encrypt the keys configured by regular administrators. With this extra level of indirection, it is possible for a crypto officer to encrypt the same KEK for a multiplicity of servers offline using the public key contained in their identity certificates. The crypto officer can then safely handoff the encrypted KEKs to the regular administrators responsible for server installations, including migrations. In order to migrate the configuration from a first server, an administrator would need to make just a single modification to the configuration before loading it onto a second server, which is to replace the encrypted KEK Keystore entry from the first server with the encrypted KEK for the second server. Upon doing this, the configuration (containing many encrypted keys) can be loaded into the second server while enabling the second server to decrypt all the encrypted keys in the configuration. The following diagram illustrates this idea: Watsen Expires 11 February 2021 [Page 36] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 +-------------+ +-------------+ | shared KEK | | shared KEK | |(unencrypted)|-------------------------------> | (encrypted) | +-------------+ encrypts offline using +-------------+ ^ each server's MEK | | | | | | possesses \o | +-------------- |\ | / \ shares with | crypto +--------------------+ officer | | | +----------------------+ | +----------------------+ | server-1 | | | server-2 | | configuration | | | configuration | | | | | | | | | | | | +----------------+ | | | +----------------+ | | | MEK-1 | | | | | MEK-2 | | | | (hidden) | | | | | (hidden) | | | +----------------+ | | | +----------------+ | | ^ | | | ^ | | | | | | | | | | | | | | | | | encrypted | | | | encrypted | | | by | | | | by | | | | | | | | | | | | | | | | +----------------+ | | | +----------------+ | | | shared KEK | | | | | shared KEK | | | | (encrypted) | | v | | (encrypted) | | | +----------------+ | | +----------------+ | | ^ | regular | ^ | | | | admin | | | | | | | | | | | encrypted | \o | | encrypted | | | by | |\ | | by | | | | / \ | | | | | | | | | | +----------------+ |----------------->| +----------------+ | | | all other keys | | migrate | | all other keys | | | | (encrypted) | | configuration | | (encrypted) | | | +----------------+ | | +----------------+ | | | | | +----------------------+ +----------------------+ Watsen Expires 11 February 2021 [Page 37] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 5. Security Considerations 5.1. Data at Rest The YANG module defined in this document defines a mechanism called a "keystore" that, by its name, suggests that it will protect its contents from unauthorized disclosure and modification. Security controls for the API (i.e., data in motion) are discussed in Section 5.2, but controls for the data at rest cannot be specified by the YANG module. In order to satisfy the expectations of a "keystore", it is RECOMMENDED that implementations ensure that the keystore contents are encrypted when persisted to non-volatile memory. 5.2. The "ietf-keystore" YANG Module The YANG module defined in this document is designed to be accessed via YANG based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols have mandatory-to- implement secure transport layers (e.g., SSH, TLS) with mutual authentication. The NETCONF access control model (NACM) [RFC8341] provides the means to restrict access for particular users to a pre-configured subset of all available protocol operations and content. None of the readable data nodes defined in this YANG module are considered sensitive or vulnerable in network environments. The NACM "default-deny-all" extension has not been set for any data nodes defined in this module. | Please be aware that this module uses the "key" and "private- | key" nodes from the "ietf-crypto-types" module | [I-D.ietf-netconf-crypto-types], where said nodes have the NACM | extension "default-deny-all" set, thus preventing unrestricted | read-access to the cleartext key values. All of the writable data nodes defined by this module, both in the "grouping" statements as well as the protocol-accessible "keystore" instance, may be considered sensitive or vulnerable in some network environments.. For instance, any modification to a key or reference to a key may dramatically alter the implemented security policy. For this reason, the NACM extension "default-deny-write" has been set for all data nodes defined in this module. Watsen Expires 11 February 2021 [Page 38] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 This module does not define any RPCs, actions, or notifications, and thus the security consideration for such is not provided here. 6. IANA Considerations 6.1. The "IETF XML" Registry This document registers one URI in the "ns" subregistry of the IETF XML Registry [RFC3688]. Following the format in [RFC3688], the following registration is requested: URI: urn:ietf:params:xml:ns:yang:ietf-keystore Registrant Contact: The NETCONF WG of the IETF. XML: N/A, the requested URI is an XML namespace. 6.2. The "YANG Module Names" Registry This document registers one YANG module in the YANG Module Names registry [RFC6020]. Following the format in [RFC6020], the the following registration is requested: name: ietf-keystore namespace: urn:ietf:params:xml:ns:yang:ietf-keystore prefix: ks reference: RFC CCCC 7. References 7.1. Normative References [I-D.ietf-netconf-crypto-types] Watsen, K., "YANG Data Types and Groupings for Cryptography", Work in Progress, Internet-Draft, draft- ietf-netconf-crypto-types-17, 10 July 2020, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . Watsen Expires 11 February 2021 [Page 39] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . 7.2. Informative References [I-D.ietf-netconf-http-client-server] Watsen, K., "YANG Groupings for HTTP Clients and HTTP Servers", Work in Progress, Internet-Draft, draft-ietf- netconf-http-client-server-04, 8 July 2020, . [I-D.ietf-netconf-keystore] Watsen, K., "A YANG Data Model for a Keystore", Work in Progress, Internet-Draft, draft-ietf-netconf-keystore-19, 10 July 2020, . [I-D.ietf-netconf-netconf-client-server] Watsen, K., "NETCONF Client and Server Models", Work in Progress, Internet-Draft, draft-ietf-netconf-netconf- client-server-20, 8 July 2020, . [I-D.ietf-netconf-restconf-client-server] Watsen, K., "RESTCONF Client and Server Models", Work in Progress, Internet-Draft, draft-ietf-netconf-restconf- client-server-20, 8 July 2020, . [I-D.ietf-netconf-ssh-client-server] Watsen, K. and G. Wu, "YANG Groupings for SSH Clients and SSH Servers", Work in Progress, Internet-Draft, draft- ietf-netconf-ssh-client-server-21, 10 July 2020, . [I-D.ietf-netconf-tcp-client-server] Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients and TCP Servers", Work in Progress, Internet-Draft, draft- Watsen Expires 11 February 2021 [Page 40] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 ietf-netconf-tcp-client-server-07, 8 July 2020, . [I-D.ietf-netconf-tls-client-server] Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and TLS Servers", Work in Progress, Internet-Draft, draft- ietf-netconf-tls-client-server-21, 10 July 2020, . [I-D.ietf-netconf-trust-anchors] Watsen, K., "A YANG Data Model for a Truststore", Work in Progress, Internet-Draft, draft-ietf-netconf-trust- anchors-12, 10 July 2020, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [Std-802.1AR-2009] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", December 2009, . Watsen Expires 11 February 2021 [Page 41] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 Appendix A. Change Log This section is to be removed before publishing as an RFC. A.1. 00 to 01 * Replaced the 'certificate-chain' structures with PKCS#7 structures. (Issue #1) * Added 'private-key' as a configurable data node, and removed the 'generate-private-key' and 'load-private-key' actions. (Issue #2) * Moved 'user-auth-credentials' to the ietf-ssh-client module. (Issues #4 and #5) A.2. 01 to 02 * Added back 'generate-private-key' action. * Removed 'RESTRICTED' enum from the 'private-key' leaf type. * Fixed up a few description statements. A.3. 02 to 03 * Changed draft's title. * Added missing references. * Collapsed sections and levels. * Added RFC 8174 to Requirements Language Section. * Renamed 'trusted-certificates' to 'pinned-certificates'. * Changed 'public-key' from config false to config true. * Switched 'host-key' from OneAsymmetricKey to definition from RFC 4253. A.4. 03 to 04 * Added typedefs around leafrefs to common keystore paths * Now tree diagrams reference ietf-netmod-yang-tree-diagrams * Removed Design Considerations section Watsen Expires 11 February 2021 [Page 42] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 * Moved key and certificate definitions from data tree to groupings A.5. 04 to 05 * Removed trust anchors (now in their own draft) * Added back global keystore structure * Added groupings enabling keys to either be locally defined or a reference to the keystore. A.6. 05 to 06 * Added feature "local-keys-supported" * Added nacm:default-deny-all and nacm:default-deny-write * Renamed generate-asymmetric-key to generate-hidden-key * Added an install-hidden-key action * Moved actions inside fo the "asymmetric-key" container * Moved some groupings to draft-ietf-netconf-crypto-types A.7. 06 to 07 * Removed a "require-instance false" * Clarified some description statements * Improved the keystore-usage examples A.8. 07 to 08 * Added "local-definition" containers to avoid posibility of the action/notification statements being under a "case" statement. * Updated copyright date, boilerplate template, affiliation, folding algorithm, and reformatted the YANG module. A.9. 08 to 09 * Added a 'description' statement to the 'must' in the /keystore/ asymmetric-key node explaining that the descendent values may exist in only, and that implementation MUST assert that the values are either configured or that they exist in . Watsen Expires 11 February 2021 [Page 43] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 * Copied above 'must' statement (and description) into the local-or- keystore-asymmetric-key-grouping, local-or-keystore-asymmetric- key-with-certs-grouping, and local-or-keystore-end-entity-cert- with-key-grouping statements. A.10. 09 to 10 * Updated draft title to match new truststore draft title * Moved everything under a top-level 'grouping' to enable use in other contexts. * Renamed feature from 'local-keys-supported' to 'local-definitions- supported' (same name used in truststore) * Removed the either-all-or-none 'must' expressions for the key's 3-tuple values (since the values are now 'mandatory true' in crypto-types) * Example updated to reflect 'mandatory true' change in crypto-types draft A.11. 10 to 11 * Replaced typedef asymmetric-key-certificate-ref with grouping asymmetric-key-certificate-ref-grouping. * Added feature feature 'key-generation'. * Cloned groupings symmetric-key-grouping, asymmetric-key-pair- grouping, asymmetric-key-pair-with-cert-grouping, and asymmetric- key-pair-with-certs-grouping from crypto-keys, augmenting into each new case statements for values that have been encrypted by other keys in the keystore. Refactored keystore model to use these groupings. * Added new 'symmetric-keys' lists, as a sibling to the existing 'asymmetric-keys' list. * Added RPCs (not actions) 'generate-symmetric-key' and 'generate- asymmetric-key' to *return* a (potentially encrypted) key. A.12. 11 to 12 * Updated to reflect crypto-type's draft using enumerations over identities. Watsen Expires 11 February 2021 [Page 44] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 * Added examples for the 'generate-symmetric-key' and 'generate- asymmetric-key' RPCs. * Updated the Introduction section. A.13. 12 to 13 * Updated examples to incorporate new "key-format" identities. * Made the two "generate-*-key" RPCs be "action" statements instead. A.14. 13 to 14 * Updated YANG module and examples to incorporate the new iana-*-algorithm modules in the crypto-types draft.. A.15. 14 to 15 * Added new "Support for Built-in Keys" section. * Added 'must' expressions asserting that the 'key-format' leaf whenever an encrypted key is specified. * Added local-or-keystore-symmetric-key-grouping for PSK support. A.16. 15 to 16 * Moved the generate key actions to ietf-crypt-types as RPCs, which are augmented by ietf-keystore to support encrypted keys. Examples updated accordingly. * Added a SSH certificate-based key (RFC 6187) and a raw private key to the example instance document (partly so they could be referenced by examples in the SSH and TLS client/server drafts. A.17. 16 to 17 * Removed augments to the "generate-symmetric-key" and "generate- asymmetric-key" groupings. * Removed "generate-symmetric-key" and "generate-asymmetric-key" examples. * Removed the "algorithm" nodes from remaining examples. * Updated the "Support for Built-in Keys" section. * Added new section "Encrypting Keys in Configuration". Watsen Expires 11 February 2021 [Page 45] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 * Added a "Note to Reviewers" note to first page. A.18. 17 to 18 * Removed dangling/unnecessary ref to RFC 8342. * r/MUST/SHOULD/ wrt strength of keys being configured over transports. * Added an example for the "certificate-expiration" notification. * Clarified that OS MAY have a multiplicity of underlying keystores and/or HSMs. * Clarified expected behavior for "built-in" keys in * Clarified the "Migrating Configuration to Another Server" section. * Expanded "Data Model Overview section(s) [remove "wall" of tree diagrams]. * Updated the Security Considerations section. A.19. 18 to 19 * Updated examples to reflect new "cleartext-" prefix in the crypto- types draft. A.20. 19 to 20 * Addressed SecDir comments. * SUBMISSION PENDING!... Acknowledgements The authors would like to thank for following for lively discussions on list and in the halls (ordered by first name): Alan Luchuk, Andy Bierman, Benoit Claise, Bert Wijnen, Balazs Kovacs, David Lamparter, Eric Voit, Ladislav Lhotka, Liang Xia, Juergen Schoenwaelder, Mahesh Jethanandani, Magnus Nystroem, Martin Bjorklund, Mehmet Ersue, Phil Shafer, Radek Krejci, Ramkumar Dhanapal, Reshad Rahman, Sean Turner, and Tom Petch. Author's Address Watsen Expires 11 February 2021 [Page 46] =0C Internet-Draft A YANG Data Model for a Keystore August 2020 Kent Watsen Watsen Networks Email: kent+ietf@watsen.net Watsen Expires 11 February 2021 [Page 47] --Apple-Mail=_2BD894E7-8F93-499E-9519-B4271E11B9F2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii


        --Apple-Mail=_2BD894E7-8F93-499E-9519-B4271E11B9F2-- --Apple-Mail=_518AADA0-8A96-4313-A9A2-A4525C31C72F-- From nobody Mon Aug 10 23:28:17 2020 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 A17A13A0CCE; Mon, 10 Aug 2020 23:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 fmje-ZDS37QU; Mon, 10 Aug 2020 23:28:14 -0700 (PDT) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92373A0C1C; Mon, 10 Aug 2020 23:28:13 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id j7so11249325oij.9; Mon, 10 Aug 2020 23:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lbDSMs6OaNxdGYVIjvSSuhpk6Vch2BbEUX0sY4p+fmI=; b=ls1iZHPIahK8K3GGrUsp5EUgN0MuQqdQoMKJRuy+dv97K9GS5HB3Malv2ttvnJWmH8 xl8jq+wS9YO8x05DI9kEc4MfJW67boH2fGqyHmOrqS2+YbRwr1cWImjLbOL5c7kJWpJu M4wH8aIna6E5fvARPjjgQJu7DYoc35Yf7bFsI215kA+sOG9fPgV1hUEf1sxhVrVlrdRp 4UdgKGl7FuGUR+BCg7yNo7T7gXK6BRSx/dhy6sNy0N8Rm2nfs8y1MA6dg+RCWBNSQzxU 6WHOcW3fJN0LpAALJlJ5vafKAEOecdSM8WOV3RAb3BpDbRoKXP3wiWLBEjXkEjmgnLY4 VtVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lbDSMs6OaNxdGYVIjvSSuhpk6Vch2BbEUX0sY4p+fmI=; b=UKUIkRFqloEvuTIoyP/dV9eP/UNmOPsLzYxEqvLvpao0oDXVYZGhodPMwZ2DwA9n/F RVJPtxmGEe0+maFyLTC6o3/qWjXBXO9Wt11uSl7nx4X2fiqgcECt2yYZxEryClVYrY4U G358FCaOuSIav/bSBV+p+sJcIKHnc76OSm1FBCH+xkGsnwyk0DgBOioZ4HNe4lwZAUFY bHTM+Lmle7CFLLBwg9Jez7PbSWaPmV0S6/W+BXAh2Qj3dHeNr5/aSp7stCMLztYv/++V 4tzeZ7RvV2F5SPGweHMFd3+KU1cPK2BOLeXHy3kxrGA69jKzzxwP7UUOx/TMJQxfyxI4 u5nA== X-Gm-Message-State: AOAM530BinJZvBWIETzplmWiEYk27wIWxY9zhvKEfMJ8eny509SEXmnr GFgC+QTD8cNCWQiYi/gZCmABaQnUKgtGLoCA2eFTEQ== X-Google-Smtp-Source: ABdhPJz+m8oQG4+Zk0VZSZDcHVtEOZFrOWvi7TRKo9wiAx52TFWLJ1ARC/qT+nNEbWk5Rw2liaqlBLgcXilbysYA1Ng= X-Received: by 2002:aca:b8c4:: with SMTP id i187mr2388001oif.121.1597127293206; Mon, 10 Aug 2020 23:28:13 -0700 (PDT) MIME-Version: 1.0 References: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> In-Reply-To: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Mon, 10 Aug 2020 23:28:00 -0700 Message-ID: To: Kent Watsen Cc: secdir@ietf.org, draft-ietf-netconf-keystore@ietf.org, "netconf-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f903e205ac942c01" Archived-At: Subject: Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 06:28:16 -0000 --000000000000f903e205ac942c01 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kent, On the metadata, yes, I did catch that the actual values are protected. My suggestion (it is entirely up to the group of course) was just to consider if any of the data that will be readable may warrant a similar restriction as you have for the actual key values. On the root key etc., - OK, I understand now. I am also good with your other updates. Thanks! /M On Mon, Aug 10, 2020 at 6:26 PM Kent Watsen wrote: > [CC-ing netconf-chairs] > > > Hi Magnus, > > Thank you for the review. Below are some comments, as well as a link to > the GitHub commit, and an updated plain-text version of the draft. > > Thanks, > Kent > > > On Aug 10, 2020, at 1:29 AM, Magnus Nystr=C3=B6m wrot= e: > > 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 are= a > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. > > This document describes a new YANG model for centralized configuration of > cryptographic keys in the context of NETCONF and RESTCONF. > > > Section 4 describes a process to encrypt all "private" keys in a > configuration. It is unclear if this refers only to the asymmetric keys i= n > the configuration (as "private keys" normally refer to asymmetric keys) o= r > also symmetric keys. It appears to apply to all cryptographic keys, and i= t > therefore seems better to replace this usage of "private" with "symmetric > and asymmetric private keys." > > > Good catch. r/all the private keys/both the symmetric and asymmetric key= s/ > > > Likewise, the use of the term "root key" is a bit unclear. A "root key" > normally refers to an asymmetric key, but in this text it could be either= . > > More broadly, it may be advantageous to consider a hierarchy, where a key > encryption key is used to encrypt all keys in a configuration and this ke= y > encryption key in turn is protected by a root (or master) key. This way, > two instances only need to share the key encryption key and there's no ne= ed > for shared root keys (which may present an issue). Likewise, one can rota= te > or renew the key encryption key if desired, whereas this usually is harde= r > for root keys. > > > What you say is the intention, but the terminology used seems to be off. > The alignment needed is: > > Root key =E2=80=94> Master Encryption Key (MEK) > Shared root key =E2=80=94> Key Encryption Key (KEK) > > > > Section 5.2 first states: "The NACM "default-deny-all" extension has not > been set for any data nodes defined in this module," ostensibly because > "none of the readable data notes ... are considered sensitive." I note he= re > that meta-data about keys oftentimes can provide valuable information abo= ut > those keys and suggest considering if the default-deny-all extension shou= ld > be set by default after all. > > > I think there is a subtly you may be missing. The keystore module uses > the key definitions defined in the crypt-types draft. In that draft, the > key data *is* flagged with the =E2=80=9Cnacm:default-deny-all=E2=80=9D ex= tension. So the > key data itself (e.g., an ECPrivateKey or AESKey, in OpenSSL parlance) is > protected. Is that sufficient to protect the key metadata mentioned...or > are you concerned about the =E2=80=9Ckey-format=E2=80=9D and/or =E2=80=9C= public-key=E2=80=9D nodes being > readable? > > > > *Editorial:* > > ( A few nits that I found ) > > Section 1: > > - Substitute "Trusted Protection Module" with "Trusted Platform Module= " > - The term "HSM" is used without explanation > > Both fixed in my local copy - thanks! > > > - Last sentence (starting: "It is also possible...") is garbled > > > Now reads: > > "It is also possible that a > system implementing this module possesses a multiplicity of > operating system level keystore utilities and/or HSMs." > > Better? > > > > Section 1.1: > > - Sentence starting "Links the each" is garbled > > Section 3: > > - Second sentence starts "Built-in built-in keys..." > > > Both fixed in my local copy - thanks! > > > > > > The GitHub commit enacting the updates is here: > https://github.com/netconf-wg/keystore/commit/5b3b9f3db0d6b7027ddf5f0e983= ab958e8802251 > > The plain-text version of the updated draft is attached. > > Thanks again! > Kent > > > /M > > > > > > --=20 -- Magnus --000000000000f903e205ac942c01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        Hi Kent,
        On the metadata, = yes, I did catch that the actual values are protected. My suggestion (it is= entirely up to the group of course) was just to consider if any of the dat= a that will be readable may warrant a similar restriction as you have for t= he actual key values.

        On the root key etc., - OK, = I understand now. I am also good with your other updates.

        Thanks!
        /M


        On Mon, Aug 10, 2020= at 6:26 PM Kent Watsen <kent+= ietf@watsen.net> wrote:
        [CC-ing netco= nf-chairs]


        Hi Magnus,

        Thank you for the review.=C2=A0 Below are some comments, as well as a= link to the GitHub commit, and an updated plain-text version of the draft.=

        Thanks,
        Kent

        <= br>
        On Aug 10, 2020, at 1:29 AM, Magnus Nystr= =C3=B6m <magnusn@= gmail.com> wrote:

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

        This document describes a new YANG model for centralize= d configuration of cryptographic keys in the context of NETCONF and RESTCON= F.
          S= ection 4 describes a process to encrypt all "private" keys in a c= onfiguration. It is unclear if this refers only to the asymmetric keys in t= he configuration (as "private keys" normally refer to asymmetric = keys) or also symmetric keys. It appears to apply to all cryptographic keys= , and it therefore seems better to replace this usage of "private"= ; with "symmetric and asymmetric private keys."

          Good catch. =C2=A0r/all the pri= vate keys/both the symmetric=C2=A0and asymmetric keys/

          =

          Likewise, the use of the term &qu= ot;root key" is a bit unclear. A "root key" normally refers = to an asymmetric key, but in this text it could be either.

          More broadly, it may be advantageous to consider a hierarchy, wher= e a key encryption key is used to encrypt all keys in a configuration and t= his key encryption key in turn is protected by a root (or master) key. This= way, two instances only need to share the key encryption key and there'= ;s no need for shared root keys (which may present an issue). Likewise, one= can rotate or renew the key encryption key if desired, whereas this usuall= y is harder for root keys.

          What you say is the intention, but the terminology used s= eems to be off. =C2=A0 The alignment needed is:

          = =C2=A0 Root key =E2=80=94> Master Encryption Key (MEK)
          =C2=A0 = Shared root key =E2=80=94> Key Encryption Key (KEK)

          =


          Section 5.2 first state= s: "The NACM "default-deny-all" extension has not been set= for any data nodes defined in this module," ostensibly because &quo= t;none of the readable data notes ... are considered sensitive." I not= e here that meta-data about keys oftentimes can provide valuable informatio= n about those keys and suggest considering if the default-deny-all extensio= n should be set by default after all.

          I think there is a subtly you may be missing.=C2= =A0 The keystore module uses the key definitions defined in the crypt-types= draft.=C2=A0 In that draft, the key data *is* flagged with the =E2=80=9Cna= cm:default-deny-all=E2=80=9D extension.=C2=A0 So the key data itself (e.g.,= an ECPrivateKey or AESKey, in OpenSSL parlance) is protected.=C2=A0 Is tha= t sufficient to protect the key metadata mentioned...or are you concerned a= bout the =E2=80=9Ckey-format=E2=80=9D and/or =E2=80=9Cpublic-key=E2=80=9D n= odes being readable?


          Edito= rial:

          ( A few nits that I found )

          Section 1:
          • Substitute "Trusted= Protection Module" with "Trusted Platform Module"
          • T= he term "HSM" is used without explanation
          Both fixed in my local copy - thanks!

          • Last sentence (starting: "It is al= so possible...") is garbled

          Now reads:

          =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 "It is also possible that a=C2=A0
          =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0system implementing this module posses= ses a=C2=A0multiplicity of
          =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0opera= ting system level keystore utilities and/or=C2=A0HSMs."

          =
          Better?



          Section 1.1:
          • Sentence starting "Links the= each" is garbled
          Section 3:
          • Second se= ntence starts "Built-in built-in keys..."

          Both fixe= d in my local copy - thanks!



            The GitHub commit enacting the update= s is here:=C2=A0https://github.co= m/netconf-wg/keystore/commit/5b3b9f3db0d6b7027ddf5f0e983ab958e8802251

            The plain-text version of the updated draft is atta= ched.

            Thanks again!
            Kent

            <= /div>

            /M






            --
            -- Magnus
            --000000000000f903e205ac942c01-- From nobody Tue Aug 11 12:14:50 2020 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 A93B53A09B8; Tue, 11 Aug 2020 12:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.573, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, 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 qQHJO8e2k6XC; Tue, 11 Aug 2020 12:14:43 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 463463A08B9; Tue, 11 Aug 2020 12:14:43 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id z18so12494516wrm.12; Tue, 11 Aug 2020 12:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=FHCW0B6tNxV3sMDbqtqd1CpBIpQUPnBYH2zwF02eVO8=; b=ofnvDpdgnaGhZfJ7K89cLO5+xxu1ZiQuyX7+70vOmdAizmJg2OsX9jWCFCCS0z0HLW 5Q5Rk2+TK0Rev3WwAQGLlsk5BmXqqyJPeh0XZzZScOb3lWkCxLQjbBnO/oMh0h7hKsxP zLyNA4sRtLH5OYFEPBEXiwY920zF37WarDBQ+2ctfkc1/Ukv9yULQrAz1/WMV7BePO9+ Uyfj/l8833m+ySGO8KFanCzEDComR6y0TJU8wiFwoW2NTZofmXNQ1xMRj5Xn7nRtFVVy 7P0l3GI1oMmNsLl/kvUXa1Qi2nqFlcpwWf7gXmGRFhSUV3UPkjgoKWNcsVKy1fHQihHE x6jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=FHCW0B6tNxV3sMDbqtqd1CpBIpQUPnBYH2zwF02eVO8=; b=uUnceyi6vDMtc84Am7RnEhl/IlTrghm7efoMZtiyCPzZHpCazhlXOkyk5x4f6TlRnC QTymK7uBpSzd0Kxgso9lyubtvaVXj0o3aIfYHwKmgpqCD6xJcziDlrxm2SLB92HoK0bu nqZaFv5+4TbbjpuxOhN1YKaS4xAlA+5k1XxZV3V1ttR+cBtUclUrPCErb104SZ8YVYys 2iuwAM2+BmFxQlJ+1iSjR8Zdpxg/4a9jhCWOHNDOg5CkX3eZ4zOFF24cCoN2yL9wKjFa 3Y962I6VI5xAki3r7bw3/geiG30x2qcnrIjG19qALRb2Y481ctcgHj6WrKCIZIIwNlPm bCfg== X-Gm-Message-State: AOAM5339OAldFLeBygTmeILZq4pXM5tM+61Hs0gT86MdHfryUE4q9Fik t9t6ImBNq7lyUR7y8RLL+Oo= X-Google-Smtp-Source: ABdhPJxe/jFFV+V2LN0r9rcZN4+LDD/p8Oi9OEIOPZoHkIWZXoFZWATrbiVEJuEbK7+kYfaSKY/fpA== X-Received: by 2002:adf:fac8:: with SMTP id a8mr30810494wrs.368.1597173281626; Tue, 11 Aug 2020 12:14:41 -0700 (PDT) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id o125sm6998874wma.27.2020.08.11.12.14.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2020 12:14:41 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Tue, 11 Aug 2020 22:14:39 +0300 From: Yaron Sheffer To: Carsten Bormann CC: Laurence Lundblade , , , , Message-ID: Thread-Topic: [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> <6A1090D8-D012-4A04-BC4A-9CF23E791DA2@tzi.org> In-Reply-To: <6A1090D8-D012-4A04-BC4A-9CF23E791DA2@tzi.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 19:14:45 -0000 >=20 > I understand that, but realistically, without a list of (potential) v= alidity checks in the RFC, there will be wide variance in what is documented= by decoders =E2=80=93 if any. In fact I checked a few implementations just now, a= nd most of them do not document what validity checks they perform. Those tha= t document something are hard to compare. If you make a canonical list, peop= le would have a starting point. To be fair, you probably checked RFC 7049 implementations, and RFC 7049= didn=E2=80=99t have such a requirement (improving the discussion of validity was = one of the major work items in 7049bis, see Appendix G.3). One point to keep in mind is that, with CBOR, most validity processing = happens in the processing of tags, and that is an extension point. So a lis= t in 7049bis will never be complete. Even if it only covers base CBOR and t= he tags registered in 7049/7049bis, a detailed version is likely to be tedio= us and highly dependent of specific implementation approaches. Trying to imagine the outcome of this exercise, my visual image right n= ow is a PICS Proforma, so I think I=E2=80=99ll better stop here... Gr=C3=BC=C3=9Fe, Carsten Hi Carsten, You are addressing this issue from the point of view of a spec writer, I su= ggest you take the POV of the implementer, the user of a decoder. Those peop= le are not CBOR experts, and when faced with free-form and probably terse do= cumentation of a decoder's validity checking would never know what they need= to consider to add as application-level checking. I realize that tags are an extension point, but if we are to avoid decoding= -related vulnerabilities, I suggest you list validity checks for the base CB= OR and tags in RFC7049+bis. Thanks, Yaron From nobody Tue Aug 11 16:24:32 2020 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 8D8173A0DC9; Tue, 11 Aug 2020 16:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvmCShEXtLIO; Tue, 11 Aug 2020 16:24:20 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6FA3A0DBE; Tue, 11 Aug 2020 16:24:19 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BR86R6B8Sz17r5; Wed, 12 Aug 2020 01:23:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 12 Aug 2020 01:24:01 +0200 Cc: cbor@ietf.org, secdir@ietf.org, Last Call , Laurence Lundblade , draft-ietf-cbor-7049bis.all@ietf.org X-Mao-Original-Outgoing-Id: 618881041.389055-e7d65e16d11098fbbf08f2f18de616d3 Content-Transfer-Encoding: quoted-printable Message-Id: References: <159705005508.2366.4819563096010229406@ietfa.amsl.com> <6A1090D8-D012-4A04-BC4A-9CF23E791DA2@tzi.org> To: Yaron Sheffer X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 23:24:24 -0000 On 2020-08-11, at 21:14, Yaron Sheffer wrote: >=20 >>=20 >> I understand that, but realistically, without a list of (potential) = validity checks in the RFC, there will be wide variance in what is = documented by decoders =E2=80=93 if any. In fact I checked a few = implementations just now, and most of them do not document what validity = checks they perform. Those that document something are hard to compare. = If you make a canonical list, people would have a starting point. >=20 > To be fair, you probably checked RFC 7049 implementations, and RFC = 7049 didn=E2=80=99t have such a requirement (improving the discussion of = validity was one of the major work items in 7049bis, see Appendix G.3). >=20 > One point to keep in mind is that, with CBOR, most validity = processing happens in the processing of tags, and that is an extension = point. So a list in 7049bis will never be complete. Even if it only = covers base CBOR and the tags registered in 7049/7049bis, a detailed = version is likely to be tedious and highly dependent of specific = implementation approaches. >=20 > Trying to imagine the outcome of this exercise, my visual image = right now is a PICS Proforma, so I think I=E2=80=99ll better stop = here... >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > Hi Carsten, >=20 > You are addressing this issue from the point of view of a spec writer, = I suggest you take the POV of the implementer, I took the view of the implementer of a generic decoder (which I happen = to also be IRL), faced with a PICS Proforma. Just in case that term doesn=E2=80=99t already send you running for the = hills, there are some standards that come with a [not so] little word = document that you are supposed to fill in to describe what your = implementation of that standard really does. > the user of a decoder. Those people are not CBOR experts, and when = faced with free-form and probably terse documentation of a decoder's = validity checking would never know what they need to consider to add as = application-level checking. I certainly can agree with that. Still, I would like to learn about = other places where IETF has done something like that, so we can learn = from those efforts. > I realize that tags are an extension point, but if we are to avoid = decoding-related vulnerabilities, I suggest you list validity checks for = the base CBOR and tags in RFC7049+bis. Would that also be a good thing for a separate document, possibly = including more tags? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Aug 12 06:10:54 2020 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 482BF3A128C; Wed, 12 Aug 2020 06:10:53 -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, SPF_HELO_NONE=0.001, 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 STCTiq6hMrGq; Wed, 12 Aug 2020 06:10:50 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294343A0CCB; Wed, 12 Aug 2020 06:10:46 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 1DF1E28B004A; Wed, 12 Aug 2020 09:10:46 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id DA9BD1F8051; Wed, 12 Aug 2020 09:10:45 -0400 (EDT) From: Sandra Murphy Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 12 Aug 2020 09:10:44 -0400 To: secdir@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-keystore.authors@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [secdir] early secdir review of draft-ietf-netconf-keystore-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 13:10:53 -0000 This is a requested SECDIR early review of = draft-ietf-netconf-keystore-19, not an IETF Last Call review. I have reviewed this document as an early review assigned by the = security directorate, as part of the directorate's ongoing effort to = review documents headed eventually to the IESG. Document editors and WG = chairs should treat these comments just like any other comments. I am a neophyte at Yang so any comments I make here should be understood = with that in mind. (The recent mpls and netconf discussion of the MPLS = module reuse of an RPC and the difference between "destination address" = and "local label" have further impressed upon me just how much I do not = know about YANG.) Outline of this review is: News of draft status Summary of the draft General and issue comments Page-by-page comments and nits News of draft status: --------------------- This document was in WGLC when assigned and it appears that the WGLC has = not yet been decided. In the netconf session at IETF108, the wg discussed the need for a raw = password feature, which might end up as a new grouping being added to = the draft-ietf-netconf-crypto-types and therefore might induce changes = to this draft as well. Summary of the draft: --------------------- The draft abstract says: This document defines a YANG 1.1 module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. Keys may be symmetric or asymmetric, and maybe be of types "cleartext", = "hidden" (as in a TPM), or "encrypted". Keys can be configured locally = (which means within the data model) or as a reference to a keystore = item. One server might have multiple keystores in use at any one time. The document defines groupings that might prove useful for other YANG = modules that import this one. The document describes the data model for the keystore and provides many = examples. The descriptions of the data model and examples are presented = in different modes as you read through the document, in tree diagrams, = XML, and text that (surely?) is YANG (I think). I believe the YANG text = is authoritative. For other readers, here's the sequence of description modes. Section 2.1 Mostly tree diagram descriptions of the groupings defined in = this document. Section 2.2.1-2.2.2 Examples (Keystore Instance and Cert Expiration) = given in XML. Section 2.2.3 A module, containing those groupings of Section 2.1 whose = titles' prefixes are "local-or-keystore-", is described in what I = believe would be called YANG (p16-18) and then in a tree diagram = (p19-23). Section 2.3 This section describes what I believe to be the normative = Yang module text. General and issue comments: --------------------------- This document is very well written. The examples were very helpful, = particularly to this reader who was unfamiliar with Yang. I can't = imagine the patience and care it took to keep so many descriptions in = close alignment. The document describes two new typedefs: asymmetric-key-ref and = symmetric-key-ref. Those typedefs are never further explained. I = believe (based only on the string "ref" in the name and usage as = "keystore-reference") that these are intended to be references to named = items in other parts of the keystore which themselves contain keys. = (Sheesh it takes a lot of words!) And I hope/believe that the = asymmetric-key-ref is to a structure that contains a key-pair. The text typically says "asymmetric key" without distinguishing whether = it is talking about the public key, the private key, or a key-pair. = Presumably "asymmetric key" means a key-pair and the implementations of = operations know from context which key in the key-pair is needed. I am not familiar with the Yang system, so I wonder if there is any = mechanism in Yang's use to check if the assumptions of the data model = are followed. If an asymmetric key is configured with a public key and = a private key that are not a key-pair, where is that caught? If an = asymmetric key and an associated cert are configured, but the public key = part of the structure is not the public key mentioned in the cert, where = is that caught? If the data model says that a component is an = asymmetric-key-ref, but the de-ref'd value is not an asymmetric key (key = type?), where is that caught, like maybe when the value is stored in the = keystore? (Do the questions even make sense?) Section 3 says Built-in "encrypted" keys MAY be copied into other parts of the configuration so long as they maintain their reference to the other built-in key that encrypted them. I could see that built-in keys should be encrypted by other built-in = keys (I don't see what other keys are available at the building-in time = to encrypt them, but proof by "I don't see" is unconvincing). Is that = required? I don't think the data model represents built-in keys as a = distinct type, so I'm not sure the data model could represent the = built-in-ness requirement. Could it ever be that a built-in key could = be encrypted by a non-built-in key? I.e., does something prevent it. Section 4 p34 says "built-in keys MUST be hidden". That really should = be mentioned in Section 3. Section 3 and 4 about built-in keys and root keys and hidden keys: Section 4 p34 says The root key SHOULD be a hidden key, i.e., one whose private data has no presence in or and Given the long lifetime of built-in keys (see Section 3), built-in keys MUST be hidden. and Section 3 p32 says The key characteristic of the built-in keys is that they are provided by the system, as opposed to configuration. As such, they are present in . So built-in keys must be hidden, which means they are candidates to be = root keys, but they are "present in operational". By the first = sentence, their private data is not in , so the = configuration must use the hidden-private-key or hidden-key key-type for = the secret parts. By the requirement that built-in keys must be hidden, servers that do = not support hidden keys can not use built-in keys. Correct? A hidden root key MAY be either a symmetric key or an asymmetric key. Does the same apply to built-in keys? The examples in Section 3 are all = asymmetric keys. Is using a built-in key as a root key advisable in operational = situations? Presumably if a root key is not a built-in key and not a hidden key, = then its secret data must be of cleartext-key type. Encrypting the root = key is not possible, there is no other single key available (or it would = be the root key). Has any consideration been given to dual root keys? = I could see that that would be too complex to manage. Section 4.1 p35 The use of the root key mentions encrypting with an asymmetric key, but = not signing with an asymmetric key. Are signing and other crypto = services not a part of the netconf view? Section 4.2 p35 Each time a new key is to be configured, it SHOULD be encrypted by the root key. Would it be good to discuss how to configure a root key? If the root = key is not a built-in key and there is no support for a hidden key, then = a cleartext key would be required, correct? An encrypted key would not = be possible because it would require a second key that would have to be = available in the keystore - which means that would be the root key. Section 4.3 p35 This process for migrating a configuration to a new server would also = work for replacing the root key on a server without requiring = re-encrypting all the keystore's encrypted keys. (Mind you, I don't = know how a non-builtin, non-hidden root key is configured from a cold = start.) The text calls the key a "shared root key" - but the use in this process = of migrating a configuration does not require that the key be shared = other than between the "first" and "second" servers. I don't see that = there's any reason to share the "shared root key" more widely; each = migration between two servers could use a different "shared root key". "This shared root key would only need to be known to an organization's = crypto officer." -- until it is decrypted in a server for use in = encrypting and decrypting local keys, right? I don't know how YANG = implementations hold the root keys that are constantly in use but = hopefully access is carefully controlled. A key common to all servers in an operational environment has been found = to be unwise because an exposure at one server has a global impact. The = text on p 36 says "The crypto officer can then safely handoff the = encrypted shared key to other administrators responsible for server = installations, including migrations." but that should be taken as a = handoff as necessary at each occasion, not taken as a handoff to all = other servers jointly, at the same time. Section 5.2 p38 This section points to the NETCONF protocol's support for mutual = authentication, but in this particular case, I believe that the = mandatory support for confidentiality is very important and should be = mentioned, in particular for the configuration of cleartext keys. I had one puzzle I could never figure out - why the keystore-reference = for the grouping local-or-keystore-asymmetric-key-with-certs-grouping = (Sect 2.1.3.5) is an asymmetric-key-ref type. Other uses of = asymmetric-key-ref are consistent with it being a reference to a key = only, but here I expected the reference would be to a structure that = contains the key and its associated certs. The descriptions in the Sect = 2.3 Yang Module p29 says the grouping contains the cert and its keys. Is the asymmetric-key-ref in some way useable as both a reference to an = asymmetric key and an asymmetric key and its associated certs? At first I thought the "associated certs" in the groupings were the = certificate chain certs - the subject cert, the issuer cert, etc. I am = not sure they are - might they be many certificates for the same public = key, perhaps for different algorithms? I think that should be = explained. Page-by-page comments and nits: ------------------------------- Section 1 p 3 there are groupings that defined enabling a key to be either Did you mean the past tense here? Or did you mean "define"? Section 1.1 p 4 In the diagram, what is the meaning of the lines - what relationshiop do = they represent - e.g., "refers to", "uses", "augments", something else? It looks like netconf-client-server has no relationship (whatever = "relationship" is) to http-client-server, restconf-client-sever has no = relationship to ssh-client-server, and http-client-server has no = relationship to keystore or truststore. Is that all correct? Section 1.3 p 5 This document in compliant with Network Management Datastore Architecture (NMDA) [RFC8342]. RFC8342 is listed in the informative section - what does it mean to be = compliant with an informative reference? [Std-802.1AR-2009] certificate) are expected to appear in I did not catch that the term was part of R%FC8342, and = went looking for a reference. I found it in many places, like RFC6241. = For those just that unobservant, could you put a citation here to = RFC8342, which I think is the proper reference for that term. Note: = appears later, and a citation to RFC8342 is probably proper = there as well. Yes, I know, probably about as necessary as a reference = to "packet", but it would have spared me, maybe other non-Yang clueful = folk will be reading this also. Section 2 p 5 This section defines a YANG 1.1 [RFC7950] module that defines a "keystore" Should that be "ietf-keystore"? Or do you mean keystore in a general = sense, in which case I think the quote marks make it look like a name, = not a general sense. (I went looking for a definition of a "keystore", = but that could just be me.) Section 2.1.1. p6 The following diagram lists all the "feature" statements defined in Everywhere beyond this page it says "tree diagram". RFC8340 is cited in = Section 2.1.3.1, but this is the first use (unless I'm wrong about the = "tree diagram"), so the citation should go here. The following diagram lists the "typedef" statements defined in the The following diagram lists all the "grouping" statements defined in diagram -> "tree diagram" Section 2.1.3.3 - 2.1.3.6: " offer an option as to if an asymmetric key is defined" - personally, I = would say "as to whether". I don't know if the RFC-Editor (and rfc = style guide) care. "augmented in if, e.g.," - I actually thought this was an editing error, = until heard "augment in" used as a word in the IETF session. Web search = shows "augment in" is a term of art in netconf! But some uses add a = hyphen, which I think is a good idea. reference a asymmetric key in an alternate location. a asymmetric -> an asymmetric. A global change might be good, as well = as changing "an symmetric" to "a symmetric". Section 2.1.3.4 * For the "local-definition" option, the defintion uses the "asymmetric-key-pair-grouping" grouping discussed in Section 2.1.3.4 of [I-D.ietf-netconf-crypto-types]. It looks to me like it is actually Section 2.1.4.4 of = [I-D.ietf-netconf-crypto-types]. Section 2.1.3.7 p 11 * The "keystore-grouping" grouping is defines a keystore instance as "is defines" -> "defines" * For asymmetric keys, each "asymmetric-key" uses the "asymmetric- key-pair-with-certs-grouping" grouping discussed Section 2.1.3.10 of [I-D.ietf-netconf-crypto-types]. "discussed" -> "discussed in" Why do none of the asymmetric keys here use a grouping that is the key = only, like the ct:asymmetric-key-pair-grouping used in Sectoin 2.1.3.4 = of this document (discussed in 2.1.4.4 of = [I-D.ietf-netconf-crypto-types]). | | +--rw encrypted-private-key | | +--rw encrypted-by | | | +--rw (encrypted-by-choice) | | | +--:(symmetric-key-ref) | | | | +--rw symmetric-key-ref? leafref | | | +--:(asymmetric-key-ref) | | | +--rw asymmetric-key-ref? leafref Section 2.2.1 p 13 The following example illustrates keys in . Like I said before, maybe a citation of RFC8340 here. Section 2.2.3 p 17 has the phrase "following non-normative ". Does that = belong here? Or because this is XML, it can not be confused to be a = normantive Yang module? hidden-asymmetric-key The "hidden-asymmetric-key" key appears later in the asymmetric-keys = part of the keystore example on p15. I don't know how to prevent that = forward sort of reference for the readers, or if it is a problem. Section 2.2.3 p 18 list end-entity-cert-with-key { key name; ... uses ks:local-or-keystore-end-entity-cert-with-key-grouping; description "An end-entity certificate, and its associated private key, that may be configured locally or be a reference to a specific certificate (and its associated private key) in the keystore."; You can't rely on descriptions, but I see no explicit reference to the = private key in that end-entity cert grouping. That grouping is defined = in Section 2.1.3.6 p 9, and the keystore-reference is an = asymmetric-key-certificate-ref-grouping. That grouping has an = asymmetric-key-ref and a cert. The description above says "and its = associated private key". So is the asymmetric-key-ref a ref to the = private key or to a key pair? Section 2.3 p 25 typedef symmetric-key-ref { type leafref { path "/ks:keystore/ks:symmetric-keys/ks:symmetric-key" + "/ks:name"; } Does default-deny-write belong here, or added each time an item is = defined of this type? Section 2.3 p 26 case asymmetric-key-ref { leaf asymmetric-key-ref { type leafref { path "/ks:keystore/ks:asymmetric-keys/" + "ks:asymmetric-key/ks:name"; } description "Identifies the asymmetric key used to encrypt this key."; } (a) "the asymmetric key used to encrypt" - the public key part is used = to encrypt, so is the asymmetric key just the public key or a key-pair = where the appropriate part of the key-pair is used according to context? (b) "encrypt this key" - The "this key" part is appropriate if the = assymmetric-key-ref is being used in an encrypted-by-choice structure, = but there are lots of places in this text where the type is not in such = a structure. Is it the case that the uses always resolve to be = encrypting a key? (c) "encrypt" - Is it always the case that asymmetric keys in the = keystore will be used to encrypt something? There is no expectation = that the asymmetric key-pair will be used to sign something? Section 2.3 p27 description "A grouping that expands to allow the symmetric key to be either stored locally, within the using data model, or be a reference to a symmetric key stored in the Keystore."; The following is wordsmithing the description text, so a very-nitty-nit. ", or be" -> ", or" (the "be" is before the "either", don't need it) A reader might be confused as to whether the disjunction was two = disjuncts or three. I might suggest using "i.e., within the using data store". Maybe also move the "be" inside the "either or" for scoping "A grouping that expands to allow the symmetric key to either be stored locally, i.e., within the using data model, or be a reference to a symmetric key stored in the Keystore."; The groupings in this section have a descriptoin of the grouping, a = description of the key case and a description of the choice. I thought = it worked better to place the description of the choice closer to the = "choice local or keystore" rather than at the end. And finally. Descriptions very frequently (always?) conclude with a "." = but they are very frequently not sentences, so the "." is not necessary. = I do not know if the RFC-Editor or the Style manual cares. Section 2.3 p 28 grouping local-or-keystore-asymmetric-key-with-certs-grouping ... case keystore { if-feature "keystore-supported"; leaf keystore-reference { type ks:asymmetric-key-ref; description "A reference to an asymmetric-key (and all of its associated certificates) in the Keystore."; An example of my puzzle about the = local-or-keystore-asymmetric-key-with-certs-grouping keystore-reference. = How are the certs to be found if the keystore-reference is to the = asymmetric key only? Or must the asymmetric-key-ref sometimes point = just to a key and sometimes to a key+certs, as needed? Section 3 p 31 In some implementations, a server may support built-in keys. Built- in built-in keys "Built-in built-in" =3D> "Built-in" Section 3 p 32 In order for the built-in keys (and/or their associated built-in certificates) to be referenced by configuration, the referenced keys MUST first be copied into . ... Built-in "hidden" keys cannot be copied into other parts of the configuration because their private parts are hidden, and therefore impossible to replicate. Section 4 p34 says built-in keys MUST be hidden. So they must be copied = to but they can't be copied? Huh? The keys SHOULD be copied into using the same "key" values, so that the server can bind the references to the built-in entries. The word "key" is overloaded in this document, like "The key = characteristic of the built-in keys" and "Key Words". Here, the = reference is surely to a required part of the "list" syntax, so no way = to use a different word. Maybe say 'the same list "key" values' or 'the = same values for the list "key" field/node'. Built-in "encrypted" keys MAY be copied into other parts of the configuration so long as they maintain their reference to the other built-in key that encrypted them. (a) Section 4 p34 says "built-in keys MUST be hidden", so is there a way = the hidden built-in keys can be encrypted keys? (b) So encrypted built-in keys must always be encrypted by other = built-in keys? Is there a way to represent that in the data model? (I = explored this before.) MAY be a subset of the built-in keys define in set) of the built-in keys define in "define" -> "defined" Only the referenced keys need to be copied; that is, the keys in MAY be a subset of the built-in keys define in . No keys may be added or changed (with exception to associating additional certificates to a built-in key); that is, the keys in MUST be a subset (which includes the whole of the set) of the built-in keys define in . I don't understatnd this part. First it says "keys in MAY be a subset of the built-in keys define in = " and then "keys in MUST be a subset ... of the built-in keys define in = ". That is inconsistent, is it intended? Does the last sentence mean that if there are built-in keys, no other = keys may be added to the keystore? I don't know what is intended here. About "exception to" - I use "exeption to " and "exception for ". I don't know if the RFC-Editor or the Style manual = cares. Section 4.1 p34 not support hidden keys, then the private data part of key MUST be=20 "of key" -> "of the root key" Section 4.1 p35 If the hidden root key is asymmetric, then the server SHOULD provide APIs enabling other keys to be both generated and encrypted by it The "both generated and encrypted by it" sounds like keys are being = generated by the root key. I don't think that's generally true. = Section 4.2 separates key generation and key encryption steps. I think = this should be clearer. (The mention of other crypto services moved to area before nits.) Section 4.2 p35 (A discussion of issues, not nits, was moved to area before nits.) Section 4.3 p35 (A discussion of issues, not nits, was moved to area before nits.) =20 Section 5.2 p38 (A discussion of issues, not nits, was moved to area before nits.) | Please be aware that this module uses the "key" and "private- | key" nodes from the "ietf-crypto-types" module | [I-D.ietf-netconf-crypto-types], where said nodes have the NACM | extension "default-deny-all" set, thus preventing unrestricted | read-access to the cleartext key values. This text missed the change A.19 to add a "cleartext" prefix as in = ietf-netconf-crypto-types. The "cleartext" prefix is present in the = modules, tree-diagrams, XML, etc., but the references in text here did = not change. (Actually, I see several examples in the text in = ietf-netconf-crypto-types where the change was not made, e.g. p 9 says = '- The "key" node can encode any plain-text key value.' where the = preceding tree diagram has a node named "cleartext-key" and older = versions said "key".) I appreciate the discussion of the = default-deny-all in Section 3.5 p42 of ietf-netconf-crypto-types and I = think that a citation here would be warranted and useful. BTW. I don't know the NACM well but could it be said that the = default-deny-all prevents uncontrolled access, but does not necessarily = prevent unrestricted access, because a present but careless access = control might not actually restrict access? Section 6.2 p 39 "the the" -> "the" Section 7.2 p40 The list of Informative References includes: [I-D.ietf-netconf-keystore] Watsen, K., "A YANG Data Model for a Keystore", Work in Progress, Internet-Draft, draft-ietf-netconf-keystore-17, 20 May 2020, . Isn't this a self reference to an earlier version? Note: ID nits gives 11 warnings, but all are due to references to older = versions of existing drafts or to future versions not yet published. = The latter case seems to be wrong, and the warning usually notes (However, the state information for draft-ietf-netconf-keystore is = not up-to-date. The last update was unsuccessful) I have no idea what that means. The warnings are consistent, so may be = something to watch. =E2=80=94Sandy From nobody Wed Aug 12 06:28:26 2020 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 203603A102E; Wed, 12 Aug 2020 06:28:25 -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, SPF_HELO_NONE=0.001, 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 GB-1XpSj8AUE; Wed, 12 Aug 2020 06:28:22 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1993A106C; Wed, 12 Aug 2020 06:28:21 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 38B6328B003D; Wed, 12 Aug 2020 09:28:21 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id F37D01F8051; Wed, 12 Aug 2020 09:28:20 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sandra Murphy In-Reply-To: Date: Wed, 12 Aug 2020 09:28:19 -0400 Cc: secdir@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-keystore.authors@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <18A977F3-E1D5-4016-B54A-5BEFD9453E31@tislabs.com> References: To: Sandra Murphy X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] early secdir review of draft-ietf-netconf-keystore-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 13:28:25 -0000 And I missed the fact that Magnus did a review as well. =E2=80=94Sandy > On Aug 12, 2020, at 9:10 AM, Sandra Murphy wrote: >=20 > This is a requested SECDIR early review of = draft-ietf-netconf-keystore-19, not an IETF Last Call review. >=20 > I have reviewed this document as an early review assigned by the = security directorate, as part of the directorate's ongoing effort to = review documents headed eventually to the IESG. Document editors and WG = chairs should treat these comments just like any other comments. >=20 > I am a neophyte at Yang so any comments I make here should be = understood with that in mind. (The recent mpls and netconf discussion = of the MPLS module reuse of an RPC and the difference between = "destination address" and "local label" have further impressed upon me = just how much I do not know about YANG.) >=20 > Outline of this review is: >=20 > News of draft status > Summary of the draft > General and issue comments > Page-by-page comments and nits >=20 >=20 > News of draft status: > --------------------- >=20 > This document was in WGLC when assigned and it appears that the WGLC = has not yet been decided. >=20 > In the netconf session at IETF108, the wg discussed the need for a raw = password feature, which might end up as a new grouping being added to = the draft-ietf-netconf-crypto-types and therefore might induce changes = to this draft as well. >=20 > Summary of the draft: > --------------------- >=20 > The draft abstract says: > This document defines a YANG 1.1 module called "ietf-keystore" that > enables centralized configuration of both symmetric and asymmetric > keys. >=20 > Keys may be symmetric or asymmetric, and maybe be of types = "cleartext", "hidden" (as in a TPM), or "encrypted". Keys can be = configured locally (which means within the data model) or as a reference = to a keystore item. One server might have multiple keystores in use at = any one time. >=20 > The document defines groupings that might prove useful for other YANG = modules that import this one. >=20 > The document describes the data model for the keystore and provides = many examples. The descriptions of the data model and examples are = presented in different modes as you read through the document, in tree = diagrams, XML, and text that (surely?) is YANG (I think). I believe the = YANG text is authoritative. >=20 > For other readers, here's the sequence of description modes. >=20 > Section 2.1 Mostly tree diagram descriptions of the groupings defined = in this document. >=20 > Section 2.2.1-2.2.2 Examples (Keystore Instance and Cert Expiration) = given in XML. >=20 > Section 2.2.3 A module, containing those groupings of Section 2.1 = whose titles' prefixes are "local-or-keystore-", is described in what I = believe would be called YANG (p16-18) and then in a tree diagram = (p19-23). >=20 > Section 2.3 This section describes what I believe to be the normative = Yang module text. >=20 > General and issue comments: > --------------------------- >=20 > This document is very well written. The examples were very helpful, = particularly to this reader who was unfamiliar with Yang. I can't = imagine the patience and care it took to keep so many descriptions in = close alignment. >=20 > The document describes two new typedefs: asymmetric-key-ref and = symmetric-key-ref. Those typedefs are never further explained. I = believe (based only on the string "ref" in the name and usage as = "keystore-reference") that these are intended to be references to named = items in other parts of the keystore which themselves contain keys. = (Sheesh it takes a lot of words!) And I hope/believe that the = asymmetric-key-ref is to a structure that contains a key-pair. >=20 > The text typically says "asymmetric key" without distinguishing = whether it is talking about the public key, the private key, or a = key-pair. Presumably "asymmetric key" means a key-pair and the = implementations of operations know from context which key in the = key-pair is needed. >=20 > I am not familiar with the Yang system, so I wonder if there is any = mechanism in Yang's use to check if the assumptions of the data model = are followed. If an asymmetric key is configured with a public key and = a private key that are not a key-pair, where is that caught? If an = asymmetric key and an associated cert are configured, but the public key = part of the structure is not the public key mentioned in the cert, where = is that caught? If the data model says that a component is an = asymmetric-key-ref, but the de-ref'd value is not an asymmetric key (key = type?), where is that caught, like maybe when the value is stored in the = keystore? (Do the questions even make sense?) >=20 > Section 3 says > Built-in "encrypted" keys MAY be copied > into other parts of the configuration so long as they maintain their > reference to the other built-in key that encrypted them. >=20 > I could see that built-in keys should be encrypted by other built-in = keys (I don't see what other keys are available at the building-in time = to encrypt them, but proof by "I don't see" is unconvincing). Is that = required? I don't think the data model represents built-in keys as a = distinct type, so I'm not sure the data model could represent the = built-in-ness requirement. Could it ever be that a built-in key could = be encrypted by a non-built-in key? I.e., does something prevent it. >=20 > Section 4 p34 says "built-in keys MUST be hidden". That really should = be mentioned in Section 3. >=20 > Section 3 and 4 about built-in keys and root keys and hidden keys: >=20 > Section 4 p34 says >=20 > The root key SHOULD be a hidden key, i.e., one whose private data has > no presence in or >=20 > and > Given the long lifetime of built-in > keys (see Section 3), built-in keys MUST be hidden. >=20 > and Section 3 p32 says >=20 > The key characteristic of the built-in keys is that they are provided > by the system, as opposed to configuration. As such, they are > present in . >=20 > So built-in keys must be hidden, which means they are candidates to be = root keys, but they are "present in operational". By the first = sentence, their private data is not in , so the = configuration must use the hidden-private-key or hidden-key key-type for = the secret parts. >=20 > By the requirement that built-in keys must be hidden, servers that do = not support hidden keys can not use built-in keys. Correct? >=20 > A hidden root key MAY be either a symmetric key or an asymmetric key. >=20 > Does the same apply to built-in keys? The examples in Section 3 are = all asymmetric keys. >=20 > Is using a built-in key as a root key advisable in operational = situations? >=20 > Presumably if a root key is not a built-in key and not a hidden key, = then its secret data must be of cleartext-key type. Encrypting the root = key is not possible, there is no other single key available (or it would = be the root key). Has any consideration been given to dual root keys? = I could see that that would be too complex to manage. >=20 > Section 4.1 p35 >=20 > The use of the root key mentions encrypting with an asymmetric key, = but not signing with an asymmetric key. Are signing and other crypto = services not a part of the netconf view? >=20 > Section 4.2 p35 >=20 > Each time a new key is to be configured, it SHOULD be encrypted by > the root key. >=20 > Would it be good to discuss how to configure a root key? If the root = key is not a built-in key and there is no support for a hidden key, then = a cleartext key would be required, correct? An encrypted key would not = be possible because it would require a second key that would have to be = available in the keystore - which means that would be the root key. >=20 > Section 4.3 p35 >=20 > This process for migrating a configuration to a new server would also = work for replacing the root key on a server without requiring = re-encrypting all the keystore's encrypted keys. (Mind you, I don't = know how a non-builtin, non-hidden root key is configured from a cold = start.) >=20 > The text calls the key a "shared root key" - but the use in this = process of migrating a configuration does not require that the key be = shared other than between the "first" and "second" servers. I don't see = that there's any reason to share the "shared root key" more widely; each = migration between two servers could use a different "shared root key". >=20 > "This shared root key would only need to be known to an organization's = crypto officer." -- until it is decrypted in a server for use in = encrypting and decrypting local keys, right? I don't know how YANG = implementations hold the root keys that are constantly in use but = hopefully access is carefully controlled. >=20 > A key common to all servers in an operational environment has been = found to be unwise because an exposure at one server has a global = impact. The text on p 36 says "The crypto officer can then safely = handoff the encrypted shared key to other administrators responsible for = server installations, including migrations." but that should be taken as = a handoff as necessary at each occasion, not taken as a handoff to all = other servers jointly, at the same time. >=20 > Section 5.2 p38 >=20 > This section points to the NETCONF protocol's support for mutual = authentication, but in this particular case, I believe that the = mandatory support for confidentiality is very important and should be = mentioned, in particular for the configuration of cleartext keys. >=20 >=20 >=20 > I had one puzzle I could never figure out - why the keystore-reference = for the grouping local-or-keystore-asymmetric-key-with-certs-grouping = (Sect 2.1.3.5) is an asymmetric-key-ref type. Other uses of = asymmetric-key-ref are consistent with it being a reference to a key = only, but here I expected the reference would be to a structure that = contains the key and its associated certs. The descriptions in the Sect = 2.3 Yang Module p29 says the grouping contains the cert and its keys. >=20 > Is the asymmetric-key-ref in some way useable as both a reference to = an asymmetric key and an asymmetric key and its associated certs? >=20 > At first I thought the "associated certs" in the groupings were the = certificate chain certs - the subject cert, the issuer cert, etc. I am = not sure they are - might they be many certificates for the same public = key, perhaps for different algorithms? I think that should be = explained. >=20 >=20 >=20 > Page-by-page comments and nits: > ------------------------------- >=20 > Section 1 p 3 >=20 > there are groupings that defined enabling a key to be either >=20 > Did you mean the past tense here? Or did you mean "define"? >=20 > Section 1.1 p 4 >=20 > In the diagram, what is the meaning of the lines - what relationshiop = do they represent - e.g., "refers to", "uses", "augments", something = else? >=20 > It looks like netconf-client-server has no relationship (whatever = "relationship" is) to http-client-server, restconf-client-sever has no = relationship to ssh-client-server, and http-client-server has no = relationship to keystore or truststore. Is that all correct? >=20 > Section 1.3 p 5 >=20 > This document in compliant with Network Management Datastore > Architecture (NMDA) [RFC8342]. >=20 > RFC8342 is listed in the informative section - what does it mean to be = compliant with an informative reference? >=20 > [Std-802.1AR-2009] certificate) are expected to appear in > >=20 > I did not catch that the term was part of R%FC8342, and = went looking for a reference. I found it in many places, like RFC6241. = For those just that unobservant, could you put a citation here to = RFC8342, which I think is the proper reference for that term. Note: = appears later, and a citation to RFC8342 is probably proper = there as well. Yes, I know, probably about as necessary as a reference = to "packet", but it would have spared me, maybe other non-Yang clueful = folk will be reading this also. >=20 > Section 2 p 5 >=20 > This section defines a YANG 1.1 [RFC7950] module that defines a > "keystore" >=20 > Should that be "ietf-keystore"? Or do you mean keystore in a general = sense, in which case I think the quote marks make it look like a name, = not a general sense. (I went looking for a definition of a "keystore", = but that could just be me.) >=20 > Section 2.1.1. p6 >=20 > The following diagram lists all the "feature" statements defined in >=20 > Everywhere beyond this page it says "tree diagram". RFC8340 is cited = in Section 2.1.3.1, but this is the first use (unless I'm wrong about = the "tree diagram"), so the citation should go here. >=20 > The following diagram lists the "typedef" statements defined in the > The following diagram lists all the "grouping" statements defined in >=20 > diagram -> "tree diagram" >=20 > Section 2.1.3.3 - 2.1.3.6: >=20 > " offer an option as to if an asymmetric key is defined" - personally, = I would say "as to whether". I don't know if the RFC-Editor (and rfc = style guide) care. >=20 > "augmented in if, e.g.," - I actually thought this was an editing = error, until heard "augment in" used as a word in the IETF session. Web = search shows "augment in" is a term of art in netconf! But some uses = add a hyphen, which I think is a good idea. >=20 > reference a asymmetric key in an alternate location. >=20 > a asymmetric -> an asymmetric. A global change might be good, as well = as changing "an symmetric" to "a symmetric". >=20 > Section 2.1.3.4 >=20 > * For the "local-definition" option, the defintion uses the > "asymmetric-key-pair-grouping" grouping discussed in > Section 2.1.3.4 of [I-D.ietf-netconf-crypto-types]. >=20 > It looks to me like it is actually Section 2.1.4.4 of = [I-D.ietf-netconf-crypto-types]. >=20 > Section 2.1.3.7 p 11 >=20 > * The "keystore-grouping" grouping is defines a keystore instance as >=20 > "is defines" -> "defines" >=20 > * For asymmetric keys, each "asymmetric-key" uses the "asymmetric- > key-pair-with-certs-grouping" grouping discussed Section 2.1.3.10 > of [I-D.ietf-netconf-crypto-types]. >=20 > "discussed" -> "discussed in" >=20 > Why do none of the asymmetric keys here use a grouping that is the key = only, like the ct:asymmetric-key-pair-grouping used in Sectoin 2.1.3.4 = of this document (discussed in 2.1.4.4 of = [I-D.ietf-netconf-crypto-types]). >=20 > | | +--rw encrypted-private-key > | | +--rw encrypted-by > | | | +--rw (encrypted-by-choice) > | | | +--:(symmetric-key-ref) > | | | | +--rw symmetric-key-ref? leafref > | | | +--:(asymmetric-key-ref) > | | | +--rw asymmetric-key-ref? leafref >=20 > Section 2.2.1 p 13 >=20 > The following example illustrates keys in . >=20 > Like I said before, maybe a citation of RFC8340 here. >=20 > Section 2.2.3 p 17 has the phrase "following non-normative ". Does = that belong here? Or because this is XML, it can not be confused to be = a normantive Yang module? >=20 > > > hidden-asymmetric-key ey-ref> > >=20 > The "hidden-asymmetric-key" key appears later in the asymmetric-keys = part of the keystore example on p15. I don't know how to prevent that = forward sort of reference for the readers, or if it is a problem. >=20 > Section 2.2.3 p 18 >=20 > list end-entity-cert-with-key { > key name; > ... > uses ks:local-or-keystore-end-entity-cert-with-key-grouping; > description > "An end-entity certificate, and its associated private key, > that may be configured locally or be a reference to a > specific certificate (and its associated private key) in > the keystore."; >=20 > You can't rely on descriptions, but I see no explicit reference to the = private key in that end-entity cert grouping. That grouping is defined = in Section 2.1.3.6 p 9, and the keystore-reference is an = asymmetric-key-certificate-ref-grouping. That grouping has an = asymmetric-key-ref and a cert. The description above says "and its = associated private key". So is the asymmetric-key-ref a ref to the = private key or to a key pair? >=20 > Section 2.3 p 25 >=20 > typedef symmetric-key-ref { > type leafref { > path "/ks:keystore/ks:symmetric-keys/ks:symmetric-key" > + "/ks:name"; > } >=20 > Does default-deny-write belong here, or added each time an item is = defined of this type? >=20 > Section 2.3 p 26 >=20 > case asymmetric-key-ref { > leaf asymmetric-key-ref { > type leafref { > path "/ks:keystore/ks:asymmetric-keys/" > + "ks:asymmetric-key/ks:name"; > } > description > "Identifies the asymmetric key used to encrypt this key."; > } >=20 > (a) "the asymmetric key used to encrypt" - the public key part is used = to encrypt, so is the asymmetric key just the public key or a key-pair = where the appropriate part of the key-pair is used according to context? >=20 > (b) "encrypt this key" - The "this key" part is appropriate if the = assymmetric-key-ref is being used in an encrypted-by-choice structure, = but there are lots of places in this text where the type is not in such = a structure. Is it the case that the uses always resolve to be = encrypting a key? >=20 > (c) "encrypt" - Is it always the case that asymmetric keys in the = keystore will be used to encrypt something? There is no expectation = that the asymmetric key-pair will be used to sign something? >=20 > Section 2.3 p27 >=20 > description > "A grouping that expands to allow the symmetric key to be > either stored locally, within the using data model, or be > a reference to a symmetric key stored in the Keystore."; >=20 > The following is wordsmithing the description text, so a = very-nitty-nit. >=20 > ", or be" -> ", or" (the "be" is before the "either", don't need it) >=20 > A reader might be confused as to whether the disjunction was two = disjuncts or three. >=20 > I might suggest using "i.e., within the using data store". Maybe also > move the "be" inside the "either or" for scoping > "A grouping that expands to allow the symmetric key to either > be stored locally, i.e., within the using data model, or be > a reference to a symmetric key stored in the Keystore."; >=20 > The groupings in this section have a descriptoin of the grouping, a = description of the key case and a description of the choice. I thought = it worked better to place the description of the choice closer to the = "choice local or keystore" rather than at the end. >=20 > And finally. Descriptions very frequently (always?) conclude with a = "." but they are very frequently not sentences, so the "." is not = necessary. I do not know if the RFC-Editor or the Style manual cares. >=20 > Section 2.3 p 28 >=20 > grouping local-or-keystore-asymmetric-key-with-certs-grouping > ... > case keystore { > if-feature "keystore-supported"; > leaf keystore-reference { > type ks:asymmetric-key-ref; > description > "A reference to an asymmetric-key (and all of its > associated certificates) in the Keystore."; >=20 > An example of my puzzle about the = local-or-keystore-asymmetric-key-with-certs-grouping keystore-reference. = How are the certs to be found if the keystore-reference is to the = asymmetric key only? Or must the asymmetric-key-ref sometimes point = just to a key and sometimes to a key+certs, as needed? >=20 > Section 3 p 31 >=20 > In some implementations, a server may support built-in keys. Built- > in built-in keys >=20 > "Built-in built-in" =3D> "Built-in" >=20 > Section 3 p 32 >=20 > In order for the built-in keys (and/or their associated built-in > certificates) to be referenced by configuration, the referenced keys > MUST first be copied into . > ... > Built-in "hidden" keys cannot be copied into other parts of the > configuration because their private parts are hidden, and therefore > impossible to replicate. >=20 > Section 4 p34 says built-in keys MUST be hidden. So they must be = copied to but they can't be copied? Huh? >=20 > The keys SHOULD be copied into > using the same "key" values, so that the server can bind > the references to the built-in entries. >=20 > The word "key" is overloaded in this document, like "The key = characteristic of the built-in keys" and "Key Words". Here, the = reference is surely to a required part of the "list" syntax, so no way = to use a different word. Maybe say 'the same list "key" values' or 'the = same values for the list "key" field/node'. >=20 > Built-in "encrypted" keys MAY be copied > into other parts of the configuration so long as they maintain their > reference to the other built-in key that encrypted them. >=20 > (a) Section 4 p34 says "built-in keys MUST be hidden", so is there a = way the hidden built-in keys can be encrypted keys? >=20 > (b) So encrypted built-in keys must always be encrypted by other = built-in keys? Is there a way to represent that in the data model? (I = explored this before.) >=20 > MAY be a subset of the built-in keys define in > set) of the built-in keys define in >=20 > "define" -> "defined" >=20 > Only the referenced keys need to be copied; that is, the keys in > MAY be a subset of the built-in keys define in > . No keys may be added or changed (with exception to > associating additional certificates to a built-in key); that is, the > keys in MUST be a subset (which includes the whole of the > set) of the built-in keys define in . >=20 > I don't understatnd this part. First it says >=20 > "keys in MAY be a subset of the built-in keys define in = " >=20 > and then >=20 > "keys in MUST be a subset ... of the built-in keys define in = ". >=20 > That is inconsistent, is it intended? >=20 > Does the last sentence mean that if there are built-in keys, no other = keys may be added to the keystore? I don't know what is intended here. >=20 > About "exception to" - I use "exeption to " and "exception for = ". I don't know if the RFC-Editor or the Style manual = cares. >=20 > Section 4.1 p34 >=20 > not support hidden keys, then the private data part of key MUST be=20 >=20 > "of key" -> "of the root key" >=20 > Section 4.1 p35 >=20 > If the hidden root key is asymmetric, then the server > SHOULD provide APIs enabling other keys to be both generated and > encrypted by it >=20 > The "both generated and encrypted by it" sounds like keys are being = generated by the root key. I don't think that's generally true. = Section 4.2 separates key generation and key encryption steps. I think = this should be clearer. >=20 > (The mention of other crypto services moved to area before nits.) >=20 > Section 4.2 p35 >=20 > (A discussion of issues, not nits, was moved to area before nits.) >=20 > Section 4.3 p35 >=20 > (A discussion of issues, not nits, was moved to area before nits.) =20 >=20 > Section 5.2 p38 >=20 > (A discussion of issues, not nits, was moved to area before nits.) >=20 >=20 > | Please be aware that this module uses the "key" and "private- > | key" nodes from the "ietf-crypto-types" module > | [I-D.ietf-netconf-crypto-types], where said nodes have the NACM > | extension "default-deny-all" set, thus preventing unrestricted > | read-access to the cleartext key values. >=20 > This text missed the change A.19 to add a "cleartext" prefix as in = ietf-netconf-crypto-types. The "cleartext" prefix is present in the = modules, tree-diagrams, XML, etc., but the references in text here did = not change. (Actually, I see several examples in the text in = ietf-netconf-crypto-types where the change was not made, e.g. p 9 says = '- The "key" node can encode any plain-text key value.' where the = preceding tree diagram has a node named "cleartext-key" and older = versions said "key".) I appreciate the discussion of the = default-deny-all in Section 3.5 p42 of ietf-netconf-crypto-types and I = think that a citation here would be warranted and useful. >=20 > BTW. I don't know the NACM well but could it be said that the = default-deny-all prevents uncontrolled access, but does not necessarily = prevent unrestricted access, because a present but careless access = control might not actually restrict access? >=20 > Section 6.2 p 39 >=20 > "the the" -> "the" >=20 > Section 7.2 p40 >=20 > The list of Informative References includes: >=20 > [I-D.ietf-netconf-keystore] > Watsen, K., "A YANG Data Model for a Keystore", Work in > Progress, Internet-Draft, draft-ietf-netconf-keystore-17, > 20 May 2020, netconf-keystore-17>. >=20 > Isn't this a self reference to an earlier version? >=20 > Note: ID nits gives 11 warnings, but all are due to references to = older versions of existing drafts or to future versions not yet = published. The latter case seems to be wrong, and the warning usually = notes > (However, the state information for draft-ietf-netconf-keystore is = not > up-to-date. The last update was unsuccessful) >=20 > I have no idea what that means. The warnings are consistent, so may = be something to watch. >=20 > =E2=80=94Sandy >=20 From nobody Wed Aug 12 07:35:13 2020 Return-Path: <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@amazonses.watsen.net> 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 B6CA13A12E7; Wed, 12 Aug 2020 07:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 a_bFzdPqrHef; Wed, 12 Aug 2020 07:35:10 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDCE3A12D3; Wed, 12 Aug 2020 07:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1597242909; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=BWQbyl58R5c+mMQU3ANsUUIXKBp1mKzfM9dP689Q74E=; b=AjLrpLAKNXE6B4WF1k3piKvl2X4oU6945wthIkDvuCekbPRCm5/54Ky4RxeV1VbP sxPLKFKzJCCJqzNl4BuOj4T0o2V3gaVC8HGoBWt2XcyqNSywO7MtodBXB1PXDtAOVxF fkTFQ8z4haTX/blWOri2bs51WOjUN3aKT+I6LVrA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: Date: Wed, 12 Aug 2020 14:35:09 +0000 Cc: secdir@ietf.org, draft-ietf-netconf-keystore@ietf.org, "netconf-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com> References: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> To: =?utf-8?Q?Magnus_Nystr=C3=B6m?= X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.12-54.240.48.93 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 14:35:12 -0000 Hi Magnus, I just want to confirm, did you read the new Section 4 (Encrypting Keys = in Configuration) in the plain-text draft I attached in my previous = response? - it was effectively completely rewritten to align with the = Key Encryption Key and Master Key terminology... PS: Sandy=E2=80=99s response is massive, but it refers to the old = Section 4 text so, before digging into it, I want to ensure that = you=E2=80=99re happy with the new text. Kent > On Aug 11, 2020, at 2:28 AM, Magnus Nystr=C3=B6m = wrote: >=20 > Hi Kent, > On the metadata, yes, I did catch that the actual values are = protected. My > suggestion (it is entirely up to the group of course) was just to = consider > if any of the data that will be readable may warrant a similar = restriction > as you have for the actual key values. >=20 > On the root key etc., - OK, I understand now. I am also good with your > other updates. >=20 > Thanks! > /M >=20 >=20 > On Mon, Aug 10, 2020 at 6:26 PM Kent Watsen = wrote: >=20 >> [CC-ing netconf-chairs] >>=20 >>=20 >> Hi Magnus, >>=20 >> Thank you for the review. Below are some comments, as well as a link = to >> the GitHub commit, and an updated plain-text version of the draft. >>=20 >> Thanks, >> Kent >>=20 >>=20 >> On Aug 10, 2020, at 1:29 AM, Magnus Nystr=C3=B6m = wrote: >>=20 >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the = IESG. >> These comments were written primarily for the benefit of the security = area >> directors. Document editors and WG chairs should treat these = comments just >> like any other last call comments. >>=20 >> This document describes a new YANG model for centralized = configuration of >> cryptographic keys in the context of NETCONF and RESTCONF. >>=20 >>=20 >> Section 4 describes a process to encrypt all "private" keys in a >> configuration. It is unclear if this refers only to the asymmetric = keys in >> the configuration (as "private keys" normally refer to asymmetric = keys) or >> also symmetric keys. It appears to apply to all cryptographic keys, = and it >> therefore seems better to replace this usage of "private" with = "symmetric >> and asymmetric private keys." >>=20 >>=20 >> Good catch. r/all the private keys/both the symmetric and asymmetric = keys/ >>=20 >>=20 >> Likewise, the use of the term "root key" is a bit unclear. A "root = key" >> normally refers to an asymmetric key, but in this text it could be = either From nobody Wed Aug 12 23:26:29 2020 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 62A753A05DE; Wed, 12 Aug 2020 23:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 261bgeYEL4Ng; Wed, 12 Aug 2020 23:26:25 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0353C3A0645; Wed, 12 Aug 2020 23:26:24 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id e6so4127784oii.4; Wed, 12 Aug 2020 23:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GmtDckQoxfWeCWqCT5tXDTxLO5OuJG9i/YQ9uoyRGQ4=; b=XaDjJ2B0UZi/H/HEzuanCfL0AyYgkCV3ONnsAGBsEBpsLL/c66AyBidWm2/L0QYZwV 5NJxfU912sxsQx9V51CZB+1hCZZsD+fBFZ45U1xoUMosrYonuQBar553YnIPoJuDXo/B 8LtI6o8U4taf4SQMaVCAibRlkUb6ziC+Xu2mt2xY7X8JwyMM+LJEL887p2PpsC7afIH3 sARvB7TF2WDpdMNXw3PCaYv3ku3B8bHCixq7oNNNYsL/sIKdcGK3i6zlyFrlMQFlMCdO PpVlgzjUwiDmuyw0zA3U+gkHU+/qWQz7sTmgtdJ77ZrTP1UmBE4OnqBUoty6c4PG3E+s kTXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GmtDckQoxfWeCWqCT5tXDTxLO5OuJG9i/YQ9uoyRGQ4=; b=L/ZwQM9GaTkVL0fhTtDYpv+9Igw2QMA3EZTNAHc5opX8bLqOduiUFqBwNASZUkwTHK B8fekWPF9CFjmgtr5M7sGhNQXMPPFxi4Hv5EQXYaGyZOfOjCByhSzfVl3wLV5YOY6g6x pTHvPe641xCEx228Wh5L7AMcFKpLP2CBSFCOjEE9TOqkMIn78O9/wreQWC2Iy9hjPHpe F5umeZuhQmnQJ1gmQ8Hxw+hw218IiR8V5gY7hcnh5gOQzFdMGyejAOCLanqk3Zg5Qjbw GFKpepYU6R15IXJ9urSLHveJhN1SQdIalQDUVeqI1H/DIvzlSm6almQgBpWyWkO7M4uo Mnbw== X-Gm-Message-State: AOAM532ezMKa23BumErs3kqsHV3jNhnkotr40pG2RcRExeQP6kFtq0fl iO0KWMriaB0M90SO7K3U+83PCDmK7BFb9fbBslI= X-Google-Smtp-Source: ABdhPJzd3gKBQyXjeqsEjmcWqekiLqxFVfGHOlGgiptzPfBGwdE9F6doUCo3IjWuqob0ZhAJ+AYsN2v20VIVupwYoIo= X-Received: by 2002:aca:eb84:: with SMTP id j126mr2246371oih.30.1597299984100; Wed, 12 Aug 2020 23:26:24 -0700 (PDT) MIME-Version: 1.0 References: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com> In-Reply-To: <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com> From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Wed, 12 Aug 2020 23:26:12 -0700 Message-ID: To: Kent Watsen Cc: secdir@ietf.org, draft-ietf-netconf-keystore@ietf.org, "netconf-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000026f1c805acbc62b4" Archived-At: Subject: Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 06:26:28 -0000 --00000000000026f1c805acbc62b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kent, I did review the updated Section 4 and I think it looks good. A couple of minor suggestions: - You could replace "Master Encryption Key (MEK)" with just "Master Key (MK)," it is a more common term I think. - In addition, I would suggest replacing 'In order to decouple the crypto officers from the regular administrators, a second KEK, called th= e "master encryption key" (MEK), is used." with "In order to decouple the crypto officers from the regular administrators, a second KEK, called th= e "master encryption key" (MEK), MAY be used." (The "MAY" shows there are more options) Thanks, /M On Wed, Aug 12, 2020 at 7:35 AM Kent Watsen wrote: > Hi Magnus, > > I just want to confirm, did you read the new Section 4 (Encrypting Keys i= n > Configuration) in the plain-text draft I attached in my previous response= ? > - it was effectively completely rewritten to align with the Key Encryptio= n > Key and Master Key terminology... > > PS: Sandy=E2=80=99s response is massive, but it refers to the old Section= 4 text > so, before digging into it, I want to ensure that you=E2=80=99re happy wi= th the new > text. > > Kent > > > > > On Aug 11, 2020, at 2:28 AM, Magnus Nystr=C3=B6m wr= ote: > > > > Hi Kent, > > On the metadata, yes, I did catch that the actual values are protected. > My > > suggestion (it is entirely up to the group of course) was just to > consider > > if any of the data that will be readable may warrant a similar > restriction > > as you have for the actual key values. > > > > On the root key etc., - OK, I understand now. I am also good with your > > other updates. > > > > Thanks! > > /M > > > > > > On Mon, Aug 10, 2020 at 6:26 PM Kent Watsen > wrote: > > > >> [CC-ing netconf-chairs] > >> > >> > >> Hi Magnus, > >> > >> Thank you for the review. Below are some comments, as well as a link = to > >> the GitHub commit, and an updated plain-text version of the draft. > >> > >> Thanks, > >> Kent > >> > >> > >> On Aug 10, 2020, at 1:29 AM, Magnus Nystr=C3=B6m w= rote: > >> > >> I have reviewed this document as part of the security directorate's > >> ongoing effort to review all IETF documents being processed by the IES= G. > >> These comments were written primarily for the benefit of the security > area > >> directors. Document editors and WG chairs should treat these comments > just > >> like any other last call comments. > >> > >> This document describes a new YANG model for centralized configuration > of > >> cryptographic keys in the context of NETCONF and RESTCONF. > >> > >> > >> Section 4 describes a process to encrypt all "private" keys in a > >> configuration. It is unclear if this refers only to the asymmetric key= s > in > >> the configuration (as "private keys" normally refer to asymmetric keys= ) > or > >> also symmetric keys. It appears to apply to all cryptographic keys, an= d > it > >> therefore seems better to replace this usage of "private" with > "symmetric > >> and asymmetric private keys." > >> > >> > >> Good catch. r/all the private keys/both the symmetric and asymmetric > keys/ > >> > >> > >> Likewise, the use of the term "root key" is a bit unclear. A "root key= " > >> normally refers to an asymmetric key, but in this text it could be > either > > --=20 -- Magnus --00000000000026f1c805acbc62b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
            Hi Kent,
            I did review the updated Section 4= and I think it looks good. A couple of minor suggestions:
              You could replace "Master Encryption Key (MEK)" with just "= ;Master Key (MK)," it is a more common term I think.
            • In additi= on, I would suggest replacing 'In order to decouple the crypto officers= from the regular administrators, a second KEK, called the "master enc= ryption key" (MEK), is used." with "In order to decouple the= crypto officers from the regular administrators, a second KEK, called the = "master encryption key" (MEK), MAY be used."
              (The "M= AY" shows there are more options)
            Thanks,
            /M

            On Wed, Aug 12, 2020 at 7:35 AM Kent Watsen <kent+ietf@watsen.net> wrote:
            Hi Magnus,

            I just want to confirm, did you read the new Section 4 (Encrypting Keys in = Configuration) in the plain-text draft I attached in my previous response?= =C2=A0 - it was effectively completely rewritten to align with the Key Encr= yption Key and Master Key terminology...

            PS: Sandy=E2=80=99s response is massive, but it refers to the old Section 4= text so, before digging into it, I want to ensure that you=E2=80=99re happ= y with the new text.

            Kent



            > On Aug 11, 2020, at 2:28 AM, Magnus Nystr=C3=B6m <magnusn@gmail.com> wrote:
            >
            > Hi Kent,
            > On the metadata, yes, I did catch that the actual values are protected= . My
            > suggestion (it is entirely up to the group of course) was just to cons= ider
            > if any of the data that will be readable may warrant a similar restric= tion
            > as you have for the actual key values.
            >
            > On the root key etc., - OK, I understand now. I am also good with your=
            > other updates.
            >
            > Thanks!
            > /M
            >
            >
            > On Mon, Aug 10, 2020 at 6:26 PM Kent Watsen <kent+ietf@watsen.net> wrote: >
            >> [CC-ing netconf-chairs]
            >>
            >>
            >> Hi Magnus,
            >>
            >> Thank you for the review.=C2=A0 Below are some comments, as well a= s a link to
            >> the GitHub commit, and an updated plain-text version of the draft.=
            >>
            >> Thanks,
            >> Kent
            >>
            >>
            >> On Aug 10, 2020, at 1:29 AM, Magnus Nystr=C3=B6m <magnusn@gmail.com> wrote:<= br> >>
            >> I have reviewed this document as part of the security directorate&= #39;s
            >> ongoing effort to review all IETF documents being processed by the= IESG.
            >> These comments were written primarily for the benefit of the secur= ity area
            >> directors.=C2=A0 Document editors and WG chairs should treat these= comments just
            >> like any other last call comments.
            >>
            >> This document describes a new YANG model for centralized configura= tion of
            >> cryptographic keys in the context of NETCONF and RESTCONF.
            >>
            >>
            >> Section 4 describes a process to encrypt all "private" k= eys in a
            >> configuration. It is unclear if this refers only to the asymmetric= keys in
            >> the configuration (as "private keys" normally refer to a= symmetric keys) or
            >> also symmetric keys. It appears to apply to all cryptographic keys= , and it
            >> therefore seems better to replace this usage of "private"= ; with "symmetric
            >> and asymmetric private keys."
            >>
            >>
            >> Good catch.=C2=A0 r/all the private keys/both the symmetric and as= ymmetric keys/
            >>
            >>
            >> Likewise, the use of the term "root key" is a bit unclea= r. A "root key"
            >> normally refers to an asymmetric key, but in this text it could be= either



            --
            -- Magnus
            --00000000000026f1c805acbc62b4-- From nobody Thu Aug 13 05:47:41 2020 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 8E21D3A0BEF for ; Thu, 13 Aug 2020 05:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 LX7pYNha1VgU for ; Thu, 13 Aug 2020 05:47:37 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C351F3A0BEB for ; Thu, 13 Aug 2020 05:47:37 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 07DClaTq003106 for ; Thu, 13 Aug 2020 08:47:36 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 07DClaTq003106 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1597322856; bh=mG6bggYfsgr+E8U8FeMauqDJmXPj1xkGoHLUa4qDtnI=; h=From:To:Subject:Date:From; b=hsbuVvpwLhZhtl4WQSS9c6k+jTtnO0P22DujNddHAhqyA4d1n1PL6RFM5GGZf9kD1 /P5yxaV6mHZZfRPvqPbnidUucY225CIimTqJicyr0BPpeAzIsKw2jNheSOTCX9zXEH Q4iao/88LZw+5+xzDoci9gHseqPj10YTwz8pOdhc= Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 07DClW2q032316 for ; Thu, 13 Aug 2020 08:47:32 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 13 Aug 2020 08:47:32 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Thu, 13 Aug 2020 08:47:32 -0400 From: Roman Danyliw To: "secdir@ietf.org" Thread-Topic: Re: [secdir] Secdir telechat review of draft-ietf-core-resource-directory-25 Thread-Index: AdZxb5EXK+5N8onPSPuPwGspzjjcbg== Date: Thu, 13 Aug 2020 12:47:31 +0000 Message-ID: <548bf542802f48cf994bf97119111757@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.173] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-core-resource-directory-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 12:47:40 -0000 Hi Valery, thank you for the review! =20 I had a few concerns with the authorization model so I entered a Discuss ba= llot. Regards, Roman > -----Original Message----- > From: Valery Smyslov via Datatracker > Sent: Mon, 10 August 2020 06:47 UTC > To: secdir@ietf.org > Subject: [secdir] Secdir telechat review of draft-ietf-core-resource-dire= ctory-25 > > Reviewer: Valery Smyslov > Review result: Ready > > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area dire= ctors. > Document editors and WG chairs should treat these comments just like any = other > last call comments. > The -24 version of this draft was reviewed by Adam Montville. I looked ov= er his > review and I think that the issue he raised about possible mitigation of= DDoS > amplification attacks has been addressed in this version. I personally th= ink > that sentences describing how DNS and NTP are vulnerable to amplification > attacks are redundant in this document, but that's a matter of taste and > doesn't hurt. > It is my impression, that Security Considerations were mostly written hav= ing in > mind that (D)TLS is always used, however it is only "SHOULD" in this draf= t (or > even "MAY" if we look at RFC6690 which Security Considerations this draft > refers to). I think that adding a few words describing which consequences= for > security not using (D)TLS would have and in which cases it is allowed wil= l make > the Security Considerations more consistent. From nobody Thu Aug 13 07:44:36 2020 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 7122A3A0C85; Thu, 13 Aug 2020 07:44:34 -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, SPF_HELO_NONE=0.001, 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 ZuYzQ2thihYk; Thu, 13 Aug 2020 07:44:32 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B083A0C84; Thu, 13 Aug 2020 07:44:31 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 9EC2428B003B; Thu, 13 Aug 2020 10:44:30 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 480C61F8051; Thu, 13 Aug 2020 10:44:30 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sandra Murphy In-Reply-To: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> Date: Thu, 13 Aug 2020 10:44:27 -0400 Cc: Sandra Murphy , =?utf-8?Q?Magnus_Nystr=C3=B6m?= , "netconf-chairs@ietf.org" , draft-ietf-netconf-keystore@ietf.org, secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> To: Kent Watsen X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 14:44:35 -0000 I interpreted the =E2=80=9Cshared root key=E2=80=9D as a key encryption = key =E2=80=94 I don=E2=80=99t think you eliminate any issues. (The term is common, but I haven=E2=80=99t found an ietf definition to = reference, so I can=E2=80=99t say it *is* a key encryption key.) wrt: =E2=80=9Cone can rotate or renew the key encryption key=E2=80=9D=20 I thought the migration process might work to rotate the root key, not = the =E2=80=9Cshared root key=E2=80=9D. So the =E2=80=9Cfirst server=E2=80= =9D is server Bob with root key Bob.Tues-key and =E2=80=9Csecond = server=E2=80=9D is server Bob with root key Bob.Wed-key. Do you think = that works? Magnus=E2=80=99 mention of =E2=80=9Crenew=E2=80=9D brings up the topic = of key lifetimes, which I realize I did not think to mention. (Yep, out = of all those words, I did not mention something I should have.) This = draft includes expiration times for the certificate, but no key = lifetimes, here or in the crypto-types draft. RFC8177 does include = lifetimes for keys, for the purpose of establishing valid intervals of = use and key rollover. Was key lifetime considered? =E2=80=94Sandy > On Aug 10, 2020, at 9:26 PM, Kent Watsen wrote: >=20 >>=20 >> Likewise, the use of the term "root key" is a bit unclear. A "root = key" normally refers to an asymmetric key, but in this text it could be = either. >>=20 >> More broadly, it may be advantageous to consider a hierarchy, where a = key encryption key is used to encrypt all keys in a configuration and = this key encryption key in turn is protected by a root (or master) key. = This way, two instances only need to share the key encryption key and = there's no need for shared root keys (which may present an issue). = Likewise, one can rotate or renew the key encryption key if desired, = whereas this usually is harder for root keys. >=20 > What you say is the intention, but the terminology used seems to be = off. The alignment needed is: >=20 > Root key =E2=80=94> Master Encryption Key (MEK) > Shared root key =E2=80=94> Key Encryption Key (KEK) >=20 From nobody Thu Aug 13 08:05:04 2020 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 521AC3A0C9A; Thu, 13 Aug 2020 08:05:02 -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, SPF_HELO_NONE=0.001, 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 B0mQyfW36MPu; Thu, 13 Aug 2020 08:05:01 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF453A0C98; Thu, 13 Aug 2020 08:05:00 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0AFE528B003B; Thu, 13 Aug 2020 11:05:00 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id B1EE81F8051; Thu, 13 Aug 2020 11:04:59 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sandra Murphy In-Reply-To: <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com> Date: Thu, 13 Aug 2020 11:04:57 -0400 Cc: Sandra Murphy , =?utf-8?Q?Magnus_Nystr=C3=B6m?= , "netconf-chairs@ietf.org" , draft-ietf-netconf-keystore@ietf.org, secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6C99EF5C-0BEB-404E-85F0-3D779320A416@tislabs.com> References: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com> To: Kent Watsen X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 15:05:03 -0000 Yep, sorry. A comment that I felt needed a table of contents, wow. In my defense, this was my first view of the draft, not a =E2=80=9Cwhy = didn=E2=80=99t you mention that earlier=E2=80=9D comment. This was the result of an initial review before the IETF, a full day of = review (my first look at a YANG module) and a full day of transcribing = (and resolving) comments. =E2=80=94Sandy =20 > On Aug 12, 2020, at 10:35 AM, Kent Watsen = wrote: >=20 > PS: Sandy=E2=80=99s response is massive, but it refers to the old = Section 4 text so, before digging into it, I want to ensure that = you=E2=80=99re happy with the new text. From nobody Thu Aug 13 08:16:24 2020 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 1C3EF3A0D17; Thu, 13 Aug 2020 08:16:23 -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, SPF_HELO_NONE=0.001, 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 zrBmuYSf9_Sr; Thu, 13 Aug 2020 08:16:22 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E82A3A0D0D; Thu, 13 Aug 2020 08:16:21 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 7F84B28B003B; Thu, 13 Aug 2020 11:16:20 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 0DBE21F8051; Thu, 13 Aug 2020 11:16:20 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sandra Murphy In-Reply-To: <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com> Date: Thu, 13 Aug 2020 11:16:17 -0400 Cc: Sandra Murphy , =?utf-8?Q?Magnus_Nystr=C3=B6m?= , "netconf-chairs@ietf.org" , draft-ietf-netconf-keystore@ietf.org, secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4259FA7C-8A2F-4F3E-B998-CD870EE9E3C0@tislabs.com> References: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com> To: Kent Watsen X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 15:16:23 -0000 > On Aug 12, 2020, at 10:35 AM, Kent Watsen = wrote: >=20 > I just want to confirm, did you read the new Section 4 (Encrypting = Keys in Configuration) in the plain-text draft I attached in my previous = response?=20 Taking a look at -20, it looks like Section 4 is the only change (of = substance). I see that you removed the early paragraph that says the root key should = be hidden but might be unhidden with careful access control. Have you = abandoned the idea of an unhidden root key (aka MEK)? The revisions have eliminated the "Given the long lifetime of built-in = keys (see Section 3), built-in keys MUST be hidden.=E2=80=9D Did you = intend to eliminate that? Are MEK and KEK the only keys that can be used to encrypt other keys? I = thought the YANG model permitted using a reference to any keystore key = in the encrypted-by field. =E2=80=94Sandy From nobody Thu Aug 13 10:32:22 2020 Return-Path: <01000173e8e12b62-f962f0a7-4745-4692-9d13-5d3faf14270f-000000@amazonses.watsen.net> 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 34AE93A0F6A; Thu, 13 Aug 2020 10:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 4QUmyKDpWY8E; Thu, 13 Aug 2020 10:32:19 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154613A0F3B; Thu, 13 Aug 2020 10:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1597339937; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=OdovUbqWAOQy5SWgiytIL6ObpD4Wtdqn2p7+gGdAMok=; b=LwO8kttJXkdwJWEshXSr3bxDeFng50/aiCcftmSnbFicRbLWQPqiWqsUIOQul8LQ R5BntZc21iiKuGeo0tB7eBEZcrnXv+meZAZW/rXbn6WxIEPEVqxV5fLUTf+S5ny3/Mz czn2FsPpzXh2ALmJrsNIfRbJcFipBG+1IM2sYkWs= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <6C99EF5C-0BEB-404E-85F0-3D779320A416@tislabs.com> Date: Thu, 13 Aug 2020 17:32:17 +0000 Cc: =?utf-8?Q?Magnus_Nystr=C3=B6m?= , "netconf-chairs@ietf.org" , draft-ietf-netconf-keystore@ietf.org, secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-ID: <01000173e8e12b62-f962f0a7-4745-4692-9d13-5d3faf14270f-000000@email.amazonses.com> References: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com> <6C99EF5C-0BEB-404E-85F0-3D779320A416@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.13-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 17:32:20 -0000 Hi Sandy, Thank you for your most awesome review! I=E2=80=99m preparing a response but it=E2=80=99s taking time to get = through it all. Early to mid next week seems about right. Kent > On Aug 13, 2020, at 11:04 AM, Sandra Murphy wrote: >=20 > Yep, sorry. A comment that I felt needed a table of contents, wow. >=20 > In my defense, this was my first view of the draft, not a =E2=80=9Cwhy = didn=E2=80=99t you mention that earlier=E2=80=9D comment. >=20 > This was the result of an initial review before the IETF, a full day = of review (my first look at a YANG module) and a full day of = transcribing (and resolving) comments. >=20 > =E2=80=94Sandy =20 >=20 >> On Aug 12, 2020, at 10:35 AM, Kent Watsen = wrote: >>=20 >> PS: Sandy=E2=80=99s response is massive, but it refers to the old = Section 4 text so, before digging into it, I want to ensure that = you=E2=80=99re happy with the new text. >=20 From nobody Thu Aug 13 11:02:51 2020 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 C947C3A102D for ; Thu, 13 Aug 2020 11:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 XlLWgpPQisJT for ; Thu, 13 Aug 2020 11:02:47 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4D4213A102A for ; Thu, 13 Aug 2020 11:02:47 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07DI2hMn026808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 14:02:45 -0400 Date: Thu, 13 Aug 2020 11:02:42 -0700 From: Benjamin Kaduk To: Valery Smyslov Cc: secdir@ietf.org Message-ID: <20200813180242.GZ92412@kduck.mit.edu> References: <159704204394.11310.18005109400419971010@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <159704204394.11310.18005109400419971010@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-core-resource-directory-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 18:02:50 -0000 Thanks for the reviews, Valery and Adam! Like Roman, I filed a Discuss ballot with questions about the authorization model, including whether transport security such as (D)TLS can/should be assumed, as you pointed out. (I also mentioned that the discussion of NTP DDoS seems out of place...) -Ben On Sun, Aug 09, 2020 at 11:47:23PM -0700, Valery Smyslov via Datatracker wrote: > Reviewer: Valery Smyslov > Review result: Ready > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > The -24 version of this draft was reviewed by Adam Montville. I looked over his > review and I think that the issue he raised about possible mitigation of DDoS > amplification attacks has been addressed in this version. I personally think > that sentences describing how DNS and NTP are vulnerable to amplification > attacks are redundant in this document, but that's a matter of taste and > doesn't hurt. > > It is my impression, that Security Considerations were mostly written having in > mind that (D)TLS is always used, however it is only "SHOULD" in this draft (or > even "MAY" if we look at RFC6690 which Security Considerations this draft > refers to). I think that adding a few words describing which consequences for > security not using (D)TLS would have and in which cases it is allowed will make > the Security Considerations more consistent. > > > > _______________________________________________ > 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 Aug 13 11:15:21 2020 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 1DD883A0FEB for ; Thu, 13 Aug 2020 11:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dI48ckCtF3wh for ; Thu, 13 Aug 2020 11:15:19 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 A04D33A0FE6 for ; Thu, 13 Aug 2020 11:15:18 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07DIFEXf031615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 14:15:16 -0400 Date: Thu, 13 Aug 2020 11:15:13 -0700 From: Benjamin Kaduk To: Catherine Meadows Cc: secdir@ietf.org Message-ID: <20200813181513.GB92412@kduck.mit.edu> References: <159404545672.27089.13777709421479611964@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <159404545672.27089.13777709421479611964@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lamps-rfc7030est-clarify-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 18:15:20 -0000 Thanks for the review, Catherine (and thanks Michael for the updates). I entered a No OBjection ballot. -Ben On Mon, Jul 06, 2020 at 07:24:16AM -0700, Catherine Meadows via Datatracker wrote: > Reviewer: Catherine Meadows > Review result: Has Nits > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. Document > editors and WG chairs should treat these comments just like any other comments. > > This draft sets forth changes to the syntax of Enrollment over Secure Transport > (EST) (RFC7030) to fix some errors and ambiguities that resulted in > interoperability issues. RFC7030 also includes a form of header that has been > deprecated in other RFC’s. This document thus deprecates that header as well. > > Since the only changes to the draft makes to the syntax are either to clarify > ambiguities in the descriptions and to deprecate syntax that has already > deprecated by other RFC’s, it presents no new security or privacy concerns. > However, I found a few typos, etc. that I am listing below. They are all of > the sort that would be missed by a spell checker. I don’t know if I got all > of them, so I’d suggest another round or proofreading. > > I consider this document Ready with Nits. > > Abstract > > some errata that was reported > > should be > > some errata that were reported > > This document fixes some > syntactical errors in ASN.1 that was presented > > assuming that the word “was” refers to the errors, that should be > > This document fixes some > syntactical errors in ASN.1 that were presented > > In the Privacy Considerations Section > > This document does not disclose any additional identifies > > should be > > This document does not disclose any additional identities > > From nobody Thu Aug 13 11:23:05 2020 Return-Path: <01000173e90f9703-c3dcb1ba-0b0d-431c-b7db-93389b5dca37-000000@amazonses.watsen.net> 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 2118A3A1033; Thu, 13 Aug 2020 11:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 is1VK2ii4dt5; Thu, 13 Aug 2020 11:23:01 -0700 (PDT) Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4303A101C; Thu, 13 Aug 2020 11:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1597342980; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=yFtMULbagB0WSTyl/ot4VpF9c+E3D3mejRlmiUHFRQ8=; b=XNQjeq5VxqkBxL+LMrho/T0s7vGHIFFjrkOzbBID2th+bmgY7x+unyPzoimuQ+0h 84OjdlnhDhxD5RTXDCF3PqLZ8Qz5mIpw/rTFUzGyNR69Z+z9fgPIm4tGbw+Lz1/0t9I KHQ9mWzhe8CS3KrzTIsAPA0fjuY5UIUh7IbFF1Kg= From: Kent Watsen Message-ID: <01000173e90f9703-c3dcb1ba-0b0d-431c-b7db-93389b5dca37-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_25F0ED38-24EF-48CB-A63A-B17F427DAA99" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 13 Aug 2020 18:23:00 +0000 In-Reply-To: <4259FA7C-8A2F-4F3E-B998-CD870EE9E3C0@tislabs.com> Cc: =?utf-8?Q?Magnus_Nystr=C3=B6m?= , "netconf-chairs@ietf.org" , draft-ietf-netconf-keystore@ietf.org, secdir@ietf.org To: Sandra Murphy References: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com> <4259FA7C-8A2F-4F3E-B998-CD870EE9E3C0@tislabs.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.13-54.240.48.95 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 18:23:03 -0000 --Apple-Mail=_25F0ED38-24EF-48CB-A63A-B17F427DAA99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Sandy, >> On Aug 12, 2020, at 10:35 AM, Kent Watsen = wrote: >>=20 >> I just want to confirm, did you read the new Section 4 (Encrypting = Keys in Configuration) in the plain-text draft I attached in my previous = response?=20 >=20 > Taking a look at -20, it looks like Section 4 is the only change (of = substance). >=20 > I see that you removed the early paragraph that says the root key = should be hidden but might be unhidden with careful access control. = Have you abandoned the idea of an unhidden root key (aka MEK)? It has not been intentionally abandoned, for the simple reason that not = all devices may support =E2=80=9Chidden=E2=80=9D keys and so = access-control is all they can do. Sadly, this is in fact what most = systems do today. While the "root key=E2=80=9D was generally mapped to =E2=80=9CMEK", the = section containing the text you mention was more about a KEK. Thus I = made this tweak to my local copy: OLD: In other deployments, an organization's crypto officer, = possessing the KEK's cleartext value, configures the same KEK on the second = server, presumably as a hidden key so that the cleartext value is = not disclosed to regular administrators. NEW: In other deployments, an organization's crypto officer, = possessing the KEK's cleartext value, configures the same KEK on the second = server, presumably as a hidden key or a key protected by = access-control=20 (e.g., NACM's "default-deny-all), so that the cleartext value = is not disclosed to regular administrators. > The revisions have eliminated the "Given the long lifetime of built-in = keys (see Section 3), built-in keys MUST be hidden.=E2=80=9D Did you = intend to eliminate that? Kind of. I feel that this draft cannot be overly proscriptive. The = closest new text follows with an enhancement that (I think) strikes the = right balance (i.e. the =E2=80=9CMUST=E2=80=9D in the quoted text = becomes =E2=80=94> "commonly=E2=80=A6hidden=E2=80=9D). However, I = tweaked the text a bit more to be even more like that from before: OLD: A MEK is commonly a globally-unique built-in (see ) asymmetric key for which the private key is hidden and the = public key is contained in an identity certificate (e.g., IDevID). NEW: A MEK is commonly a globally-unique built-in (see ) asymmetric key for which the private key, due to its long = lifetime, is hidden=20 () and the=20 public key is contained in an identity certificate (e.g., = IDevID). > Are MEK and KEK the only keys that can be used to encrypt other keys? = I thought the YANG model permitted using a reference to any keystore key = in the encrypted-by field. Correct. In fact, the YANG model itself doesn=E2=80=99t know anything = about MEKs or KEKs; it only has keys, which MAY be builtin and MAY be = encrypted or hidden. Effectively the model supports any key encrypting = another key and, in that sense, any key can be a KEK. Sections 3 and 4 attempt to highlight best/common practice (for those = that might not know any better) without limiting possible variations = (for those that think they do or otherwise are more adventurous). ;) Kent --Apple-Mail=_25F0ED38-24EF-48CB-A63A-B17F427DAA99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
            Hi Sandy,

            On Aug 12, 2020, at 10:35 AM, Kent Watsen = <kent+ietf@watsen.net> wrote:

            I just want to confirm, did you read the new Section 4 = (Encrypting Keys in Configuration) in the plain-text draft I attached in = my previous response?

            Taking = a look at -20, it looks like Section 4 is the only change (of = substance).

            I see that you removed the = early paragraph that says the root key should be hidden but might be = unhidden with careful access control.  Have you abandoned the idea = of an unhidden root key (aka MEK)?

            It = has not been intentionally abandoned, for the simple reason that not all = devices may support =E2=80=9Chidden=E2=80=9D keys and so access-control = is all they can do.  Sadly, this is in fact what most systems do = today.

            While the "root key=E2=80=9D = was generally mapped to =E2=80=9CMEK", the section containing the text = you mention was more about a KEK.  Thus I made this tweak to my = local copy:

            OLD:
                =        In other deployments, an organization's = crypto officer, possessing the
                  =       KEK's cleartext value, configures the same = KEK on the second server,
                    =     presumably as a hidden key so that the cleartext = value is not disclosed
                      =   to regular administrators.

            NEW:
                       In = other deployments, an organization's crypto officer, possessing = the
                       KEK's = cleartext value, configures the same KEK on the second server,
                       presumably as a = hidden key or a key protected by access-control 
                       (e.g., NACM's = "default-deny-all), so that the cleartext value is = not
                       disclosed to = regular administrators.


            The revisions have eliminated the "Given the = long lifetime of built-in keys (see Section 3), built-in keys MUST be = hidden.=E2=80=9D  Did you intend to eliminate that?

            Kind of. =  I feel that this draft cannot be overly proscriptive. The closest = new text follows with an enhancement that (I think) strikes the right = balance (i.e. the =E2=80=9CMUST=E2=80=9D in the quoted text becomes = =E2=80=94> "commonly=E2=80=A6hidden=E2=80=9D).  However, I = tweaked the text a bit more to be even more like that from = before:

            OLD:
                        A MEK is = commonly a globally-unique built-in = (see <xref target=3D"built-ins"/>)
              =           asymmetric key for which the = private key is hidden and the public key is
                =         contained in an identity certificate = (e.g., IDevID).

            NEW:
                  =       A MEK is commonly a = globally-unique built-in = (see <xref target=3D"built-ins"/>)
                      =   asymmetric key for which the private key, due to its = long lifetime, is hidden 
                    =   =   (<relref section=3D"2.1.4.4." target=3D"I-D.ietf-= netconf-crypto-types"/>) and the 
                =         public key is contained in an = identity certificate (e.g., IDevID).



            Are MEK and KEK the only keys that can be used to encrypt = other keys?  I thought the YANG model permitted using a reference = to any keystore key in the encrypted-by field.

            Correct.  In fact, the YANG model itself = doesn=E2=80=99t know anything about MEKs or KEKs; it only has keys, = which MAY be builtin and MAY be encrypted or hidden.  Effectively = the model supports any key encrypting another key and, in that sense, = any key can be a KEK.

            Sections 3 and = 4 attempt to highlight best/common practice (for those that might not = know any better) without limiting possible variations (for those that = think they do or otherwise are more adventurous).  ;)


            Kent


            = --Apple-Mail=_25F0ED38-24EF-48CB-A63A-B17F427DAA99-- From nobody Thu Aug 13 11:40:44 2020 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 5CE463A1005; Thu, 13 Aug 2020 11:40:42 -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, SPF_HELO_NONE=0.001, 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 zPN5m4SnHr5n; Thu, 13 Aug 2020 11:40:39 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739553A0D2A; Thu, 13 Aug 2020 11:40:39 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 786A628B003B; Thu, 13 Aug 2020 14:40:38 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 232061F8051; Thu, 13 Aug 2020 14:40:38 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sandra Murphy In-Reply-To: <01000173e8e12b62-f962f0a7-4745-4692-9d13-5d3faf14270f-000000@email.amazonses.com> Date: Thu, 13 Aug 2020 14:40:36 -0400 Cc: Sandra Murphy , =?utf-8?Q?Magnus_Nystr=C3=B6m?= , "netconf-chairs@ietf.org" , draft-ietf-netconf-keystore@ietf.org, secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <36E95B44-91BD-4FE6-9C0C-90DBA4A6C36A@tislabs.com> References: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com> <6C99EF5C-0BEB-404E-85F0-3D779320A416@tislabs.com> <01000173e8e12b62-f962f0a7-4745-4692-9d13-5d3faf14270f-000000@email.amazonses.com> To: Kent Watsen X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 18:40:42 -0000 > On Aug 13, 2020, at 1:32 PM, Kent Watsen wrote: >=20 > Hi Sandy, >=20 > Thank you for your most awesome review! >=20 > I=E2=80=99m preparing a response but it=E2=80=99s taking time to get = through it all. Early to mid next week seems about right. No problem whatsoever. I have some work to catch up on. :-) =E2=80=94Sandy >=20 > Kent >=20 >=20 >=20 >> On Aug 13, 2020, at 11:04 AM, Sandra Murphy = wrote: >>=20 >> Yep, sorry. A comment that I felt needed a table of contents, wow. >>=20 >> In my defense, this was my first view of the draft, not a =E2=80=9Cwhy = didn=E2=80=99t you mention that earlier=E2=80=9D comment. >>=20 >> This was the result of an initial review before the IETF, a full day = of review (my first look at a YANG module) and a full day of = transcribing (and resolving) comments. >>=20 >> =E2=80=94Sandy =20 >>=20 >>> On Aug 12, 2020, at 10:35 AM, Kent Watsen = wrote: >>>=20 >>> PS: Sandy=E2=80=99s response is massive, but it refers to the old = Section 4 text so, before digging into it, I want to ensure that = you=E2=80=99re happy with the new text. >>=20 From nobody Thu Aug 13 12:09:55 2020 Return-Path: <01000173e93a78c8-35cdcae2-405d-4c42-8f77-a8176753fa0e-000000@amazonses.watsen.net> 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 B86A53A104C; Thu, 13 Aug 2020 12:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 T0QXx37KgW0x; Thu, 13 Aug 2020 12:09:51 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBF33A0746; Thu, 13 Aug 2020 12:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1597345790; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=1sqKpbQz3A7G4AZXFPcodZrpBGMxWvdxC9qQePuPOK4=; b=hyxxihy1c+dGwnFQj0DxjG/5IAaHoIhSWwIQNJVk4qyZbkB2HfjeIN0U7CWRQgBr mL+gay0xNpoWs3rfdsXwt/JI3oK5uvYlGq9e3WNzuY/hadVxEEGhen3lCpzSLAcbxVy aqXwSi8Q2OOWUbmfEtXbXhp+egDCJMkg39t2tpGM= From: Kent Watsen Message-ID: <01000173e93a78c8-35cdcae2-405d-4c42-8f77-a8176753fa0e-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3F708979-73AB-424E-B64F-77F6DB76E5A7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 13 Aug 2020 19:09:50 +0000 In-Reply-To: Cc: =?utf-8?Q?Magnus_Nystr=C3=B6m?= , "netconf-chairs@ietf.org" , draft-ietf-netconf-keystore@ietf.org, secdir@ietf.org To: Sandra Murphy References: <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.13-54.240.48.93 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 19:09:54 -0000 --Apple-Mail=_3F708979-73AB-424E-B64F-77F6DB76E5A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Sandy, I think you=E2=80=99re making two comments, but there may be more! 1) is there support for key-lifetime/expiration? The answer is =E2=80=9Cno=E2=80=9D (or, perhaps, =E2=80=9Cnot yet=E2=80=9D= ), for the simple reason that key file formats (e.g., OpenSSL = RSAPrivateKey, ECPrivateKey, AESKey, etc.) do not have fields for = validity periods. Do you think this module should add such a field = (like RFC 8177)? - if it did, then the module certainly could also = define a key-expiration notification. Please advise. 2) Can KEKs be renewed / rolled over? Yes, but not like in RFC 8177. I=E2=80=99m not a routing person, but my = understanding to that RFC 8177=E2=80=99s approach is visible in routing = protocol messages... In contrast, configuration is being set and there may only be the = =E2=80=9Ccurrent=E2=80=9D key. That said, a renew/rollover might be = implemented as follows: - crypto-officer generates a new KEK - for each device having the same KEK (e.g., primary/failover = devices): - crypto-officer encrypts the KEK with the device=E2=80=99s MEK - crypto-officer hands off the encrypted-KEK to a regular admin - regular-admin loads the encrypted KEK into the device - note that, at this time, no switchover has occurred yet - for each key on the device encrypted by expiring KEK: - regular-admin requests the device to encrypt the key using the new KEK (no switchover has occurred yet). In = pseudocode: new-encrypted-key =3D new-kek.encrypt(cleartext-key) (see = [1]) - regular-admin replaces the key (encrypted by the expiring KEK) with the new (really the same) key (encrypted by The new KEK). =20 [1] this entails the regular admins knowing the cleartext clears, which = is NOT best practice, but a necessary(?) consequence of the decision = discussed here: = https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-17#section-3.2= . =20 To be clear, there were before two RPCs: generate-symmetric-key() and = generate-asymmetric-key(). If IETF were to rescind this decision, or = when a future effort fills in the missing piece, then it would make = sense to additional RPC called, perhaps, reencrypt-symmetric-key() and = reencrypt-asymmetric-key(). [Update, due to second-guessing myself] Hmmm, the reasons for why the = two =E2=80=9Cgenerate=E2=80=9D RPCs couldn=E2=80=99t be defined may not = apply/limit the creation of said =E2=80=9Creencrypt=E2=80=9D RPCs=E2=80=A6= is this something you think should be added? Regardless if said =E2=80=9Creencrypt=E2=80=9D RPCs are added or not, do = you think the draft should extend =E2=80=9CEncrypting Keys in = Configuration=E2=80=9D section with the above sketch of steps? Please let me know if there were more than these two questions in your = comment. Thanks, Kent > On Aug 13, 2020, at 10:44 AM, Sandra Murphy wrote: >=20 > I interpreted the =E2=80=9Cshared root key=E2=80=9D as a key = encryption key =E2=80=94 I don=E2=80=99t think you eliminate any issues. >=20 > (The term is common, but I haven=E2=80=99t found an ietf definition to = reference, so I can=E2=80=99t say it *is* a key encryption key.) >=20 > wrt: =E2=80=9Cone can rotate or renew the key encryption key=E2=80=9D=20= >=20 > I thought the migration process might work to rotate the root key, not = the =E2=80=9Cshared root key=E2=80=9D. So the =E2=80=9Cfirst server=E2=80= =9D is server Bob with root key Bob.Tues-key and =E2=80=9Csecond = server=E2=80=9D is server Bob with root key Bob.Wed-key. Do you think = that works? >=20 > Magnus=E2=80=99 mention of =E2=80=9Crenew=E2=80=9D brings up the topic = of key lifetimes, which I realize I did not think to mention. (Yep, out = of all those words, I did not mention something I should have.) This = draft includes expiration times for the certificate, but no key = lifetimes, here or in the crypto-types draft. RFC8177 does include = lifetimes for keys, for the purpose of establishing valid intervals of = use and key rollover. Was key lifetime considered? >=20 > =E2=80=94Sandy >=20 >> On Aug 10, 2020, at 9:26 PM, Kent Watsen = wrote: >>=20 >>>=20 >>> Likewise, the use of the term "root key" is a bit unclear. A "root = key" normally refers to an asymmetric key, but in this text it could be = either. >>>=20 >>> More broadly, it may be advantageous to consider a hierarchy, where = a key encryption key is used to encrypt all keys in a configuration and = this key encryption key in turn is protected by a root (or master) key. = This way, two instances only need to share the key encryption key and = there's no need for shared root keys (which may present an issue). = Likewise, one can rotate or renew the key encryption key if desired, = whereas this usually is harder for root keys. >>=20 >> What you say is the intention, but the terminology used seems to be = off. The alignment needed is: >>=20 >> Root key =E2=80=94> Master Encryption Key (MEK) >> Shared root key =E2=80=94> Key Encryption Key (KEK) >>=20 >=20 --Apple-Mail=_3F708979-73AB-424E-B64F-77F6DB76E5A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Sandy,

            I think = you=E2=80=99re making two comments, but there may be more!


            1) is there support for key-lifetime/expiration?

            The answer is =E2=80=9Cno=E2= =80=9D (or, perhaps, =E2=80=9Cnot yet=E2=80=9D), for the simple reason = that key file formats (e.g., OpenSSL RSAPrivateKey, ECPrivateKey, = AESKey, etc.) do not have fields for validity periods.  Do you = think this module should add such a field (like RFC = 8177)? - if it did, then the module certainly could also = define a key-expiration notification.  Please advise.


            2) Can KEKs be renewed / rolled over?

            Yes, but not like in RFC 8177.  I=E2=80=99m = not a routing person, but my understanding to that RFC 8177=E2=80=99s = approach is visible in routing protocol messages...

            In contrast, configuration is being set and there = may only be the =E2=80=9Ccurrent=E2=80=9D key.  That said, a = renew/rollover might be implemented as follows:

               - crypto-officer generates a new = KEK
               - for each device having the same KEK (e.g., = primary/failover devices):
                    - = crypto-officer encrypts the KEK with the device=E2=80=99s = MEK
                    - crypto-officer hands off the = encrypted-KEK to a regular admin
                    - = regular-admin loads the encrypted KEK into the device
              =           - note that, at this time, no = switchover has occurred yet
                    - for = each key on the device encrypted by expiring KEK:
              =           - regular-admin requests the device = to encrypt the key using
                      =      the new KEK (no switchover has occurred yet). =  In pseudocode:
                    =        new-encrypted-key =3D new-kek.encrypt(cleartext-key) (see = [1])
                        - = regular-admin replaces the key (encrypted by the = expiring
                          KEK) = with the new (really the same) key (encrypted by
                =           The new KEK).
                =                     =    
            [1] this entails the regular admins knowing the = cleartext clears, which is NOT best practice, but a necessary(?) = consequence of the decision discussed here: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-17#= section-3.2.   

            To be = clear, there were before two RPCs: generate-symmetric-key() and = generate-asymmetric-key().  If IETF were to rescind this decision, = or when a future effort fills in the missing piece, then it would make = sense to additional RPC called, perhaps, reencrypt-symmetric-key() and = reencrypt-asymmetric-key().

            [Update, = due to second-guessing myself] Hmmm, the reasons for why the two = =E2=80=9Cgenerate=E2=80=9D RPCs couldn=E2=80=99t be defined may not = apply/limit the creation of said =E2=80=9Creencrypt=E2=80=9D RPCs=E2=80=A6= is this something you think should be added?

            Regardless if said =E2=80=9Creencrypt=E2=80=9D RPCs are added or not, do you = think the draft should extend =E2=80=9CEncrypting = Keys in = Configuration=E2=80=9D section with the above sketch of = steps?


            Please let me know if there were more than these = two questions in your comment.

            Thanks,
            Kent



            On Aug 13, 2020, at 10:44 AM, = Sandra Murphy <sandy@tislabs.com> wrote:

            I = interpreted the =E2=80=9Cshared root key=E2=80=9D as a key encryption = key =E2=80=94 I don=E2=80=99t think you eliminate any issues.

            (The term is common, but I haven=E2=80=99t = found an ietf definition to reference, so I can=E2=80=99t say it *is* a = key encryption key.)

            wrt: =E2=80=9Cone can = rotate or renew the key encryption key=E2=80=9D

            I thought the migration process might work to rotate the root = key, not the =E2=80=9Cshared root key=E2=80=9D.  So the =E2=80=9Cfirs= t server=E2=80=9D is server Bob with root key Bob.Tues-key and =E2=80=9Cse= cond server=E2=80=9D is server Bob with root key Bob.Wed-key.  Do = you think that works?

            Magnus=E2=80=99 = mention of =E2=80=9Crenew=E2=80=9D brings up the topic of key lifetimes, = which I realize I did not think to mention.  (Yep, out of all those = words, I did not mention something I should have.)  This draft = includes expiration times for the certificate, but no key lifetimes, = here or in the crypto-types draft.  RFC8177 does include lifetimes = for keys, for the purpose of establishing valid intervals of use and key = rollover.  Was key lifetime considered?

            =E2=80=94Sandy

            On Aug 10, 2020, at 9:26 PM, Kent Watsen <kent+ietf@watsen.net> wrote:


            Likewise, = the use of the term "root key" is a bit unclear. A "root key" normally = refers to an asymmetric key, but in this text it could be either.

            More broadly, it may be advantageous to = consider a hierarchy, where a key encryption key is used to encrypt all = keys in a configuration and this key encryption key in turn is protected = by a root (or master) key. This way, two instances only need to share = the key encryption key and there's no need for shared root keys (which = may present an issue). Likewise, one can rotate or renew the key = encryption key if desired, whereas this usually is harder for root = keys.

            What you say is the = intention, but the terminology used seems to be off.   The = alignment needed is:

             Root key = =E2=80=94> Master Encryption Key (MEK)
             Shared = root key =E2=80=94> Key Encryption Key (KEK)



            = --Apple-Mail=_3F708979-73AB-424E-B64F-77F6DB76E5A7-- From nobody Thu Aug 13 17:45:05 2020 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 D86CB3A0B76; Thu, 13 Aug 2020 17:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yzPY3Yx4m0G; Thu, 13 Aug 2020 17:44:59 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650118.outbound.protection.outlook.com [40.107.65.118]) (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 BD8663A0B79; Thu, 13 Aug 2020 17:44:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aQt40o+Z2JBE1kabBllY8SET2JRJ3J+7UwO4j4uQoEIdtf3MiXJcDa5UyVPmLJIOeKYrM7PbCE/+sqvABe3G794JVQ0L6uwHU6JE6LJuM0Y0dW6AwvGdaSkP/CwEOYR1+ehrokf0USwEYFBZJhYgFNolacOcs9QtsYxuT3JaMgwTQFESTeaPnO850QuUgXYIJDTjFK3qeh2pvHJBuSR6A0UPM6F6f7kj6wBs3w0zrdzgBDi/viSSMhiBMnpUf62PRjEOXqBddUQOlYDIq6aCniL8954nHUdnxF372QFpR5Xo+xpAI9/6tVkpZ4GF6BnIlq+OmkAAEn3YTdDh8p8hCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RaTrDM7coCJ4d+c6hVE3Sb0/0pzeUCq0wIWF9Tlaxgw=; b=kctF/Oc1VOlu0oAqzAguj9Z0nnxf2KGTPiex04UhofaLTF4F/EKaWkpCgC6dEJiVlQVWMdwo81k3TLcTQWN5DtJqNpcARKHAmDwTc8QFG/VDcTV8qIDi53WxWwrTtXC4opJurF7sq6/yD4r1Y87i/hkbcaIw+Tu6UXyv4kxz8AtDCNPsFvVHQx06mX4zYDNdMaCqFvLJe7D2jZ30+XEZ8wfTZP2rVynnzMlcex4m+sbE1Smx9jApQVz2+ToLzZMdHsSyesLWB3z784Rq7QIL7ojloNMSsjan7mChf8vZ5uiXofPHbCvIuzIb5KzWqs5AcFEO91/XHgB8feOX0692Ww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RaTrDM7coCJ4d+c6hVE3Sb0/0pzeUCq0wIWF9Tlaxgw=; b=ak+jpNUhwxqARQDJl28R7eCXrUXarhCdTY+j+nUnNikO2z8jSGRttDR2Yv+a6nbnWmkGWStVLkP3cgeCzVyhIL1Ak+sOGdxcUjQsNerIrNXEJBSPw/bIynYFZnomjuBMe3iGIYYDgKDykD0S96SlYPBH985KuGyEahXbDDONlyE= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0878.namprd00.prod.outlook.com (2603:10b6:208:a3::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3323.0; Fri, 14 Aug 2020 00:44:50 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::e9b3:c850:e214:627e]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::e9b3:c850:e214:627e%6]) with mapi id 15.20.3326.000; Fri, 14 Aug 2020 00:44:50 +0000 From: Mike Jones To: Kyle Rose , "secdir@ietf.org" CC: "draft-ietf-cbor-date-tag.all@ietf.org" , "last-call@ietf.org" , "cbor@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-cbor-date-tag-05 Thread-Index: AdZx1BxyoBjm9wtuR3uPvOkylOb0YQ== Date: Fri, 14 Aug 2020 00:44:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-14T00:28:56Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5ae9dac8-a305-4f45-8149-fa8770de83f5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: krose.org; dkim=none (message not signed) header.d=none;krose.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.88.234] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b669ea15-e609-43f6-30e6-08d83feb40bd x-ms-traffictypediagnostic: MN2PR00MB0878: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cpDtXRWz6mB2XLOLZT4pUmxtLx8MGMK0h+++WNtyCqV08iWfGuKh4ZGWX2FuRN1TaWNfDDU9TTgQ3HkqGtaG6CYbB4DmjyU9hO9EQv5dzp1Lh6K6v+13Kug8tJgg96aNySDmo3imbYGR7xE4BH5s41lRuOVdK6t9VteTIqqN3fNEQdXD8KaO6rf+bHgrGTiixtJOaijz6vaP5Rdn2tHZuHBLlLoNF8Pcua7KpkwGiCaDvheqB6zgm+o91roFmVPLVR/4NkNH+i3xpKLVqOKWHS86cCro8Je9cKn64vgEw2sfmODmpD1upnTNXo3/MpzIuyTl1DXq6IINuds26udBNd9ie8NUtYeoddEhWw3+5uo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(346002)(136003)(366004)(396003)(83380400001)(186003)(6506007)(54906003)(53546011)(966005)(86362001)(26005)(8676002)(110136005)(71200400001)(166002)(478600001)(7696005)(10290500003)(316002)(8990500004)(33656002)(82960400001)(76116006)(66446008)(66556008)(66946007)(66476007)(64756008)(52536014)(82950400001)(2906002)(5660300002)(9686003)(55016002)(8936002)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: GXjoI7VzXnfDN1TIWIrhONg7PAxHkFcAD7EaqG23uO2Hfv52a2lhQEjckGBtjMVmFRbZY87YIaLHb08XQUUFun6Jj/H0hdwKiau3u4RwgCKLlcr25+7/4Q8p+He6pfxxzasVmk5D9H/KyqH0ibOk/ZhfDQ/VVQSeLuvKcJ8jnl2m7Lnm7ee+02GpBYmyBprv25KEusBy8kWxlZmy6kMevMnZMLy8ptNUkjDZG6fh7BlLMc7lYM14FyqbtKTpBY/sZ6EN89oghGE5YOptL66fDih9Ogx34SJB0cflpIb/TOgZ2LHlCCvfTQcXTVeMKNO4inNX+1hCSBwl1F9iK4Cn+P0iaqRCljvVBVb4SDWCm9JFwjod1y7OYbnESs7WFUvweosTLqT2n773sy2K2u6gmfCMrG6ojw/DjpoEv2rlxjXL3Yuv395iC31GIs5mF+LlQL2Vwy4YttFJlEEJroeMZqJvk8BBEwTiWA/yE1TCngknAT8kN/x+85ux+V6PaQT3+0AE21EFRgDaDXFCIsxmoPDhQLKAxB8ewJp0KyLRPiD6l1qGAiRkl/+9lbg4EuN2LOFkWsSezw0mEg4IHbZRMBPuddGLQZQGQF0DlurcBW1cZySgUT6gp8fDAzpSBQb9Fnhx79RZwkYxdZb+z7PrbA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB06860E2D4F9B897F47CB76C5F5401MN2PR00MB0686namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b669ea15-e609-43f6-30e6-08d83feb40bd X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 00:44:50.8223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ehQizczDOTFqtMBSgjwtyc8OIz0aQelZHAhE7nCMRstkZpd0cvkt358SDgaR98sRXtlMYN79pJwut0XUryWhcA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0878 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-cbor-date-tag-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 00:45:01 -0000 --_000_MN2PR00MB06860E2D4F9B897F47CB76C5F5401MN2PR00MB0686namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIHRob3VnaHRmdWwgcmV2aWV3LCBLeWxlLiAgTXkgcmVwbGllcyB0byB5 b3VyIGNvbW1lbnRzIGFyZSBpbmxpbmUuLi4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBLeWxlIFJvc2UgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPg0K U2VudDogTW9uZGF5LCBBdWd1c3QgMTAsIDIwMjAgMTE6NDggQU0NClRvOiBzZWNkaXJAaWV0Zi5v cmcNCkNjOiBkcmFmdC1pZXRmLWNib3ItZGF0ZS10YWcuYWxsQGlldGYub3JnOyBsYXN0LWNhbGxA aWV0Zi5vcmc7IGNib3JAaWV0Zi5vcmcNClN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wNQ0KDQoNCg0KUmV2aWV3ZXI6IEt5bGUgUm9z ZQ0KDQpSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KDQoNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVm Zm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUg SUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5l Zml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4NCg0KRG9jdW1lbnQgZWRpdG9ycyBh bmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90 aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KDQoNClRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgd2l0 aCBuaXRzLiBJIHNlZSBubyBpc3N1ZXMgb2YgaW50ZXJlc3QgdG8gdGhlIHNlY3VyaXR5IGRpcmVj dG9yYXRlLg0KDQoNCg0KSSBkbyBoYXZlIHRocmVlIGNvbW1lbnRzLCBob3dldmVyOg0KDQoNCg0K KiBJbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiwgYSBiZXR0ZXIgZXhhbXBs ZSBtaWdodCBiZSB0aGUgcG90ZW50aWFsIGluYXBwcm9wcmlhdGVuZXNzIG9mIHVzaW5nIGFuIGlt cHJlY2lzZSBtZWNoYW5pc20gZm9yIHNwZWNpZnlpbmcgY2VydGlmaWNhdGUgZXhwaXJhdGlvbi4N Cg0KDQoNCkknbGwgcGxhbiB0byBhZGQgdGhpcyBleGFtcGxlIHdoZW4gYWRkcmVzc2luZyBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCg0KDQoqIEl0J3Mgbm90IGNsZWFyIGhvdyB0aGlzIGlz IGludGVuZGVkIHRvIHdvcmsgZm9yIGRhdGVzIHByaW9yIHRvIHRoZSBzdGFydCBvZiB0aGUgR3Jl Z29yaWFuIGNhbGVuZGFyIGluIDE1ODIuIFdoYXQgZG8gbmVnYXRpdmUgaW50ZWdlciB2YWx1ZXMg bWVhbiB3aGVuIHRoZXkgaW1wbHkgYSBkYXRlIGJlZm9yZSAxNS1PY3QtMTU4Mj8gSXMgdGhlIEdy ZWdvcmlhbiBjYWxlbmRhciBkZWZpbmVkIGZvciBhbGwgdGltZT8gSW4gYSBicmllZiBpbnZlc3Rp Z2F0aW9uLCBJJ3ZlIGJlZW4gdW5hYmxlIHRvIGZpbmQgdGhlIGFuc3dlciB0byB0aGlzLg0KDQoN Cg0KU2VlIHRoZSBzZWN0aW9uIGluIHRoZSBJbnRyb2R1Y3Rpb24gb24gdGhlIHJlbGF0aW9uc2hp cCB0byB0aGUgTW9kaWZpZWQgSnVsaWFuIERhdGUgdmFsdWUgYW5kIHRoZW4gc2VlIGh0dHBzOi8v Y29yZTIuZ3NmYy5uYXNhLmdvdi90aW1lLyBmb3IgdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGUgTW9k aWZpZWQgSnVsaWFuIERhdGUgdG8gdGhlIEp1bGlhbiBEYXRlLCBhIHRpbWVzY2FsZSBkZWZpbmVk IGJ5IHRoZSBTbWl0aHNvbmlhbiBBc3Ryb25vbWljYWwgT2JzZXJ2YXRvcnkgYmVnaW5uaW5nIGF0 IG5vb24gMSBKYW51YXJ5IDQ3MTMgQi5DLiAgVGhhdCBzZWVtcyB0byBnbyBmYXIgYmFjayBlbm91 Z2ggZm9yIG1vc3QgcHJhY3RpY2FsIHB1cnBvc2VzLg0KDQoNCg0KSW50ZXJlc3RpbmdseSwgYWNj b3JkaW5nIHRvIGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0p1bGlhbl9kYXk6DQoNCuKA nFRoZSBNb2RpZmllZCBKdWxpYW4gRGF0ZSAoTUpEKSB3YXMgaW50cm9kdWNlZCBieSB0aGUgU21p dGhzb25pYW4gQXN0cm9waHlzaWNhbCBPYnNlcnZhdG9yeSBpbiAxOTU3IHRvIHJlY29yZCB0aGUg b3JiaXQgb2YgU3B1dG5payB2aWEgYW4gSUJNIDcwNCAoMzYtYml0IG1hY2hpbmUpIGFuZCB1c2lu ZyBvbmx5IDE4IGJpdHMgdW50aWwgQXVndXN0IDcsIDI1NzYuIE1KRCBpcyB0aGUgZXBvY2ggb2Yg VkFYL1ZNUyBhbmQgaXRzIHN1Y2Nlc3NvciBPcGVuVk1TLCB1c2luZyA2My1iaXQgZGF0ZS90aW1l LCB3aGljaCBhbGxvd3MgdGltZXMgdG8gYmUgc3RvcmVkIHVwIHRvIEp1bHkgMzEsIDMxMDg2LCAw Mjo0ODowNS40Ny5bMThdIFRoZSBNSkQgaGFzIGEgc3RhcnRpbmcgcG9pbnQgb2YgbWlkbmlnaHQg b24gTm92ZW1iZXIgMTcsIDE4NTggYW5kIGlzIGNvbXB1dGVkIGJ5IE1KRCA9IEpEIC0gMjQwMDAw MC41LuKAnQ0KDQoNCg0KKiBJbiBhIHZlcnkgZ3Jvc3Mgc2Vuc2UsIHRoaXMgc3BlY2lmaWNhdGlv biAqaXMqIGFjdHVhbGx5IHRpZWQgdG8gdGhlIHByZXZhaWxpbmcgdGltZXNjYWxlLCBsZWFwIHNl Y29uZHMgYW5kIGFsbDogaWYgdGhlIHdob2xlIHdvcmxkIHdlcmUgdG8gdHJhbnNpdGlvbiBmcm9t IFVUQyB0byBUQUkgYW5kIHN0b3AgYWRkaW5nIGxlYXAgc2Vjb25kcywgcHJlc3VtYWJseSBpbXBs ZW1lbnRhdGlvbnMgd291bGQgY29udGludWUgdG8gZ2VuZXJhdGUgZGF0ZXMgZm9yIHRoaXMgc3Bl Y2lmaWNhdGlvbiBieSB0cnVuY2F0aW5nIHRoZSBsb2NhbCB0aW1lc3RhbXAgdG8gdGhlIGRhdGUs IHdoaWNoIHdvdWxkIGNhdXNlIGl0IHRvIGRyaWZ0IGFsb25nIHdpdGggVEFJIGF3YXkgZnJvbSBV VEMgb3ZlciB0aW1lLiBUaGVyZSB3b3VsZG4ndCBiZSBhIGh1Z2UgcHJhY3RpY2FsIGVmZmVjdCBo ZXJlIGdpdmVuIGhvdyBsaXR0bGUgdGhleSBhcmUgZXhwZWN0ZWQgdG8gZGl2ZXJnZSBvdmVyIHRo ZSBmb3Jlc2VlYWJsZSBmdXR1cmUsIGJ1dCBpdCB3b3VsZCBtZWFuIHRoYXQgZGF0ZXMgZW5jb2Rl ZCBpbiB0aGlzIGZvcm1hdCB0b2RheSB3b3VsZCBub3QgY2FycnkgZW5vdWdoIGluZm9ybWF0aW9u IHRvIHByZWNpc2VseSBpbmRpY2F0ZSBhIGRhdGUgaW4gdGhlIGZhciBmdXR1cmUgZXZlbiBpZiB0 aGUgdGFyZ2V0IHRpbWVzY2FsZSB3ZXJlIHVuZGVyc3Rvb2QgdGhyb3VnaG91dCBzaW5jZSB0aGUg c291cmNlIHRpbWVzY2FsZSBpc24ndCBwYXJ0IG9mIHRoZSBlbmNvZGluZy4NCg0KDQoNCklmIGl0 4oCZcyBnb29kIGVub3VnaCBmb3IgdGhlIFNtaXRoc29uaWFuIEFzdHJvbm9taWNhbCBPYnNlcnZh dG9yeSAoYWxiZWl0LCB1dGlsaXppbmcgYSBkZWZpbmVkIGludGVnZXIgb2Zmc2V0KSwgaXTigJlz IGdvb2QgZW5vdWdoIGZvciBtZS4gOy0pICBUaW1la2VlcGluZyBpcyB1bHRpbWF0ZWx5IGEgaHVt YW4gY3VsdHVyYWwgZW5kZWF2b3IgYW5kIGl04oCZcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMg c3BlY2lmaWNhdGlvbiB0byBwcm9iZSBpdHMgbWFueSB2YXJpYXRpb25zIGFuZCBmb2libGVzLiAg VGhlIGVzc2VuY2Ugb2YgZGF0ZXMgaXMgdGhhdCBlYWNoIHRpbWUgdGhlIHdvcmxkIGdvZXMgcm91 bmQsIHRoZXNlIHZhbHVlcyBpbmNyZW1lbnQuICBUaGF0IHNhaWQsIGlmIHlvdSBoYXZlIHNwZWNp ZmljIHRleHQgeW914oCZZCBsaWtlIHRvIHNlZSBhZGRlZCwgSeKAmW0gb3BlbiB0byBpdC4NCg0K DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBCZXN0IHdpc2hlcywNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQoNClAuUy4gIEkgbmV2ZXIgZXhwZWN0ZWQgdGhh dCB3cml0aW5nIHRoaXMgdmVyeSBzaW1wbGUgc3BlY2lmaWNhdGlvbiB3b3VsZCByZXN1bHQgaW4g c3VjaCBpbnRlcmVzdGluZyBkaXNjdXNzaW9ucyBhYm91dCB0aW1la2VlcGluZyENCg0KDQo= --_000_MN2PR00MB06860E2D4F9B897F47CB76C5F5401MN2PR00MB0686namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQt d3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5UaGFua3MgZm9yIHlvdXIgdGhvdWdodGZ1bCByZXZpZXcsIEt5bGUuJm5i c3A7IE15IHJlcGxpZXMgdG8geW91ciBjb21tZW50cyBhcmUgaW5saW5lLi4uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTog S3lsZSBSb3NlIHZpYSBEYXRhdHJhY2tlciAmbHQ7bm9yZXBseUBpZXRmLm9yZyZndDsgPGJyPg0K U2VudDogTW9uZGF5LCBBdWd1c3QgMTAsIDIwMjAgMTE6NDggQU08YnI+DQpUbzogc2VjZGlyQGll dGYub3JnPGJyPg0KQ2M6IGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy5hbGxAaWV0Zi5vcmc7IGxh c3QtY2FsbEBpZXRmLm9yZzsgY2JvckBpZXRmLm9yZzxicj4NClN1YmplY3Q6IFNlY2RpciBsYXN0 IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wNTwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+UmV2aWV3ZXI6IEt5bGUgUm9zZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+UmV2aWV3IHJlc3VsdDogSGFzIE5pdHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJp dHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1l bnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4mbmJzcDsgVGhlc2UgY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEg ZGlyZWN0b3JzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RG9jdW1l bnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0 IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+VGhpcyBkb2N1bWVudCBpcyByZWFkeSB3aXRoIG5pdHMuIEkgc2VlIG5vIGlzc3Vl cyBvZiBpbnRlcmVzdCB0byB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkkgZG8gaGF2ZSB0aHJlZSBjb21tZW50cywgaG93ZXZlcjo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+KiBJbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg c2VjdGlvbiwgYSBiZXR0ZXIgZXhhbXBsZSBtaWdodCBiZSB0aGUgcG90ZW50aWFsIGluYXBwcm9w cmlhdGVuZXNzIG9mIHVzaW5nIGFuIGltcHJlY2lzZSBtZWNoYW5pc20gZm9yIHNwZWNpZnlpbmcg Y2VydGlmaWNhdGUgZXhwaXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JJ2xsIHBsYW4gdG8gYWRkIHRoaXMgZXhhbXBsZSB3aGVu IGFkZHJlc3Npbmcgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+KiBJdCdz IG5vdCBjbGVhciBob3cgdGhpcyBpcyBpbnRlbmRlZCB0byB3b3JrIGZvciBkYXRlcyBwcmlvciB0 byB0aGUgc3RhcnQgb2YgdGhlIEdyZWdvcmlhbiBjYWxlbmRhciBpbiAxNTgyLiBXaGF0IGRvIG5l Z2F0aXZlIGludGVnZXIgdmFsdWVzIG1lYW4gd2hlbiB0aGV5IGltcGx5IGEgZGF0ZSBiZWZvcmUg MTUtT2N0LTE1ODI/IElzIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIgZGVmaW5lZCBmb3IgYWxsIHRp bWU/DQogSW4gYSBicmllZiBpbnZlc3RpZ2F0aW9uLCBJJ3ZlIGJlZW4gdW5hYmxlIHRvIGZpbmQg dGhlIGFuc3dlciB0byB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlNlZSB0aGUgc2VjdGlvbiBpbiB0aGUgSW50cm9kdWN0aW9uIG9u IHRoZSByZWxhdGlvbnNoaXAgdG8gdGhlIE1vZGlmaWVkIEp1bGlhbiBEYXRlIHZhbHVlIGFuZCB0 aGVuIHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly9jb3JlMi5nc2ZjLm5hc2EuZ292L3RpbWUvIj5odHRw czovL2NvcmUyLmdzZmMubmFzYS5nb3YvdGltZS88L2E+IGZvciB0aGUgcmVsYXRpb25zaGlwIG9m IHRoZSBNb2RpZmllZCBKdWxpYW4gRGF0ZSB0byB0aGUgSnVsaWFuIERhdGUsIGEgdGltZXNjYWxl IGRlZmluZWQgYnkgdGhlIFNtaXRoc29uaWFuIEFzdHJvbm9taWNhbCBPYnNlcnZhdG9yeSBiZWdp bm5pbmcgYXQgbm9vbiAxIEphbnVhcnkgNDcxMyBCLkMuJm5ic3A7IFRoYXQNCiBzZWVtcyB0byBn byBmYXIgYmFjayBlbm91Z2ggZm9yIG1vc3QgcHJhY3RpY2FsIHB1cnBvc2VzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JbnRlcmVzdGluZ2x5LCBhY2NvcmRpbmcgdG8g PGEgaHJlZj0iaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvSnVsaWFuX2RheSI+DQpodHRw czovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9KdWxpYW5fZGF5PC9hPjo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7igJxUaGUgTW9kaWZpZWQgSnVsaWFuIERhdGUgKE1K RCkgd2FzIGludHJvZHVjZWQgYnkgdGhlIFNtaXRoc29uaWFuIEFzdHJvcGh5c2ljYWwgT2JzZXJ2 YXRvcnkgaW4gMTk1NyB0byByZWNvcmQgdGhlIG9yYml0IG9mIFNwdXRuaWsgdmlhIGFuIElCTSA3 MDQgKDM2LWJpdCBtYWNoaW5lKSBhbmQgdXNpbmcgb25seSAxOCBiaXRzDQogdW50aWwgQXVndXN0 IDcsIDI1NzYuIE1KRCBpcyB0aGUgZXBvY2ggb2YgVkFYL1ZNUyBhbmQgaXRzIHN1Y2Nlc3NvciBP cGVuVk1TLCB1c2luZyA2My1iaXQgZGF0ZS90aW1lLCB3aGljaCBhbGxvd3MgdGltZXMgdG8gYmUg c3RvcmVkIHVwIHRvIEp1bHkgMzEsIDMxMDg2LCAwMjo0ODowNS40Ny5bMThdIFRoZSBNSkQgaGFz IGEgc3RhcnRpbmcgcG9pbnQgb2YgbWlkbmlnaHQgb24gTm92ZW1iZXIgMTcsIDE4NTggYW5kIGlz IGNvbXB1dGVkIGJ5IE1KRA0KID0gSkQgLSAyNDAwMDAwLjUu4oCdPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4qIElu IGEgdmVyeSBncm9zcyBzZW5zZSwgdGhpcyBzcGVjaWZpY2F0aW9uICppcyogYWN0dWFsbHkgdGll ZCB0byB0aGUgcHJldmFpbGluZyB0aW1lc2NhbGUsIGxlYXAgc2Vjb25kcyBhbmQgYWxsOiBpZiB0 aGUgd2hvbGUgd29ybGQgd2VyZSB0byB0cmFuc2l0aW9uIGZyb20gVVRDIHRvIFRBSSBhbmQgc3Rv cCBhZGRpbmcgbGVhcCBzZWNvbmRzLCBwcmVzdW1hYmx5IGltcGxlbWVudGF0aW9ucyB3b3VsZCBj b250aW51ZQ0KIHRvIGdlbmVyYXRlIGRhdGVzIGZvciB0aGlzIHNwZWNpZmljYXRpb24gYnkgdHJ1 bmNhdGluZyB0aGUgbG9jYWwgdGltZXN0YW1wIHRvIHRoZSBkYXRlLCB3aGljaCB3b3VsZCBjYXVz ZSBpdCB0byBkcmlmdCBhbG9uZyB3aXRoIFRBSSBhd2F5IGZyb20gVVRDIG92ZXIgdGltZS4gVGhl cmUgd291bGRuJ3QgYmUgYSBodWdlIHByYWN0aWNhbCBlZmZlY3QgaGVyZSBnaXZlbiBob3cgbGl0 dGxlIHRoZXkgYXJlIGV4cGVjdGVkIHRvIGRpdmVyZ2Ugb3Zlcg0KIHRoZSBmb3Jlc2VlYWJsZSBm dXR1cmUsIGJ1dCBpdCB3b3VsZCBtZWFuIHRoYXQgZGF0ZXMgZW5jb2RlZCBpbiB0aGlzIGZvcm1h dCB0b2RheSB3b3VsZCBub3QgY2FycnkgZW5vdWdoIGluZm9ybWF0aW9uIHRvIHByZWNpc2VseSBp bmRpY2F0ZSBhIGRhdGUgaW4gdGhlIGZhciBmdXR1cmUgZXZlbiBpZiB0aGUgdGFyZ2V0IHRpbWVz Y2FsZSB3ZXJlIHVuZGVyc3Rvb2QgdGhyb3VnaG91dCBzaW5jZSB0aGUgc291cmNlIHRpbWVzY2Fs ZSBpc24ndCBwYXJ0DQogb2YgdGhlIGVuY29kaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklmIGl04oCZcyBnb29kIGVub3VnaCBmb3Ig dGhlIFNtaXRoc29uaWFuIEFzdHJvbm9taWNhbCBPYnNlcnZhdG9yeSAoYWxiZWl0LCB1dGlsaXpp bmcgYSBkZWZpbmVkIGludGVnZXIgb2Zmc2V0KSwgaXTigJlzIGdvb2QgZW5vdWdoIGZvciBtZS4g Oy0pICZuYnNwO1RpbWVrZWVwaW5nIGlzIHVsdGltYXRlbHkgYSBodW1hbiBjdWx0dXJhbCBlbmRl YXZvciBhbmQgaXTigJlzIGJleW9uZA0KIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24g dG8gcHJvYmUgaXRzIG1hbnkgdmFyaWF0aW9ucyBhbmQgZm9pYmxlcy4mbmJzcDsgVGhlIGVzc2Vu Y2Ugb2YgZGF0ZXMgaXMgdGhhdCBlYWNoIHRpbWUgdGhlIHdvcmxkIGdvZXMgcm91bmQsIHRoZXNl IHZhbHVlcyBpbmNyZW1lbnQuJm5ic3A7IFRoYXQgc2FpZCwgaWYgeW91IGhhdmUgc3BlY2lmaWMg dGV4dCB5b3XigJlkIGxpa2UgdG8gc2VlIGFkZGVkLCBJ4oCZbSBvcGVuIHRvIGl0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgQmVzdCB3aXNoZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UC5TLiZuYnNw OyBJIG5ldmVyIGV4cGVjdGVkIHRoYXQgd3JpdGluZyB0aGlzIHZlcnkgc2ltcGxlIHNwZWNpZmlj YXRpb24gd291bGQgcmVzdWx0IGluIHN1Y2ggaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbnMgYWJvdXQg dGltZWtlZXBpbmchPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR00MB06860E2D4F9B897F47CB76C5F5401MN2PR00MB0686namp_-- From nobody Tue Aug 18 06:43:04 2020 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 DBFE83A0B36; Tue, 18 Aug 2020 06:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeU6oDPuWB1Q; Tue, 18 Aug 2020 06:42:55 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1EE3A0ABB; Tue, 18 Aug 2020 06:42:50 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id D49A11B00257; Tue, 18 Aug 2020 16:42:47 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1597758167; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Lt+VWqKcgs+MuaxCzm0nZHFGbyyf+5hZ2RlM7R+EVk0=; b=IBdZkWC4/+Ro4DAxLRzcoJfrJomWo9BfsOkMrNdIwj3XakFIUOHT8LiBgxhfAwmXsbJsO4 /oGWNi0+UfC6ctRmcLCneJs3qwWRYpyyjH9orhNS2XFwUPcsvjK8jvXgTN4ohjgXgFm1k4 uoPp3IvcS0AQ7rtW6ybGgP5NK7QH20nR4X4zQf8VsWw9ZgQjzPCytxLmBWs6tN6gcpZVUa n5Ne0ML+hm5Pjs/bhFbquo/jRQAXY8yJSY63SWN+R3b/Ov1m6ffWSwjA1pXHk7a81aPJNs TfQW3f0gH5hXQ7bYfgvFiCiFhvLkwtKB4AzuLhLWEkTKkdCdTV98uUU3k1DgIw== Received: by fireball.acr.fi (Postfix, from userid 15204) id 803AA25C0EF9; Tue, 18 Aug 2020 16:42:47 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24379.56023.497287.414181@fireball.acr.fi> Date: Tue, 18 Aug 2020 16:42:47 +0300 From: Tero Kivinen To: Sandra Murphy Cc: draft-ietf-netconf-keystore.authors@ietf.org, netconf-chairs@ietf.org, secdir@ietf.org In-Reply-To: <18A977F3-E1D5-4016-B54A-5BEFD9453E31@tislabs.com> References: <18A977F3-E1D5-4016-B54A-5BEFD9453E31@tislabs.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1597758167; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Lt+VWqKcgs+MuaxCzm0nZHFGbyyf+5hZ2RlM7R+EVk0=; b=f1OUrr1HCXxa/8UPzPf+oHXv6WZTtP9w66TzWgBF+2yxQR1QcIWlXDFosna3EBOzExUQok VsQkm0rk/eYqeI8/PuKvoJT3jpIYQPLt3GPB/yQ8uNcSGwdWVbid1bmbUWuwWCz9okk4CT NDHRSNmA4j/umD62uolOztlVFfXnhd2jdf9YCWjW6onhWDujKk75C0wzIrru5xmIhTThLr CyWg90019v1NuSIYFKT0l/E0s92tgpxFSh2KKg14BDz47yAj1GF6sTeBOrRuECyHhDwCpI g8R01Z7G9jDgjwl5NVkP8oLg52lw6IFrdGwlCN0shfN+dx3qHXZ2/88iOMs2Og== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1597758167; a=rsa-sha256; cv=none; b=agN+KasVg2g2xaYFMtf5j8AFh0GmVNQ/sQKmRd9kCHPBLlKAGlvokNrxkgr7KX8YZEGpYi EmlxWogh2xPfoBxpKH5iNMhXidhOFlmd7I/NdsMvwQaYDlaNkJiS94wcorv6TzQary3mj8 QnlerOi8spVJsnBtXwoqIURs8rIOp1toFRkbelECTHF6kqSXvD+p/gMTxKVyNvGogE3hhz GO60rbopQTepQyOnNBoSDuJuzqwknckfSK2dCeDEptLpdBhHSO0Z8zIBIYBOHyzX90v5e7 jCsq1whZwYvDUQXjHG8XlcqdY1SEH4gITl/190iJOfDmN2+NlfWgVAj2uscUUQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [secdir] early secdir review of draft-ietf-netconf-keystore-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 13:43:02 -0000 Sandra Murphy writes: > And I missed the fact that Magnus did a review as well. Yes, it seems there was two review requests for the draft-ietf-netconf-system-keytchain, one for early review and another for last call review. I did not notice that there were two so I did assignments for both... -- kivinen@iki.fi From nobody Wed Aug 19 20:40:04 2020 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 4D83A3A10CA; Wed, 19 Aug 2020 20:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1597894705; bh=uEX7IVMJ2awIEVRhKaPbj/+c7pO7HNocoQ3nTaYyY8A=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=R+3lpYg1tELGbGMz2DbOOWTxagmMXiE2DuneYKUH+jGNZftrFPEc/kDAOhD5SaVLm OMj1VhIB5AkaJ+8rFqriUbiOABsFlvy31vRC89YR4KYphSvcj/jQbVIo5RM5ZzuPkz F3PqYYNssvcEl2PDpVXoW19wvyaGOm96vYOa2g68= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Aug 19 20:38:24 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AE93A10C1; Wed, 19 Aug 2020 20:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1597894704; bh=uEX7IVMJ2awIEVRhKaPbj/+c7pO7HNocoQ3nTaYyY8A=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=XYw++1s6VLG/kiXsY7fXDk6E1kmBNHVV/2nhD/bGEPWSGDTIAgszST7xgpJEVDunk ECAvS/8BKZwjOfiUysaU5bHtjJCaJri2KuiX6W79kA3Zsy2a2IlkGftWLJWOm7pwjj 1aiOnfmuvOYzR7aHkNCNfNwfZf/T76zkctU/Sctg= 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 C464D3A10C1 for ; Wed, 19 Aug 2020 20:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6PERRR6QP-Q for ; Wed, 19 Aug 2020 20:38:20 -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 1078A3A10B4 for ; Wed, 19 Aug 2020 20:38:19 -0700 (PDT) Received: from [112.102.243.76] (helo=[192.168.0.101]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k8bP6-0006m7-D0 for new-work@ietf.org; Thu, 20 Aug 2020 03:38:16 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Thu, 20 Aug 2020 11:38:09 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 19 Aug 2020 20:40:02 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web Real-Time Communications Working Group (until 2020-09-22) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 03:38:27 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBXZWIgUmVh bC1UaW1lIENvbW11bmljYXRpb25zIFdvcmtpbmcgCkdyb3VwOgogwqAgaHR0cHM6Ly93d3cudzMu b3JnLzIwMjAvMDgvcHJvcG9zZWQtd2VicnRjLWNoYXJ0ZXIuaHRtbAoKQXMgcGFydCBvZiBlbnN1 cmluZyB0aGF0IHRoZSBjb21tdW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0Ms IHRoaXMgZHJhZnQgY2hhcnRlciBpcyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0 ZWUgcmV2aWV3IHBlcmlvZC4KClczQyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDIw MjAtMDktMjIgb24gdGhlCnByb3Bvc2VkIGNoYXJ0ZXIuIFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRv CnB1YmxpYy1uZXctd29ya0B3My5vcmcsIHdoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAg aHR0cDovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3Ro ZXIgdGhhbiBjb21tZW50cyBzZW50IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5 CkNvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9u c2UgdG8KY29tbWVudHMuIElmIHlvdSB3b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2Ug Y29vcmRpbmF0ZQp5b3VyIGNvbW1lbnRzIHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVw cmVzZW50YXRpdmUuIEZvcgpleGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29t bWVudHMgdmlhIHRoaXMgbGlzdCBhbmQKaGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXBy ZXNlbnRhdGl2ZSByZWZlciB0byBpdCBmcm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21t ZW50cy4KCklmIHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBp bmZvcm1hdGlvbiwgcGxlYXNlCmNvbnRhY3QgRG9taW5pcXVlIEhhemFlbC1NYXNzaWV1eCA8ZG9t QHczLm9yZz4gYW5kCkNhcmluZSBCb3VybmV6IDxjYXJpbmVAdzMub3JnPiwgV2ViUlRDIFdHIFRl YW0gQ29udGFjdHMuCgpUaGFuayB5b3UsCgpYdWV5dWFuIEppYSwgVzNDIE1hcmtldGluZyAmIENv bW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5vcmcvQ29uc29ydGl1bS9NZW1iZXIvTGlz dAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdv cmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Thu Aug 20 08:04:40 2020 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 2227C3A10D6; Wed, 19 Aug 2020 20:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1597895424; bh=gKIsDK0bL5jhP12MBKzJFV/pUb998jN/nmgwbPcqVkU=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=xklf7WOBCFO1sH5ydMqWmTCBlYNRkuqm0ozWzDFodOETGmjke4mIwlO/884SAW3QU j6ISmEUZYknTtM+nYHWz0gF6Cun5i48Hn+F5Vlc2ztX/zY/X8LbQqWTt3/7X2QxWPj SYCBrRhXXp+puCJt/zNLYpz3PvQKhYRGbjR5mzFs= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Aug 19 20:50:23 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 735AB3A10CD; Wed, 19 Aug 2020 20:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1597895423; bh=gKIsDK0bL5jhP12MBKzJFV/pUb998jN/nmgwbPcqVkU=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=ooU0ISR/sxPi9OMmXsYBmMRg6E7hSB17A1FGdECZ1QoUOfibYkgoMvnAUiGGlhkve sse7neW7P9Ir07UR/ORQyQKb9mXqQS2P3Fsn5VM9//AbUD0WQ/HGkkcsXWkBcWqF2n uxu38J8rC4mHvBnJiOu7Jy2LdRFLTx5a9JDIp4So= 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 8ED773A10CD for ; Wed, 19 Aug 2020 20:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68Y0Tc0Bgsp1 for ; Wed, 19 Aug 2020 20:50:20 -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 AC2953A10C1 for ; Wed, 19 Aug 2020 20:50:20 -0700 (PDT) Received: from [112.102.243.76] (helo=[192.168.0.101]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k8bal-00072P-2a for new-work@ietf.org; Thu, 20 Aug 2020 03:50:19 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Thu, 20 Aug 2020 11:50:13 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 20 Aug 2020 08:04:39 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Chinese Web Interest Group (until 2020-09-17) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 03:50:26 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBDaGluZXNl IFdlYiBJbnRlcmVzdCBHcm91cDoKIMKgwqAgaHR0cHM6Ly93d3cudzMub3JnLzIwMjAvMDgvcHJv cG9zZWQtY2hpbmVzZS1pZy1jaGFydGVyLmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhhdCB0 aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRyYWZ0 IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJldmlldyBw ZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDIwLTA5LTE3IG9u IHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpwdWJsaWMtbmV3 LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgwqAgaHR0cDovL2xp c3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBj b21tZW50cyBzZW50IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRl ZSBSZXByZXNlbnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29t bWVudHMuIElmIHlvdSB3b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0 ZQp5b3VyIGNvbW1lbnRzIHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRp dmUuIEZvcgpleGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlh IHRoaXMgbGlzdCBhbmQKaGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2 ZSByZWZlciB0byBpdCBmcm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KCklm IHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZvcm1hdGlv biwgcGxlYXNlCmNvbnRhY3QgRnVxaWFvIFh1ZSwgQ2hpbmVzZSBXZWIgSUcgVGVhbSBDb250YWN0 LCBhdCA8eGZxQHczLm9yZz4uCgpUaGFuayB5b3UsCgpYdWV5dWFuIEppYSwgVzNDIE1hcmtldGlu ZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5vcmcvQ29uc29ydGl1bS9NZW1i ZXIvTGlzdAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K bmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Thu Aug 20 17:09:21 2020 Return-Path: <010001740e58ed69-9189c088-85d3-4198-a533-37474ad88521-000000@amazonses.watsen.net> 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 12A5D3A0F62; Thu, 20 Aug 2020 17:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 Fz81PllUhIgh; Thu, 20 Aug 2020 17:09:04 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D70D3A081F; Thu, 20 Aug 2020 17:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1597968543; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=vE0wq4x88BgA94VMrRzWX7VH4eX8cz84PSEp9YccyEo=; b=lAEQazD1t5wgIOnh3hERl73V0bWUNKG4ifAk/leG5//Z2qiYzXHZRJa3n/LrZVX9 jh0c31obblyMzkLLQcZRqzQVK/537gzuX4pqqsJ4/VhSAcn+X2KncKauUv7EBKhtpZy 4nsRXs2TyTl2CSnYBPfD/76HKgfGOtd6GITtRPwQ= From: Kent Watsen Message-ID: <010001740e58ed69-9189c088-85d3-4198-a533-37474ad88521-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0348A326-1A9C-4C92-A178-9883E263A74F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 21 Aug 2020 00:09:03 +0000 In-Reply-To: Cc: secdir@ietf.org, "netconf@ietf.org" To: Sandra Murphy References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.21-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [secdir] early secdir review of draft-ietf-netconf-keystore-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 00:09:11 -0000 --Apple-Mail=_0348A326-1A9C-4C92-A178-9883E263A74F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [+netconf (for visibility) and -keystore.authors (since its just me)] Hi Sandy, This is a massive review. Thank you for that, but it demands a massive = response=E2=80=A6I hope you=E2=80=99re ready for it ;) Before jumping in, I want to clarify something that I=E2=80=99ll also = make a point to add to the Introduction section, which is that the = ietf-keystore YANG module defines a configuration model supporting = existing practices; it does not intend to define new ways for doing = things. For instance, the sections regarding built-in keys, hidden = keys, key-encryption keys, and master keys all attempt to support = existing practices. The point being that, in thinking about what these = sections are saying, trust that this draft isn=E2=80=99t defining new = behavior, and folk's experience with systems is the best guide. Also, note that I did update Section 4 (Encrypting Keys in = Configuration) per Magnus=E2=80=99s review. That update was sent to the = SecDir list on the 10th (with GitHub commit here [1]). While the = section was effectively entirely rewritten, the update essentially = accomplishes just one thing, which is the swap a couple terms as = follows: r/root key/master key/ and r/shared root key/key encryption = key/. Your review precedes this update, but my responses below will, = when appropriate, reflect the current terms. [1] = https://github.com/netconf-wg/keystore/commit/5b3b9f3db0d6b7027ddf5f0e983a= b958e8802251 = PS: I just updated all the drafts with the updates from this email. The = bad news is that the Datatracker is still using the *previous* draft = version for hyperlinks, so be sure to manually increment whenever = opening a referenced document. Thanks, Kent > On Aug 12, 2020, at 9:10 AM, Sandra Murphy wrote: >=20 > This is a requested SECDIR early review of = draft-ietf-netconf-keystore-19, not an IETF Last Call review. >=20 > I have reviewed this document as an early review assigned by the = security directorate, as part of the directorate's ongoing effort to = review documents headed eventually to the IESG. Document editors and WG = chairs should treat these comments just like any other comments. >=20 > I am a neophyte at Yang so any comments I make here should be = understood with that in mind. (The recent mpls and netconf discussion = of the MPLS module reuse of an RPC and the difference between = "destination address" and "local label" have further impressed upon me = just how much I do not know about YANG.) >=20 > Outline of this review is: >=20 > News of draft status > Summary of the draft > General and issue comments > Page-by-page comments and nits >=20 >=20 > News of draft status: > --------------------- >=20 > This document was in WGLC when assigned and it appears that the WGLC = has not yet been decided. >=20 > In the netconf session at IETF108, the wg discussed the need for a raw = password feature, which might end up as a new grouping being added to = the draft-ietf-netconf-crypto-types and therefore might induce changes = to this draft as well. True, it was discussed @108, but that change in crypto-types will not = affect this draft (however, it will affect the tcp-client-server, = ssh-client-server, and http-client-server drafts) > Summary of the draft: > --------------------- >=20 > The draft abstract says: > This document defines a YANG 1.1 module called "ietf-keystore" that > enables centralized configuration of both symmetric and asymmetric > keys. >=20 > Keys may be symmetric or asymmetric, and maybe be of types = "cleartext", "hidden" (as in a TPM), or "encrypted". Keys can be = configured locally (which means within the data model) or as a reference = to a keystore item. One server might have multiple keystores in use at = any one time. >=20 > The document defines groupings that might prove useful for other YANG = modules that import this one. >=20 > The document describes the data model for the keystore and provides = many examples. The descriptions of the data model and examples are = presented in different modes as you read through the document, in tree = diagrams, XML, and text that (surely?) is YANG (I think). I believe the = YANG text is authoritative. True, the YANG module in Section 2.3 is the raison d=E2=80=99=C3=AAtre = for the draft. > For other readers, here's the sequence of description modes. >=20 > Section 2.1 Mostly tree diagram descriptions of the groupings defined = in this document. >=20 > Section 2.2.1-2.2.2 Examples (Keystore Instance and Cert Expiration) = given in XML. >=20 > Section 2.2.3 A module, containing those groupings of Section 2.1 = whose titles' prefixes are "local-or-keystore-", is described in what I = believe would be called YANG (p16-18) and then in a tree diagram = (p19-23). >=20 > Section 2.3 This section describes what I believe to be the normative = Yang module text. Yes, the YANG module in 2.3 is the normative module text for the draft. >=20 > General and issue comments: > --------------------------- >=20 > This document is very well written. The examples were very helpful, = particularly to this reader who was unfamiliar with Yang. I can't = imagine the patience and care it took to keep so many descriptions in = close alignment. My secret is: 1) maintain all YANG modules and examples a stand-alone files. 2) each time building the draft (`make clean; make`), dynamically: a) validate all YANG modules b) validate all examples against the YANG modules c) generate all tree diagrams d) stitch tree-diagrams, examples, and YANG modules into an uber = xml2rfc file This way, everything stays connected and up-to-date. I takes effort to = set up, but it pays for itself over time (not only for the author, but = also for WG participants who might otherwise discover anomalies that = could=E2=80=99ve been caught). > The document describes two new typedefs: asymmetric-key-ref and = symmetric-key-ref. Those typedefs are never further explained. I = believe (based only on the string "ref" in the name and usage as = "keystore-reference") that these are intended to be references to named = items in other parts of the keystore which themselves contain keys. = (Sheesh it takes a lot of words!) And I hope/believe that the = asymmetric-key-ref is to a structure that contains a key-pair. Yes, you got it.=20 FWIW, Section 2.1.2 (Typedefs) says: "The leafrefs refer to symmetric = and asymmetric keys in the keystore. These typedefs are provided = primarily as an aid to downstream modules that import the = "ietf-keystore" module.=E2=80=9D Not good enough? > The text typically says "asymmetric key" without distinguishing = whether it is talking about the public key, the private key, or a = key-pair. Presumably "asymmetric key" means a key-pair and the = implementations of operations know from context which key in the = key-pair is needed. Yes, that is what is intended. Is that nomenclature okay or should = =E2=80=9Ckey-pair=E2=80=9D be postpended throughout? In contrast, note that when referring to asymmetric key halfs, the text = attempts to always call that it out, e.g., =E2=80=9Cthe public half of = the asymmetric key=E2=80=9D. > I am not familiar with the Yang system, so I wonder if there is any = mechanism in Yang's use to check if the assumptions of the data model = are followed. (1) If an asymmetric key is configured with a public key = and a private key that are not a key-pair, where is that caught? (2) If = an asymmetric key and an associated cert are configured, but the public = key part of the structure is not the public key mentioned in the cert, = where is that caught? (3) If the data model says that a component is an = asymmetric-key-ref, but the de-ref'd value is not an asymmetric key (key = type?), where is that caught, like maybe when the value is stored in the = keystore? (Do the questions even make sense?) Yes, the questions (now numbered 1-3) make sense. For #1) I just updated the =E2=80=9Cdescription=E2=80=9D for the " = asymmetric-key-pair-grouping=E2=80=9D in the "ietf-crypto-types=E2=80=9D = module (in draft-ietf-netconf-crypto-types): OLD: "A private key and its associated public key."; NEW: "A private key and its associated public key. Implementations SHOULD ensure that the two keys are a matching pair.=E2=80=9D [Note: =E2=80=9CSHOULD=E2=80=9D is used instead of =E2=80=9CMUST=E2=80=9D = because the fallback is to simply *trust* that the clients never = configure mismatched values.] For #2) Already the description statements for various groupings in the = "ietf-crypto-types=E2=80=9D module have suitable statements: grouping end-entity-cert-grouping { description "An end entity certificate, and a notification for when it is about to (or already has) expire. Implementations SHOULD assert that, where used, the end entity certificate contains the expected public key.=E2=80=9D; } grouping asymmetric-key-pair-with-cert-grouping { description "A private/public key pair and an associated certificate. Implementations SHOULD assert that certificates contain the matching public key.=E2=80=9D; } grouping asymmetric-key-pair-with-certs-grouping { description "A private/public key pair and associated certificates. Implementations SHOULD assert that certificates contain the matching public key.=E2=80=9D; } For #3) There are three parts to this one. =20 3a) First, when configuring a key into the Keystore, I made the = following adjustments: For "symmetric-key-grouping=E2=80=9D: OLD: description "Identifies the symmetric key's format.=E2=80=9D; NEW: description "Identifies the symmetric key's format. Implementations SHOULD ensure that incoming symmetric key value is encoded in the specified format.=E2=80=9D; For "public-key-grouping=E2=80=9D: OLD: description "Identifies the public key's format."; } NEW: description "Identifies the public key's format. Implementations SHOULD ensure that incoming public key value is encoded in the specified format."; } For asymmetric-key-pair-grouping: OLD: description "Identifies the private key's format."; } NEW: description "Identifies the private key's format. Implementations SHOULD ensure that incoming private key value is encoded in the specified format."; } 3b) Second, regarding if a format mismatch can occur, this is not = possible as, e.g., the =E2=80=9Ckey-format=E2=80=9D for the = symmetric-key (see below) uses an =E2=80=9Cidentityref" that indicates = that set values must derive from the "symmetric-key-format=E2=80=9D = (i.e., NOT either the =E2=80=9Cpublic-key-format=E2=80=9D or = =E2=80=9Cprivate-key-format=E2=80=9D identities): leaf key-format { nacm:default-deny-write; type identityref { base symmetric-key-format; } 3c) Third, regarding if the thing referenced is what its supposed to be, = note in the YANG module has this definition: typedef asymmetric-key-ref { type leafref { path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" + "/ks:name"; } Thus, if a configuration points to =E2=80=9Cfoo=E2=80=9D, but no = asymmetric key called =E2=80=9Cfoo=E2=80=9D exists, then a YANG = validation would fail when the configuration is attempted to be set. QUESTION: should these implementation-notes be *moved* into Security = Considerations? One one hand, there=E2=80=99s is best IETF-form but, = on the other hand, there is best YANG-form. =46rom both PoVs, I think = a case can be made but, if no one cares, I=E2=80=99ll leave it be. > Section 3 says > Built-in "encrypted" keys MAY be copied > into other parts of the configuration so long as they maintain their > reference to the other built-in key that encrypted them. >=20 > I could see that built-in keys should be encrypted by other built-in = keys (I don't see what other keys are available at the building-in time = to encrypt them, but proof by "I don't see" is unconvincing). Is that = required? I don't think the data model represents built-in keys as a = distinct type, so I'm not sure the data model could represent the = built-in-ness requirement. Could it ever be that a built-in key could = be encrypted by a non-built-in key? I.e., does something prevent it. =46rom a terminology perspective, equate =E2=80=9Cbuilt-in=E2=80=9D with = =E2=80=9Cgenerated by the manufacturer and/or in the device=E2=80=99s = factory default configuration". To the last question, no, a built-in key cannot be encrypted by a = non-builtin key. That would be putting the cart in front of the horse, = so to speak. But, to the crux of your question, that sentence simply acknowledging = what=E2=80=99s possible. For instance, imagine a device ships with a = *hidden* built-in key called =E2=80=9Cfoo=E2=80=9D and an encrypted = built-in key called =E2=80=9Cbar=E2=80=9D, where bar is encrypted by = foo. Presumably both foo and bar would appear in the Keystore in = and, if a user wanted to use bar as a KEK, they would copy = it into the exact same spot in (i.e., in Keystore, using the = same name, e.g., =E2=80=9Cbar"). This sentence acknowledges that the = key might possibly be renamed =E2=80=9Cbaz=E2=80=9D or possibly be = copied into a =E2=80=9Clocal definition=E2=80=9D somewhere (i.e., not in = Keystore at all). In such cases, the configured-key is still valid so = long as the base64 and the leafref pointing to =E2=80=9Cfoo=E2=80=9D = remain. It=E2=80=99s a corner case that=E2=80=99s unlikely to trigger = in practice, because why would you, though theoretically possible = without a technical reason for a constraint. Makes sense? =20 > Section 4 p34 says "built-in keys MUST be hidden". That really should = be mentioned in Section 3. As mentioned in an email I wrote on Thu (Aug 13th), I don=E2=80=99t = think this MUST is enforceable and so am dialing it back something akin = to a SHOULD or RECOMMENDED via this text: A MEK is commonly a globally-unique built-in (see ) asymmetric key for which the private key, due to its long = lifetime, is hidden=20 () and the=20 public key is contained in an identity certificate (e.g., = IDevID). > Section 3 and 4 about built-in keys and root keys and hidden keys: >=20 > Section 4 p34 says >=20 > The root key SHOULD be a hidden key, i.e., one whose private data has > no presence in or >=20 > and > Given the long lifetime of built-in > keys (see Section 3), built-in keys MUST be hidden. But this last part is no longer a =E2=80=9CMUST=E2=80=9D (see above) > and Section 3 p32 says >=20 > The key characteristic of the built-in keys is that they are provided > by the system, as opposed to configuration. As such, they are > present in . >=20 > So built-in keys must be hidden, which means they are candidates to be = root keys, but they are "present in operational". By the first = sentence, their private data is not in , so the = configuration must use the hidden-private-key or hidden-key key-type for = the secret parts. Yes > By the requirement that built-in keys must be hidden, servers that do = not support hidden keys can not use built-in keys. Correct? Not anymore, since it can=E2=80=99t be enforced. The better statement = might be: "it is highly RECOMMENDED that builtin keys are [permanently] = hidden and, if this is not possible, highly restricted access mechanisms = are used to limit the built-in key's secret data to only highly = authorized clients (e.g., an organization=E2=80=99s crypto officer)." > A hidden root key MAY be either a symmetric key or an asymmetric key. True. Asymmetric is the common case but its possible that a MEK could = be a symmetric key, such that *only* a, e.g., TPM, is able to = encrypt/decrypt certain keys (e.g., KEKs) > Does the same apply to built-in keys? The examples in Section 3 are = all asymmetric keys. Yes (see example in previous response) > Is using a built-in key as a root key advisable in operational = situations? Absolutely. This is commonly done and (I think) recommended by TCG. > Presumably if a root key is not a built-in key and not a hidden key, = then its secret data must be of cleartext-key type. Encrypting the root = key is not possible, there is no other single key available (or it would = be the root key). Has any consideration been given to dual root keys? = I could see that that would be too complex to manage. Your presumptions are correct. There certainly could be more than one = MEK (root key). This model doesn=E2=80=99t constrain that possibility = from being exposed to users. > Section 4.1 p35 >=20 > The use of the root key mentions encrypting with an asymmetric key, = but not signing with an asymmetric key. Are signing and other crypto = services not a part of the netconf view? Signing is using something a device might do to prove to a remote peer = that it originated some data. In the context of the Keystore, it=E2=80=99= s clearly desirable to configure encrypted keys but not clear there is a = need to configure signed keys. At least, I=E2=80=99m unaware of the use = case. Certainly any asymmetric key could be used to sign data, but the = API (i.e., RPCs) enabling that are currently outside the scope of this = document. > Section 4.2 p35 >=20 > Each time a new key is to be configured, it SHOULD be encrypted by > the root key. >=20 > Would it be good to discuss how to configure a root key? If the root = key is not a built-in key and there is no support for a hidden key, then = a cleartext key would be required, correct? An encrypted key would not = be possible because it would require a second key that would have to be = available in the keystore - which means that would be the root key. I added: "How to configure a MEK during the manufacturing process is outside the scope of this document.=E2=80=9D And: "It is highly RECOMMENDED that MEKs are built-in and hidden but, if this is not possible, MEKs highly restricted access mechanisms = SHOULD=20 be used to limit access to the MEK's secret data to only highly=20 authorized clients (e.g., an organization=E2=80=99s crypto = officer). In this case, it is RECOMMENDED that the MEK is not built-in and hence is, effectively, just like a KEK.=E2=80=9D > Section 4.3 p35 Heads up: this is the section that was rewritten based on Magnus=E2=80=99s= review. The =E2=80=9Cshared root key=E2=80=9D is now called =E2=80=9Ckey= encryption key=E2=80=9D (KEK) and the =E2=80=9Croot key=E2=80=9D is now = =E2=80=9Cmaster encryption key=E2=80=9D (MEK) in the -20 version I = shared as an attachment last week. =20 PS: Magnus suggests renaming =E2=80=9CMaster Encryption Key=E2=80=9D to = =E2=80=9CMaster Key=E2=80=9D; I haven=E2=80=99t done this yet hence why = I=E2=80=99m still using the MEK term=E2=80=A6 > This process for migrating a configuration to a new server would also = work for replacing the root key on a server without requiring = re-encrypting all the keystore's encrypted keys. (Mind you, I don't = know how a non-builtin, non-hidden root key is configured from a cold = start.) Yes. > The text calls the key a "shared root key" - but the use in this = process of migrating a configuration does not require that the key be = shared other than between the "first" and "second" servers. I don't see = that there's any reason to share the "shared root key" more widely; each = migration between two servers could use a different "shared root key". Agreed. > "This shared root key would only need to be known to an organization's = crypto officer." -- until it is decrypted in a server for use in = encrypting and decrypting local keys, right? I don't know how YANG = implementations hold the root keys that are constantly in use but = hopefully access is carefully controlled. To your question, right, only the crypto officer and then later the = device itself should ever know the key. Regarding the second part of your comment, please note that the YANG = model isn=E2=80=99t forcing any behavior. =46rom my previous comments = above, I think you see that the draft =E2=80=9Crecommends=E2=80=9D = certain behaviors but, otherwise, enables implementations do present an = interface reflecting a device=E2=80=99s internal behavior. > A key common to all servers in an operational environment has been = found to be unwise because an exposure at one server has a global = impact. The text on p 36 says "The crypto officer can then safely = handoff the encrypted shared key to other administrators responsible for = server installations, including migrations." but that should be taken as = a handoff as necessary at each occasion, not taken as a handoff to all = other servers jointly, at the same time. Agreed. I think that it understood that the shared KEK would be = encrypted for the minimal subset of devices=E2=80=A6presumably just a = single failover device but, perhaps, a set of devices constituting a = cluster. > Section 5.2 p38 >=20 > This section points to the NETCONF protocol's support for mutual = authentication, but in this particular case, I believe that the = mandatory support for confidentiality is very important and should be = mentioned, in particular for the configuration of cleartext keys. Please be aware that this section is following (roughly) the template = defined here: https://tools.ietf.org/html/rfc8407.html#section-3.7.1 = . This template = ware reviewed by previous Security Area ADs . FWIW, the first paragraph says =E2=80=9C=E2=80=A6 Both of these = protocols have mandatory-to-implement secure transport layers (e.g., = SSH, TLS) with mutual authentication.=E2=80=9D, so =E2=80=9Cconfidentialit= y isn=E2=80=99t completely unstated=E2=80=A6. What text would you like to see added here? > I had one puzzle I could never figure out - why the keystore-reference = for the grouping local-or-keystore-asymmetric-key-with-certs-grouping = (Sect 2.1.3.5) is an asymmetric-key-ref type. Other uses of = asymmetric-key-ref are consistent with it being a reference to a key = only, but here I expected the reference would be to a structure that = contains the key and its associated certs. The descriptions in the Sect = 2.3 Yang Module p29 says the grouping contains the cert and its keys. Good catch. Yes, there is some wonkiness here. (Continued in next = comment) > Is the asymmetric-key-ref in some way useable as both a reference to = an asymmetric key and an asymmetric key and its associated certs? Indeed. The reality is that the Keystore only supports the notion of = keys that may have associated certificates. In all cases, the = =E2=80=9Clocal=E2=80=9D definition is as described, but sometimes the = =E2=80=9Ckeystore=E2=80=9D definition is a bit off. =20 The only perfect* mapping is the = =E2=80=9Clocal-or-keystore-asymmetric-key-with-certs-grouping=E2=80=9D = grouping, as that is exactly what the Keystore has in it. =20 The "local-or-keystore-end-entity-cert-with-key-grouping=E2=80=9D isn't = that bad either, as it points to specific cert, which is under a = key=E2=80=A6the only wonkiness is that the key may have other certs = under it too, but it isn=E2=80=99t a big deal. =20 The "local-or-keystore-asymmetric-key-grouping=E2=80=9D is the worst = mapping because, while it does point to a key, the key may have certs = under it. The expectation is that this won=E2=80=99t be a problem in = context because the code is, presumably, only interested in the key (not = the certs), as that is exactly all the code would get if the =E2=80=9Cloca= l=E2=80=9D definition is used. > At first I thought the "associated certs" in the groupings were the = certificate chain certs - the subject cert, the issuer cert, etc. I am = not sure they are - might they be many certificates for the same public = key, perhaps for different algorithms? I think that should be = explained. Each =E2=80=9Ccertificate=E2=80=9D is actually the "end-entity-cert-cms" = CMS structure defined in the =E2=80=9Ccrypto-types=E2=80=9D draft. Each = CMS MAY contain a chain of certs for that end-entity =E2=80=9Ccertificate=E2= =80=9D, in quotes because the =E2=80=9Ccertificate=E2=80=9D can also = include associated issuer certs, as needed for the context. Therefore, that a key may have a multiplicity of associated certs (i.e. = CMSs) is to support things such as: different algorithms, different = Subject/SAN, different Issuers, etc. Makes sense. Happy to make things more clear, can you propose the text you=E2=80=99d = like to see? > Page-by-page comments and nits: > ------------------------------- >=20 > Section 1 p 3 >=20 > there are groupings that defined enabling a key to be either >=20 > Did you mean the past tense here? Or did you mean "define"? Fixed =E2=80=94> "define". > Section 1.1 p 4 >=20 > In the diagram, what is the meaning of the lines - what relationshiop = do they represent - e.g., "refers to", "uses", "augments", something = else? "The relationship between=E2=80=9D =E2=80=94> "The normative dependency = relationship between" > It looks like netconf-client-server has no relationship (whatever = "relationship" is) to http-client-server, restconf-client-sever has no = relationship to ssh-client-server, and http-client-server has no = relationship to keystore or truststore. Is that all correct? Yes. NETCONF doesn=E2=80=99t have an HTTP-based transport. RESTCONF = doesn=E2=80=99t have an SSH-based transport. HTTP may be =E2=80=9Cmixed-i= n=E2=80=9D with TLS to created a protocol stack, but doesn=E2=80=99t = itself depend on TLS. > Section 1.3 p 5 >=20 > This document in compliant with Network Management Datastore > Architecture (NMDA) [RFC8342]. >=20 > RFC8342 is listed in the informative section - what does it mean to be = compliant with an informative reference? r/in compliant/is compliant/ This text is via https://tools.ietf.org/html/rfc8407#section-3.5. It = means that the data model has been developed assuming that there exists = dedicated datastore that contains the =E2=80=9Coperational=E2= =80=9D value for the system as a superset of configured nodes. =20 >=20 > [Std-802.1AR-2009] certificate) are expected to appear in > >=20 > I did not catch that the term was part of R%FC8342, and = went looking for a reference. I found it in many places, like RFC6241. = For those just that unobservant, could you put a citation here to = RFC8342, which I think is the proper reference for that term. Note: = appears later, and a citation to RFC8342 is probably proper = there as well. Yes, I know, probably about as necessary as a reference = to "packet", but it would have spared me, maybe other non-Yang clueful = folk will be reading this also. Quite right - I added a =E2=80=9CTerminology=E2=80=9D section with = references for "=E2=80=9D and =E2=80=9C=E2=80=9D = (RFC 8342), as well as =E2=80=9Cclient" and =E2=80=9Cserver=E2=80=9D = (RFC 6241). > Section 2 p 5 >=20 > This section defines a YANG 1.1 [RFC7950] module that defines a > "keystore" >=20 > Should that be "ietf-keystore"? Or do you mean keystore in a general = sense, in which case I think the quote marks make it look like a name, = not a general sense. (I went looking for a definition of a "keystore", = but that could just be me.) Part of the issue is that the term =E2=80=9Ckeystore" isn=E2=80=99t = defined anywhere. I just added the following in the new = =E2=80=9CTerminology=E2=80=9D section: The term "keystore" is defined in this draft as a mechanism that intends safeguard secrets placed into it for protection. That said, the issue with the paragraph you cite is worse than you point = out, as it cites some but not all notable aspects about the = ietf-keystore module. I just rewrote that paragraph to a simpler = description of the subsections to come. OLD: This section defines a YANG 1.1 = module that defines a "keystore" and groupings supporting downstream modules to reference the keystore or have locally-defined = definitions. NEW: This section defines a YANG 1.1 = module called "ietf-keystore". A high-level overview of the module = is provided in . Examples illustatrating the = module's use=20 are provided in Examples. The = YANG module itself is defined in . > Section 2.1.1. p6 >=20 > The following diagram lists all the "feature" statements defined in >=20 > Everywhere beyond this page it says "tree diagram". RFC8340 is cited = in Section 2.1.3.1, but this is the first use (unless I'm wrong about = the "tree diagram"), so the citation should go here. >=20 > The following diagram lists the "typedef" statements defined in the > The following diagram lists all the "grouping" statements defined in >=20 > diagram -> "tree diagram" The thing that you don=E2=80=99t know is that those diagrams (plus = another that lists the =E2=80=9Cgroupings=E2=80=9D defined in the = document) are NOT RFC8340 tree diagrams, they are using a format I made = up that happens to look like the RFC 8340 diagrams. =20 I recommend the NETMOD WG consider an rfc8340-bis to define the new tree = diagram outputs for a list of features, a list of typedefs, and a list = of groupings. In the meanwhile, I updated this draft to explicitly state that = particular diagrams are not tree diagrams as follows: | The diagram above uses syntax that is similar to but not | defined in [RFC8340]. > Section 2.1.3.3 - 2.1.3.6: >=20 > " offer an option as to if an asymmetric key is defined" - personally, = I would say "as to whether". I don't know if the RFC-Editor (and rfc = style guide) care. Fixed =E2=80=94> replaced all "as to if=E2=80=9D strings to =E2=80=9Cfor = whether=E2=80=9D - better? > "augmented in if, e.g.," - I actually thought this was an editing = error, until heard "augment in" used as a word in the IETF session. Web = search shows "augment in" is a term of art in netconf! But some uses = add a hyphen, which I think is a good idea. Added to the new =E2=80=9CTerminology=E2=80=9D section: =E2=80=9C=E2=80=9D=E2=80=9D The sentence fragments "augmented" and "augmented in" are used herein as = the verbified form of the "augment" statement defined in . =E2=80=9C"=E2=80=9D > reference a asymmetric key in an alternate location. >=20 > a asymmetric -> an asymmetric. A global change might be good, as well = as changing "an symmetric" to "a symmetric". Both fixed - thanks! > Section 2.1.3.4 >=20 > * For the "local-definition" option, the defintion uses the > "asymmetric-key-pair-grouping" grouping discussed in > Section 2.1.3.4 of [I-D.ietf-netconf-crypto-types]. >=20 > It looks to me like it is actually Section 2.1.4.4 of = [I-D.ietf-netconf-crypto-types]. Fixed! =E2=80=9C2.1.3.4=E2=80=9D -> =E2=80=9C2.1.4.5" This is one issue with the new =E2=80=9Crelref=E2=80=9D element in the = xml2rfc v3 syntax, a section number (e.g., =E2=80=9C2.1.3.4=E2=80=9D) = has to be hardcoded, there=E2=80=99s no option to use the =E2=80=9Canchor=E2= =80=9D value, so misalignments may occur unknowingly. > Section 2.1.3.7 p 11 >=20 > * The "keystore-grouping" grouping is defines a keystore instance as >=20 > "is defines" -> "defines" Fixed > * For asymmetric keys, each "asymmetric-key" uses the "asymmetric- > key-pair-with-certs-grouping" grouping discussed Section 2.1.3.10 > of [I-D.ietf-netconf-crypto-types]. >=20 > "discussed" -> "discussed in" Quite right, and I found another like it, fixed both. > Why do none of the asymmetric keys here use a grouping that is the key = only, like the ct:asymmetric-key-pair-grouping used in Sectoin 2.1.3.4 = of this document (discussed in 2.1.4.4 of = [I-D.ietf-netconf-crypto-types]). >=20 > | | +--rw encrypted-private-key > | | +--rw encrypted-by > | | | +--rw (encrypted-by-choice) > | | | +--:(symmetric-key-ref) > | | | | +--rw symmetric-key-ref? leafref > | | | +--:(asymmetric-key-ref) > | | | +--rw asymmetric-key-ref? leafref The section you quoted is for the "encrypted-private-key=E2=80=9D case = of a =E2=80=9Cchoice" statement called "private-key-type=E2=80=9D. This = =E2=80=9Cchoice=E2=80=9D also supports "cleartext-private-key=E2=80=9D, = that is the raw key only, is that what you mean? > Section 2.2.1 p 13 >=20 > The following example illustrates keys in . >=20 > Like I said before, maybe a citation of RFC8340 here. The new Terminology section defines =E2=80=9C" (and = =E2=80=9C) pointing to RFC8342 (NMDA). [PS: RFC 8340 is = for =E2=80=9CTree Diagrams=E2=80=9D] > Section 2.2.3 p 17 has the phrase "following non-normative ". Does = that belong here? Or because this is XML, it can not be confused to be = a normantive Yang module? It was/is a little bit of everything \_o_/ I created a new introduction: These examples assume the existence of an example module called "ex-keystore-usage=E2=80=9D having the namespace "http://example.com/ns/example-keystore-usage". And then changed the line as follows: OLD: The following non-normative module is defined to = illustrate these groupings: NEW: Following is the "ex-keystore-usage" module's YANG = definition:=20 > > > hidden-asymmetric-key ey-ref> > >=20 > The "hidden-asymmetric-key" key appears later in the asymmetric-keys = part of the keystore example on p15. I don't know how to prevent that = forward sort of reference for the readers, or if it is a problem. This is not a problem, as ordering doesn=E2=80=99t matter with = YANG-defined models. =20 > Section 2.2.3 p 18 >=20 > list end-entity-cert-with-key { > key name; > ... > uses ks:local-or-keystore-end-entity-cert-with-key-grouping; > description > "An end-entity certificate, and its associated private key, > that may be configured locally or be a reference to a > specific certificate (and its associated private key) in > the keystore."; >=20 > You can't rely on descriptions, but I see no explicit reference to the = private key in that end-entity cert grouping. That grouping is defined = in Section 2.1.3.6 p 9, and the keystore-reference is an = asymmetric-key-certificate-ref-grouping. That grouping has an = asymmetric-key-ref and a cert. The description above says "and its = associated private key". So is the asymmetric-key-ref a ref to the = private key or to a key pair? Fixed. =E2=80=9Cassociated private key=E2=80=9D -> "associated = asymmetric key" "An end-entity certificate and its associated asymmetric key, that may be configured locally or be a reference to another certificate (and its associated asymmetric key) in the keystore.=E2=80=9D; > Section 2.3 p 25 >=20 > typedef symmetric-key-ref { > type leafref { > path "/ks:keystore/ks:symmetric-keys/ks:symmetric-key" > + "/ks:name"; > } >=20 > Does default-deny-write belong here, or added each time an item is = defined of this type? No, because it is a typedef, and typedefs don=E2=80=99t support = extensions (search RFC 7950 for "typedef-stmt=E2=80=9D and = "extension-stmt=E2=80=9D). > Section 2.3 p 26 >=20 > case asymmetric-key-ref { > leaf asymmetric-key-ref { > type leafref { > path "/ks:keystore/ks:asymmetric-keys/" > + "ks:asymmetric-key/ks:name"; > } > description > "Identifies the asymmetric key used to encrypt this key."; > } >=20 > (a) "the asymmetric key used to encrypt" - the public key part is used = to encrypt, so is the asymmetric key just the public key or a key-pair = where the appropriate part of the key-pair is used according to context? OLD: "Identifies the asymmetric key used to encrypt this key."; NEW: "Identifies the asymmetric key whose public key encrypted the associated key."; > (b) "encrypt this key" - The "this key" part is appropriate if the = assymmetric-key-ref is being used in an encrypted-by-choice structure, = but there are lots of places in this text where the type is not in such = a structure. Is it the case that the uses always resolve to be = encrypting a key? Right, per above, now "the associated key=E2=80=9D and the = =E2=80=9Cdescription" statement for "encrypted-by-choice-grouping=E2=80=9D= now says: "A grouping that defines a choice that can be augmented into the 'encrypted-by' node presented by the 'symmetric-key-grouping' and the 'asymmetric-key-pair-grouping' groupings defined in RFC AAAA.=E2=80=9D; Indicating that the =E2=80=9Cassociated key=E2=80=9D is defined in those = two groupings. Good enough? > (c) "encrypt" - Is it always the case that asymmetric keys in the = keystore will be used to encrypt something? There is no expectation = that the asymmetric key-pair will be used to sign something? An asymmetric-key may be used to sign something, but this module has no = need to do that. For instance, the module doesn=E2=80=99t support the = notion of a =E2=80=9Csigned key=E2=80=9D (a la =E2=80=9Cencrypted = key=E2=80=9D), beyond its support for certificates. This doesn=E2=80=99t = preclude a consuming application from using an asymmetric key to sign = data if needed. > Section 2.3 p27 >=20 > description > "A grouping that expands to allow the symmetric key to be > either stored locally, within the using data model, or be > a reference to a symmetric key stored in the Keystore."; >=20 > The following is wordsmithing the description text, so a = very-nitty-nit. >=20 > ", or be" -> ", or" (the "be" is before the "either", don't need it) >=20 > A reader might be confused as to whether the disjunction was two = disjuncts or three. Fixed, in all four places where =E2=80=9Cor be=E2=80=9D was being used. > I might suggest using "i.e., within the using data store". Maybe also > move the "be" inside the "either or" for scoping > "A grouping that expands to allow the symmetric key to either > be stored locally, i.e., within the using data model, or be > a reference to a symmetric key stored in the Keystore."; Added =E2=80=9Ci.e.,=E2=80=9D > The groupings in this section have a descriptoin of the grouping, a = description of the key case and a description of the choice. I thought = it worked better to place the description of the choice closer to the = "choice local or keystore" rather than at the end. Moved all =E2=80=9Cchoice=E2=80=9D statement descriptions be before the = =E2=80=9Ccase=E2=80=9D statements. > And finally. Descriptions very frequently (always?) conclude with a = "." but they are very frequently not sentences, so the "." is not = necessary. I do not know if the RFC-Editor or the Style manual cares. The descriptions should be sentences. I found only two instances that = were missing an opening article (=E2=80=98A=E2=80=99), which gave the = appearance of not being a sentence=E2=80=A6but you said there were = =E2=80=9Cmany"? > Section 2.3 p 28 >=20 > grouping local-or-keystore-asymmetric-key-with-certs-grouping > ... > case keystore { > if-feature "keystore-supported"; > leaf keystore-reference { > type ks:asymmetric-key-ref; > description > "A reference to an asymmetric-key (and all of its > associated certificates) in the Keystore."; >=20 > An example of my puzzle about the = local-or-keystore-asymmetric-key-with-certs-grouping keystore-reference. = How are the certs to be found if the keystore-reference is to the = asymmetric key only? Or must the asymmetric-key-ref sometimes point = just to a key and sometimes to a key+certs, as needed? An asymmetric key "in the Keystore=E2=80=9D always allows certs to be = associated. I understand that this isn=E2=80=99t true for asymmetric = keys in general. > Section 3 p 31 >=20 > In some implementations, a server may support built-in keys. Built- > in built-in keys >=20 > "Built-in built-in" =3D> "Built-in" Fixed - redundancy removed. > Section 3 p 32 >=20 > In order for the built-in keys (and/or their associated built-in > certificates) to be referenced by configuration, the referenced keys > MUST first be copied into . The keys SHOULD be copied into > using the same "key" values, so that the server can bind > the references to the built-in entries. >=20 > Built-in "hidden" keys cannot be copied into other parts of the > configuration because their private parts are hidden, and therefore > impossible to replicate. >=20 > Section 4 p34 says built-in keys MUST be hidden. So they must be = copied to but they can't be copied? Huh? >=20 OLD: Built-in "hidden" keys cannot be copied into other parts of = the=20 configuration because their private parts are hidden, and = therefore impossible to replicate. Built-in "encrypted" keys MAY be = copied into other parts of the configuration so long as they maintain = their reference to the other built-in key that encrypted them. NEW: In addition to copying keys into the Keystore in = <running>,=20 cleartext and encrypted keys may be copied into other parts of=20= configuration, but they will lose their connection to having = been a built-in value. Note that hidden keys cannot be copied into other parts of the configuration because doing would lose the = key's connection to the built-in key, where the key's secret value = is=20 stored. Built-in "encrypted" keys MAY be copied into other = parts=20 of the configuration so long as the reference to the other = built-in=20 key that encrypted them is maintained. > The keys SHOULD be copied into > using the same "key" values, so that the server can bind > the references to the built-in entries. >=20 > The word "key" is overloaded in this document, like "The key = characteristic of the built-in keys" and "Key Words". Here, the = reference is surely to a required part of the "list" syntax, so no way = to use a different word. Maybe say 'the same list "key" values' or 'the = same values for the list "key" field/node'. Changed "Key characteristic" to "primary characteristic=E2=80=9D. "Key words=E2=80=9D is RFC 2119 language that cannot be altered. OLD: The keys SHOULD be copied into using the same "key" values, so that the server can = bind the references to the built-in entries. NEW: The keys SHOULD be copied into <running> using the same value for the list's "key"=20= substatement, so that the server can bind the references to = the built-in entries. > Built-in "encrypted" keys MAY be copied > into other parts of the configuration so long as they maintain their > reference to the other built-in key that encrypted them. >=20 > (a) Section 4 p34 says "built-in keys MUST be hidden", so is there a = way the hidden built-in keys can be encrypted keys? Under the hood, it is possible that a hidden key is encrypted, but if it = is, that information would be hidden too ;) > (b) So encrypted built-in keys must always be encrypted by other = built-in keys? Is there a way to represent that in the data model? (I = explored this before.) >=20 > MAY be a subset of the built-in keys define in = >=20 > "define" -> "defined" FIXED. > Only the referenced keys need to be copied; that is, the keys in > MAY be a subset of the built-in keys define in > . No keys may be added or changed (with exception to > associating additional certificates to a built-in key); that is, the > keys in MUST be a subset (which includes the whole of the > set) of the built-in keys define in . >=20 > I don't understatnd this part. First it says >=20 > "keys in MAY be a subset of the built-in keys define in = " >=20 > and then >=20 > "keys in MUST be a subset ... of the built-in keys define in = ". >=20 > That is inconsistent, is it intended? >=20 > Does the last sentence mean that if there are built-in keys, no other = keys may be added to the keystore? I don't know what is intended here. Removed the last part: i.e., =E2=80=9Cthe keys in MUST be a = subset (which includes the whole of the set) of the built-in keys define = in ." NEW: Only the referenced keys need to be copied; that is, the keys in <running> MAY be a subset, including the whole of the = set,=20 of the built-in keys defined in <operational>. =20 No new built-in keys may be added nor existing built-in = changed,=20 with exception to associating additional certificates to an=20 existing built-in key. > About "exception to" - I use "exeption to " and "exception for = ". I don't know if the RFC-Editor or the Style manual = cares. =E2=80=9Cexception to=E2=80=9D =E2=80=94> =E2=80=9Cexception for=E2=80=9D > Section 4.1 p34 >=20 > not support hidden keys, then the private data part of key MUST be=20 >=20 > "of key" -> "of the root key" This sentence no longer exists after the rewrite of the section = addressing the comment from Magnus. > Section 4.1 p35 >=20 > If the hidden root key is asymmetric, then the server > SHOULD provide APIs enabling other keys to be both generated and > encrypted by it >=20 > The "both generated and encrypted by it" sounds like keys are being = generated by the root key. I don't think that's generally true. = Section 4.2 separates key generation and key encryption steps. I think = this should be clearer. >=20 > (The mention of other crypto services moved to area before nits.) After addressing the comment from Magnus, the new text is: Implementations SHOULD provide an API that simultaneously = generates and encrypts a key (symmetric or asymmetric) using a KEK. = Thusly newly generated key cleartext values are never known to the administrators generating the keys. Better? > Section 4.2 p35 >=20 > (A discussion of issues, not nits, was moved to area before nits.) >=20 > Section 4.3 p35 >=20 > (A discussion of issues, not nits, was moved to area before nits.) =20 >=20 > Section 5.2 p38 >=20 > (A discussion of issues, not nits, was moved to area before nits.) Okay. > | Please be aware that this module uses the "key" and "private- > | key" nodes from the "ietf-crypto-types" module > | [I-D.ietf-netconf-crypto-types], where said nodes have the NACM > | extension "default-deny-all" set, thus preventing unrestricted > | read-access to the cleartext key values. >=20 > This text missed the change A.19 to add a "cleartext" prefix as in = ietf-netconf-crypto-types. The "cleartext" prefix is present in the = modules, tree-diagrams, XML, etc., but the references in text here did = not change. (Actually, I see several examples in the text in = ietf-netconf-crypto-types where the change was not made, e.g. p 9 says = '- The "key" node can encode any plain-text key value.' where the = preceding tree diagram has a node named "cleartext-key" and older = versions said "key".) I appreciate the discussion of the = default-deny-all in Section 3.5 p42 of ietf-netconf-crypto-types and I = think that a citation here would be warranted and useful. Fixed: prefixed =E2=80=9Ccleartext-=E2=80=9C NEW: Please be aware that this module uses the "cleartext-key" = and=20 "cleartext-private-key" nodes from the "ietf-crypto-types" = module=20 , where = said nodes have the NACM extension "default-deny-all" set, thus = preventing uncontrolled read-access to the cleartext key values. Also fixed a number of missing =E2=80=9Ccleartext-=E2=80=9C prefixes in = the crypto-types draft. > BTW. I don't know the NACM well but could it be said that the = default-deny-all prevents uncontrolled access, but does not necessarily = prevent unrestricted access, because a present but careless access = control might not actually restrict access? Fixed. See =E2=80=9Cuncontrolled=E2=80=9D the the NEW above. > Section 6.2 p 39 >=20 > "the the" -> "the" Fixed (in other documents also) - thanks! > Section 7.2 p40 >=20 > The list of Informative References includes: >=20 > [I-D.ietf-netconf-keystore] > Watsen, K., "A YANG Data Model for a Keystore", Work in > Progress, Internet-Draft, draft-ietf-netconf-keystore-17, > 20 May 2020, netconf-keystore-17>. >=20 > Isn't this a self reference to an earlier version? >=20 > Note: ID nits gives 11 warnings, but all are due to references to = older versions of existing drafts or to future versions not yet = published. The latter case seems to be wrong, and the warning usually = notes > (However, the state information for draft-ietf-netconf-keystore is = not > up-to-date. The last update was unsuccessful) >=20 > I have no idea what that means. The warnings are consistent, so may = be something to watch. Generally speaking, a document should not reference itself! The = self-reference in this document is coming from Section 1.1 (Relation to = other RFCs). The XML feeding this section is from a common snippet of = xml2rfc XML that is stitched into the same spot for each of the = documents in the collection of RFCs-to-be, per the "Relation to other = RFCs=E2=80=9D section. My choices are: 1) Copy-paste the common-text into each document and then customize it = by converting the self-reference to something like =E2=80=9C=E2=80=9D, and the remove the reference from the "Informative = References=E2=80=9D section. or 2) Add an RFC-editor note requesting that customization be made for each = document in the collection. Thoughts? K. >=20 > =E2=80=94Sandy >=20 --Apple-Mail=_0348A326-1A9C-4C92-A178-9883E263A74F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
            [+netconf = (for visibility) and -keystore.authors (since its just me)]


            Hi = Sandy,

            This is a = massive review.  Thank you for that, but it demands a massive = response=E2=80=A6I hope you=E2=80=99re ready for it  ;)

            Before jumping in, I = want to clarify something that I=E2=80=99ll also make a point to add to = the Introduction section, which is that the ietf-keystore YANG module = defines a configuration model supporting existing practices; it does not = intend to define new ways for doing things.  For instance, the = sections regarding built-in keys, hidden keys, key-encryption keys, and = master keys all attempt to support existing practices.  The point = being that, in thinking about what these sections are saying, trust that = this draft isn=E2=80=99t defining new behavior, and folk's experience = with systems is the best guide.

            Also, note that I did update Section 4 = (Encrypting Keys in Configuration) = per Magnus=E2=80=99s review.  That update was sent to the SecDir = list on the 10th (with GitHub commit here [1]).  While the section = was effectively entirely rewritten, the update essentially = accomplishes just one thing, which is the swap a couple terms as = follows: r/root key/master key/ and r/shared root = key/key encryption key/.  Your review precedes this = update, but my responses below will, when appropriate, reflect the current = terms.

            [1] https://github.com/netconf-wg/keystore/commit/5b3b9f3db0d6b7027= ddf5f0e983ab958e8802251


            PS: I just updated all the drafts with the updates from = this email.  The bad news is that the Datatracker is still = using the *previous* draft version for hyperlinks, so be sure to = manually increment whenever opening a referenced = document.

            Thanks,
            Kent



            On Aug 12, 2020, at 9:10 AM, Sandra Murphy = <sandy@tislabs.com> wrote:

            This = is a requested SECDIR early review of draft-ietf-netconf-keystore-19, = not an IETF Last Call review.

            I have = reviewed this document as an early review assigned by the security = directorate, as part of the directorate's ongoing effort to review = documents headed eventually to the IESG.  Document editors and WG = chairs should treat these comments just like any other comments.

            I am a neophyte at Yang so any comments I make = here should be understood with that in mind.  (The recent mpls and = netconf discussion of the MPLS module reuse of an RPC and the difference = between "destination address" and "local label" have further impressed = upon me just how much I do not know about YANG.)

            Outline of this review is:

            News = of draft status
            Summary of the draft
            General = and issue comments
            Page-by-page comments and nits


            News of draft status:
            ---------------------

            This = document was in WGLC when assigned and it appears that the WGLC has not = yet been decided.

            In the netconf session at = IETF108, the wg discussed the need for a raw password feature, which = might end up as a new grouping being added to the = draft-ietf-netconf-crypto-types and therefore might induce changes to = this draft as well.

            True, it was discussed @108, but that change in = crypto-types will not affect this draft (however, it will affect the = tcp-client-server, ssh-client-server, and http-client-server = drafts)


            Summary of the = draft:
            ---------------------

            The draft abstract says:
             This document = defines a YANG 1.1 module called "ietf-keystore" that
            =  enables centralized configuration of both symmetric and = asymmetric
             keys.

            Keys = may be symmetric or asymmetric, and maybe be of types "cleartext", = "hidden" (as in a TPM), or "encrypted". Keys can be configured locally = (which means within the data model) or as a reference to a keystore = item.  One server might have multiple keystores in use at any one = time.

            The document defines groupings that = might prove useful for other YANG modules that import this one.

            The document describes the data model for the = keystore and provides many examples.  The descriptions of the data = model and examples are presented in different modes as you read through = the document, in tree diagrams, XML, and text that (surely?) is YANG (I = think).  I believe the YANG text is authoritative.

            True, = the YANG module in Section 2.3 is the raison d=E2=80=99=C3=AAtre = for the draft.



            For other readers, here's the sequence of = description modes.

            Section 2.1 Mostly tree = diagram descriptions of the groupings defined in this document.

            Section 2.2.1-2.2.2 Examples (Keystore = Instance and Cert Expiration) given in XML.

            Section 2.2.3 A module, containing those groupings of Section = 2.1 whose titles' prefixes are "local-or-keystore-", is described in = what I believe would be called YANG (p16-18) and then in a tree diagram = (p19-23).

            Section 2.3 This section = describes what I believe to be the normative Yang module text.

            Yes, = the YANG module in 2.3 is the normative module text for the = draft.



            General and issue comments:
            ---------------------------

            This = document is very well written.  The examples were very helpful, = particularly to this reader who was unfamiliar with Yang.  I can't = imagine the patience and care it took to keep so many descriptions in = close alignment.

            My secret is:

            1)= maintain all YANG modules and examples a stand-alone = files.
            2) each time building the draft (`make clean; make`), = dynamically:
                  a) validate all YANG = modules
                  b) validate all examples against = the YANG modules
                  c) generate all tree = diagrams
                  d) stitch tree-diagrams, = examples, and YANG modules into an uber xml2rfc file

            This way, everything stays connected and = up-to-date.  I takes effort to set up, but it pays for itself over = time (not only for the author, but also for WG participants who might = otherwise discover anomalies that could=E2=80=99ve been = caught).


            The document describes two new typedefs: asymmetric-key-ref = and symmetric-key-ref.  Those typedefs are never further explained. =  I believe (based only on the string "ref" in the name and usage as = "keystore-reference") that these are intended to be references to named = items in other parts of the keystore which themselves contain keys. =  (Sheesh it takes a lot of words!) And I hope/believe that the = asymmetric-key-ref is to a structure that contains a key-pair.

            Yes, = you got it. 

            FWIW, Section = 2.1.2 (Typedefs) says: "The leafrefs refer to symmetric and asymmetric = keys in the keystore.  These typedefs are provided primarily as an = aid to downstream modules that import the "ietf-keystore" module.=E2=80=9D=   Not good enough?


            The text typically says "asymmetric key" without = distinguishing whether it is talking about the public key, the private = key, or a key-pair.  Presumably "asymmetric key" means a key-pair = and the implementations of operations know from context which key in the = key-pair is needed.

            Yes, that is what is intended.  Is that = nomenclature okay or should =E2=80=9Ckey-pair=E2=80=9D be postpended = throughout?

            In contrast, note that = when referring to asymmetric key halfs, the text attempts to always call = that it out, e.g., =E2=80=9Cthe public half of the asymmetric = key=E2=80=9D.


            I am not familiar with the Yang system, so I wonder if there = is any mechanism in Yang's use to check if the assumptions of the data = model are followed.  (1) If an asymmetric key is configured with a = public key and a private key that are not a key-pair, where is that = caught?  (2) If an asymmetric key and an associated cert are = configured, but the public key part of the structure is not the public = key mentioned in the cert, where is that caught?  (3) If the data = model says that a component is an asymmetric-key-ref, but the de-ref'd = value is not an asymmetric key (key type?), where is that caught, like = maybe when the value is stored in the keystore?  (Do the questions = even make sense?)

            Yes, the questions (now numbered 1-3) make = sense.

            For #1) I just updated the = =E2=80=9Cdescription=E2=80=9D for the = " asymmetric-key-pair-grouping=E2=80=9D in the = "ietf-crypto-types=E2=80=9D module (in = draft-ietf-netconf-crypto-types):

            OLD:
                  "A private key = and its associated public key.";

            NEW:
                  "A = private key and its associated public key.  Implementations
                   SHOULD ensure that the two keys = are a matching pair.=E2=80=9D

            [Note: =E2=80=9CSHOULD=E2=80=9D is used instead of = =E2=80=9CMUST=E2=80=9D because the fallback is to simply *trust* that = the clients never configure mismatched values.]

            For #2) Already the description statements for = various groupings in the "ietf-crypto-types=E2=80=9D module have = suitable statements:

              grouping end-entity-cert-grouping {
                description
                =   "An end entity certificate, and a notification = for when
                   it is about to = (or already has) expire.  Implementations
              =      SHOULD assert that, where used, the end = entity certificate
                  =  contains the expected public key.=E2=80=9D;
                = <snip/>
              = }

              grouping asymmetric-key-pair-with-cert-groupin= g {
                description
             =     "A private/public key pair and an = associated certificate.
                  =  Implementations SHOULD assert that certificates contain
                   the matching public = key.=E2=80=9D;
                = <snip/>
              = }

              grouping asymmetric-key-pair-with-certs= -grouping {
                description
                  "A private/public key pair and = associated certificates.
                  =  Implementations SHOULD assert that certificates contain
                   the matching public = key.=E2=80=9D;
                = <snip/>
              }


            For #3) There are three = parts to this one.  

            3a) First, = when configuring a key into the Keystore, I made the following = adjustments:

            For = "symmetric-key-grouping=E2=80=9D:
              OLD:
              =     description
                  =   "Identifies the symmetric key's format.=E2=80=9D;
            &n= bsp; NEW:
                  description
                    "Identifies the symmetric = key's format.  Implementations
                =      SHOULD ensure that incoming symmetric key = value is encoded
                     in = the specified format.=E2=80=9D;

            For = "public-key-grouping=E2=80=9D:
              OLD:
              =     description
                  =   "Identifies the public key's format.";
              =   }
              NEW:
                =   description
                  =   "Identifies the public key's format. Implementations = SHOULD
                     ensure that = incoming public key value is encoded in the
              =        specified format.";
              =   }

            For asymmetric-key-pair-grouping:
            &nb= sp; OLD:
                  description
                    "Identifies the private = key's format.";
                }
              = NEW:
                  description
              =       "Identifies the private key's = format.  Implementations SHOULD
                =      ensure that incoming private key value is = encoded in the
                    =  specified format.";
                }



            3b) Second, regarding if a format mismatch can = occur, this is not possible as, e.g., the =E2=80=9Ckey-format=E2=80=9D = for the symmetric-key (see below) uses an =E2=80=9Cidentityref" that = indicates that set values must derive from the "symmetric-key-format=E2=80=9D (i.e., NOT either = the =E2=80=9Cpublic-key-format=E2=80=9D = or =E2=80=9Cprivate-key-format=E2=80=9D = identities):

              =   leaf key-format {
                =   nacm:default-deny-write;
                =   type identityref {
                =     base symmetric-key-format;
              =     }



            3c) Third, regarding if = the thing referenced is what its supposed to be, note in the YANG module = has this definition:

              typedef asymmetric-key-ref {    type leafref {
                =   path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key"<= br class=3D"">         + "/ks:name";
                }

            Thus, if a configuration points to =E2=80=9Cfoo=E2=80= =9D, but no asymmetric key called =E2=80=9Cfoo=E2=80=9D exists, then a = YANG validation would fail when the configuration is attempted to be = set.


            QUESTION: should these implementation-notes be = *moved* into Security Considerations?    One one hand, = there=E2=80=99s is best IETF-form but, on the other hand, there is best = YANG-form.   =46rom both PoVs, I think a case can be made but, if = no one cares, I=E2=80=99ll leave it be.

            Section 3 says
            =             &n= bsp;           &nbs= p;  Built-in "encrypted" keys MAY be copied
            =  into other parts of the configuration so long as they maintain = their
             reference to the other built-in key that = encrypted them.

            I could see that built-in = keys should be encrypted by other built-in keys (I don't see what other = keys are available at the building-in time to encrypt them, but proof by = "I don't see" is unconvincing).  Is that required?  I don't = think the data model represents built-in keys as a distinct type, so I'm = not sure the data model could represent the built-in-ness requirement. =  Could it ever be that a built-in key could be encrypted by a = non-built-in key?  I.e., does something prevent it.

            =46rom = a terminology perspective, equate =E2=80=9Cbuilt-in=E2=80=9D with = =E2=80=9Cgenerated by the manufacturer and/or in the device=E2=80=99s = factory default configuration".

            To = the last question, no, a built-in key cannot be encrypted by a = non-builtin key.  That would be putting the cart in front of the = horse, so to speak.

            But, to the crux = of your question, that sentence simply acknowledging what=E2=80=99s = possible.  For instance, imagine a device ships with a *hidden* = built-in key called =E2=80=9Cfoo=E2=80=9D and an encrypted built-in key = called =E2=80=9Cbar=E2=80=9D, where bar is encrypted by foo.   = Presumably both foo and bar would appear in the Keystore in = <operational> and, if a user wanted to use bar as a KEK, they = would copy it into the exact same spot in <running> (i.e., in = Keystore, using the same name, e.g., =E2=80=9Cbar").  This sentence = acknowledges that the key might possibly be renamed =E2=80=9Cbaz=E2=80=9D = or possibly be copied into a =E2=80=9Clocal definition=E2=80=9D = somewhere (i.e., not in Keystore at all).  In such cases, the = configured-key is still valid so long as the base64 and the leafref = pointing to =E2=80=9Cfoo=E2=80=9D remain.  It=E2=80=99s a corner = case that=E2=80=99s unlikely to trigger in practice, because why would = you, though theoretically possible without a technical reason for a = constraint.  Makes sense?  



            Section 4 p34 = says "built-in keys MUST be hidden".  That really should be = mentioned in Section 3.

            As mentioned in an email I wrote on Thu (Aug = 13th), I don=E2=80=99t think this MUST is enforceable and so am dialing = it back something akin to a SHOULD or RECOMMENDED via this = text:

                      =   A MEK is commonly = a globally-unique built-in = (see <xref target=3D"built-ins"/>)
                      =   asymmetric key for which the private key, due to its = long lifetime, is hidden 
                    =   =   (<relref section=3D"2.1.4.5." target=3D"I-D.ietf-= netconf-crypto-types"/>) and the 
                =         public key is contained in an = identity certificate (e.g., IDevID).



            Section 3 and 4 about built-in keys and root = keys and hidden keys:

            Section 4 p34 says

             The root key SHOULD be a hidden key, = i.e., one whose private data has
             no presence in = <running> or <operational>

            and =             &n= bsp;           &nbs= p;         Given the long = lifetime of built-in
             keys (see Section 3), built-in = keys MUST be hidden.

            But this last part is no longer a =E2=80=9CMUST=E2=80=9D = (see above)

            and Section 3 p32 says

             The key characteristic of the built-in = keys is that they are provided
             by the system, as = opposed to configuration.  As such, they are
            =  present in <operational>.

            So = built-in keys must be hidden, which means they are candidates to be root = keys, but they are "present in operational".  By the first = sentence, their private data is not in <operational>, so the = configuration must use the hidden-private-key or hidden-key key-type for = the secret parts.

            Yes

            By the requirement that = built-in keys must be hidden, servers that do not support hidden keys = can not use built-in keys.  Correct?

            Not = anymore, since it can=E2=80=99t be enforced.  The better statement = might be: "it is highly RECOMMENDED that builtin keys are [permanently] = hidden and, if this is not possible, highly restricted access mechanisms = are used to limit the built-in key's secret data to only highly = authorized clients (e.g., an organization=E2=80=99s crypto = officer)."



             A hidden root key MAY be either a symmetric key or an = asymmetric key.

            True.   Asymmetric is the common case but its = possible that a MEK could be a symmetric key, such that *only* a, e.g., = TPM, is able to encrypt/decrypt certain keys (e.g., KEKs)


            Does the same apply to built-in keys? =  The examples in Section 3 are all asymmetric keys.

            Yes = (see example in previous response)


            Is using a built-in key as a root key advisable in = operational situations?

            Absolutely.  This is commonly done and (I = think) recommended by TCG.


            Presumably if a root key is not a built-in key and not a = hidden key, then its secret data must be of cleartext-key type. =  Encrypting the root key is not possible, there is no other single = key available (or it would be the root key).  Has any consideration = been given to dual root keys?  I could see that that would be too = complex to manage.

            Your presumptions are correct.   There = certainly could be more than one MEK (root key).  This model = doesn=E2=80=99t constrain that possibility from being exposed to = users.


            Section 4.1 = p35

            The use of the root key mentions = encrypting with an asymmetric key, but not signing with an asymmetric = key.  Are signing and other crypto services not a part of the = netconf view?

            Signing is using something a device might do to = prove to a remote peer that it originated some data.   In the = context of the Keystore, it=E2=80=99s clearly desirable to configure = encrypted keys but not clear there is a need to configure signed keys. =  At least, I=E2=80=99m unaware of the use case.   Certainly = any asymmetric key could be used to sign data, but the API (i.e., RPCs) = enabling that are currently outside the scope of this = document.



            Section 4.2 p35

             Each time = a new key is to be configured, it SHOULD be encrypted by
            =  the root key.

            Would it be good to = discuss how to configure a root key?  If the root key is not a = built-in key and there is no support for a hidden key, then a cleartext = key would be required, correct?  An encrypted key would not be = possible because it would require a second key that would have to be = available in the keystore - which means that would be the root key.

            I = added:

               "How = to configure a MEK during the manufacturing process is = outside
                 the scope of = this document.=E2=80=9D

            And:

              =    "It is highly RECOMMENDED that MEKs are built-in and = hidden but, if
                  this is not = possible, MEKs highly restricted access mechanisms SHOULD 
                  be used to limit access to the = MEK's secret data to only highly 
                =   authorized clients (e.g., an organization=E2=80=99s crypt= o officer).  In this
                =   case, it is RECOMMENDED that the MEK is not built-in = and hence is,
                  effectively, just like a = KEK.=E2=80=9D


            Section 4.3 p35

            Heads up: = this is the section that was rewritten based on Magnus=E2=80=99s review. =  The =E2=80=9Cshared root key=E2=80=9D is now called =E2=80=9Ckey = encryption key=E2=80=9D (KEK) and the =E2=80=9Croot key=E2=80=9D is now = =E2=80=9Cmaster encryption key=E2=80=9D (MEK) in the -20 version I = shared as an attachment last week.  

            PS: Magnus suggests renaming =E2=80=9CMaster = Encryption Key=E2=80=9D to =E2=80=9CMaster Key=E2=80=9D; I haven=E2=80=99t= done this yet hence why I=E2=80=99m still using the MEK = term=E2=80=A6


            This process for migrating a configuration to a new server = would also work for replacing the root key on a server without requiring = re-encrypting all the keystore's encrypted keys.  (Mind you, I = don't know how a non-builtin, non-hidden root key is configured from a = cold start.)

            Yes.


            The text calls the key a "shared root key" - but the use in = this process of migrating a configuration does not require that the key = be shared other than between the "first" and "second" servers.  I = don't see that there's any reason to share the "shared root key" more = widely; each migration between two servers could use a different "shared = root key".

            Agreed.


            "This shared root key would only need to be known to an = organization's crypto officer." -- until it is decrypted in a server for = use in encrypting and decrypting local keys, right?  I don't know = how YANG implementations hold the root keys that are constantly in use = but hopefully access is carefully controlled.

            To = your question, right, only the crypto officer and then later the device = itself should ever know the key.

            Regarding the second part of your comment, please = note that the YANG model isn=E2=80=99t forcing any behavior.  =46rom = my previous comments above, I think you see that the draft = =E2=80=9Crecommends=E2=80=9D certain behaviors but, otherwise, enables = implementations do present an interface reflecting a device=E2=80=99s = internal behavior.


            A key common to all servers in an operational environment has = been found to be unwise because an exposure at one server has a global = impact.  The text on p 36 says "The crypto officer can then safely = handoff the encrypted shared key to other administrators responsible for = server installations, including migrations." but that should be taken as = a handoff as necessary at each occasion, not taken as a handoff to all = other servers jointly, at the same time.

            Agreed. =  I think that it understood that the shared KEK would be encrypted = for the minimal subset of devices=E2=80=A6presumably just a single = failover device but, perhaps, a set of devices constituting a = cluster.


            Section 5.2 = p38

            This section points to the NETCONF = protocol's support for mutual authentication, but in this particular = case, I believe that the mandatory support for confidentiality is very = important and should be mentioned, in particular for the configuration = of cleartext keys.

            Please be aware that this section is following = (roughly) the template defined here: https://tools.ietf.org/html/rfc8407.html#section-3.7.1. =  This template ware reviewed by previous Security Area ADs = .

            FWIW, the first = paragraph says =E2=80=9C=E2=80=A6 Both of these protocols have = mandatory-to-implement secure transport layers (e.g., SSH, TLS) with = mutual authentication.=E2=80=9D, so =E2=80=9Cconfidentiality isn=E2=80=99t= completely unstated=E2=80=A6.

            What text would you like to see added = here?


            I had one puzzle I could never figure out - why the = keystore-reference for the grouping = local-or-keystore-asymmetric-key-with-certs-grouping (Sect 2.1.3.5) is = an asymmetric-key-ref type.  Other uses of asymmetric-key-ref are = consistent with it being a reference to a key only, but here I expected = the reference would be to a structure that contains the key and its = associated certs.  The descriptions in the Sect 2.3 Yang Module p29 = says the grouping contains the cert and its keys.

            Good = catch.  Yes, there is some wonkiness here.  (Continued in next = comment)

            Is the asymmetric-key-ref in = some way useable as both a reference to an asymmetric key and an = asymmetric key and its associated certs?

            Indeed. =  The reality is that the Keystore only supports the notion of keys = that may have associated certificates.  In all cases, the = =E2=80=9Clocal=E2=80=9D definition is as described, but sometimes the = =E2=80=9Ckeystore=E2=80=9D definition is a bit off. =   

            The only perfect* = mapping is the = =E2=80=9Clocal-or-keystore-asymmetric-key-with-certs-grouping=E2=80=9D = grouping, as that is exactly what the Keystore has in it. =  

            The "local-or-keystore-end-entity-cert-with-key-grouping=E2=80=9D = isn't that bad either, as it points to specific cert, which is under a = key=E2=80=A6the only wonkiness is that the key may have other certs = under it too, but it isn=E2=80=99t a big deal. =  

            The = "local-or-keystore-asymmetric-key-grouping=E2=80=9D is the worst mapping = because, while it does point to a key, the key may have certs under it. =  The expectation is that this won=E2=80=99t be a problem in = context because the code is, presumably, only interested in the key (not = the certs), as that is exactly all the code would get if = the =E2=80=9Clocal=E2=80=9D definition is = used.


            At first I thought the "associated certs" in the groupings = were the certificate chain certs - the subject cert, the issuer cert, = etc.  I am not sure they are - might they be many certificates for = the same public key, perhaps for different algorithms?  I think = that should be explained.

            Each =E2=80=9Ccertificate=E2=80=9D is actually the = "end-entity-cert-cms" CMS structure defined in the =E2=80=9Ccrypto-types=E2= =80=9D draft.  Each CMS MAY contain a chain of certs for that = end-entity =E2=80=9Ccertificate=E2=80=9D, in quotes because the = =E2=80=9Ccertificate=E2=80=9D can also include associated issuer certs, = as needed for the context.

            Therefore, = that a key may have a multiplicity of associated certs (i.e. CMSs) is to = support things such as: different algorithms, different Subject/SAN, = different Issuers, etc.  Makes sense.

            Happy to make things more clear, can you propose = the text you=E2=80=99d like to see?




            Page-by-page comments and nits:
            -------------------------------

            Section 1 p 3

             there are = groupings that defined enabling a key to be either

            Did you mean the past tense here?  Or did you mean = "define"?

            Fixed =E2=80=94> "define".

            Section 1.1 p 4

            In the diagram, = what is the meaning of the lines - what relationshiop do they represent = - e.g., "refers to", "uses", "augments", something else?

            "The = relationship between=E2=80=9D =E2=80=94> "The normative dependency = relationship between"


            It looks like = netconf-client-server has no relationship (whatever "relationship" is) = to http-client-server, restconf-client-sever has no relationship to = ssh-client-server, and http-client-server has no relationship to = keystore or truststore.  Is that all correct?

            Yes. =  NETCONF doesn=E2=80=99t have an HTTP-based transport. =  RESTCONF doesn=E2=80=99t have an SSH-based transport.  HTTP = may be =E2=80=9Cmixed-in=E2=80=9D with TLS to created a protocol stack, = but doesn=E2=80=99t itself depend on TLS.


            Section 1.3 p 5

            =  This document in compliant with Network Management Datastore
             Architecture (NMDA) [RFC8342].

            RFC8342 is listed in the informative section - what does it = mean to be compliant with an informative reference?

            r/in = compliant/is compliant/

            This text is = via https://tools.ietf.org/html/rfc8407#section-3.5.   = It means that the data model has been developed assuming that there = exists dedicated <operational> datastore that contains the = =E2=80=9Coperational=E2=80=9D value for the system as a superset of = configured nodes.  



             [Std-802.1AR-2009] certificate) are = expected to appear in
             <operational>

            I did not catch that the term = <operational> was part of R%FC8342, and went looking for a = reference.  I found it in many places, like RFC6241.  For = those just that unobservant, could you put a citation here to RFC8342, = which I think is the proper reference for that term.  Note: = <running> appears later, and a citation to RFC8342 is probably = proper there as well.  Yes, I know, probably about as necessary as = a reference to "packet", but it would have spared me, maybe other = non-Yang clueful folk will be reading this also.

            Quite = right - I added a =E2=80=9CTerminology=E2=80=9D section with references = for "<running>=E2=80=9D and =E2=80=9C<operational>=E2=80=9D= (RFC 8342), as well as =E2=80=9Cclient" and =E2=80=9Cserver=E2=80=9D = (RFC 6241).



            Section 2 p 5

             This = section defines a YANG 1.1 [RFC7950] module that defines a
            =  "keystore"

            Should that be = "ietf-keystore"?  Or do you mean keystore in a general sense, in = which case I think the quote marks make it look like a name, not a = general sense.  (I went looking for a definition of a "keystore", = but that could just be me.)

            Part = of the issue is that the term =E2=80=9Ckeystore" isn=E2=80=99t defined = anywhere. I just added the following in the new =E2=80=9CTerminology=E2=80= =9D section:

             The = term "keystore" is defined in this draft as = a mechanism
                     that = intends safeguard secrets placed into it for = protection.

            That said, the issue = with the paragraph you cite is worse than you point out, as it cites = some but not all notable aspects about the ietf-keystore module.  I = just rewrote that paragraph to a simpler description of the subsections = to come.

            OLD:
              =        This section defines a YANG = 1.1 <xref target=3D"RFC7950"/> module
                     that defines a "keystore" = and groupings supporting downstream
                =      modules to reference the keystore or = have locally-defined definitions.

            NEW:
                     This section = defines a YANG = 1.1 <xref target=3D"RFC7950"/> module
                      called "ietf-keystore".  A high-level = overview of the module is provided in
                =       <xref target=3D"overview"/>. = Examples illustatrating the module's use 
              =         are provided = in <xref target=3D"examples">Examples</xref>. The = YANG
                      module itself = is defined in <xref target=3D"keystore-yang-module"/>.





            Section 2.1.1. =  p6

             The following diagram lists = all the "feature" statements defined in

            Everywhere beyond this page it says "tree diagram". =  RFC8340 is cited in Section 2.1.3.1, but this is the first use = (unless I'm wrong about the "tree diagram"), so the citation should go = here.

             The following diagram lists = the "typedef" statements defined in the
             The = following diagram lists all the "grouping" statements defined in

            diagram -> "tree diagram"

            The = thing that you don=E2=80=99t know is that those diagrams (plus another = that lists the =E2=80=9Cgroupings=E2=80=9D defined in the document) are = NOT RFC8340 tree diagrams, they are using a format I made up that = happens to look like the RFC 8340 diagrams.  

            I recommend the NETMOD WG consider an rfc8340-bis = to define the new tree diagram outputs for a list of features, a list of = typedefs, and a list of groupings.

            In = the meanwhile, I updated this draft to explicitly state that particular = diagrams are not tree diagrams as follows:

                  |  The diagram = above uses syntax that is similar to but not
                =   |  defined in [RFC8340].



            Section 2.1.3.3 - 2.1.3.6:

            " = offer an option as to if an asymmetric key is defined" - personally, I = would say "as to whether".  I don't know if the RFC-Editor (and rfc = style guide) care.

            Fixed =E2=80=94> replaced all "as to if=E2=80=9D = strings to =E2=80=9Cfor whether=E2=80=9D - better?


            "augmented in if, e.g.," - I = actually thought this was an editing error, until heard "augment in" = used as a word in the IETF session.  Web search shows "augment in" = is a term of art in netconf!  But some uses add a hyphen, which I = think is a good idea.

            Added to the new =E2=80=9CTerminology=E2=80=9D = section:

            =E2=80=9C=E2=80=9D=E2=80=9D
            The sentence fragments "augmented" and "augmented in" = are used herein as the verbified form of the = "augment" statement defined in = <relref section=3D"7.17" target=3D"RFC7950"/>.
            =E2= =80=9C"=E2=80=9D



                reference a = asymmetric key in an alternate location.

            a = asymmetric -> an asymmetric.  A global change might be good, as = well as changing "an symmetric" to "a symmetric".

            Both fixed = - thanks!


            Section = 2.1.3.4

             *  For the = "local-definition" option, the defintion uses the
            =     "asymmetric-key-pair-grouping" grouping = discussed in
                Section 2.1.3.4 of = [I-D.ietf-netconf-crypto-types].

            It looks = to me like it is actually Section 2.1.4.4 of = [I-D.ietf-netconf-crypto-types].

            Fixed! =  =E2=80=9C2.1.3.4=E2=80=9D -> =E2=80=9C2.1.4.5"

            This is one issue with the new =E2=80=9Crelref=E2=80= =9D element in the xml2rfc v3 syntax, a section number (e.g., = =E2=80=9C2.1.3.4=E2=80=9D) has to be hardcoded, there=E2=80=99s no = option to use the =E2=80=9Canchor=E2=80=9D value, so misalignments may = occur unknowingly.



            Section 2.1.3.7 p 11

             *  The "keystore-grouping" grouping is defines a = keystore instance as

            "is defines" -> = "defines"

            Fixed


             * =  For asymmetric keys, each "asymmetric-key" uses the = "asymmetric-
            =     key-pair-with-certs-grouping" grouping discussed = Section 2.1.3.10
                of = [I-D.ietf-netconf-crypto-types].

            "discussed" = -> "discussed in"

            Quite right, and I found another like it, fixed = both.


            Why do none of = the asymmetric keys here use a grouping that is the key only, like the = ct:asymmetric-key-pair-grouping used in Sectoin 2.1.3.4 of this document = (discussed in 2.1.4.4 of [I-D.ietf-netconf-crypto-types]).

                  | =     |     +--rw = encrypted-private-key
            =       |     | =        +--rw encrypted-by
                  | =     |        | =  +--rw (encrypted-by-choice)
            =       |     | =        | =     +--:(symmetric-key-ref)
            =       |     | =        |     | =  +--rw symmetric-key-ref?    leafref
            =       |     | =        | =     +--:(asymmetric-key-ref)
            =       |     | =        | =        +--rw asymmetric-key-ref? =   leafref

            The = section you quoted is for the = "encrypted-private-key=E2=80=9D case of a =E2=80=9Cchoice" = statement called "private-key-type=E2=80=9D.  This =E2=80=9Cchoice=E2=80=9D also = supports "cleartext-private-key=E2=80=9D, that is the raw key only, = is that what you mean?


            Section 2.2.1 p 13

             The = following example illustrates keys in <running>.

            Like I said before, maybe a citation of RFC8340 here.

            The new = Terminology section defines =E2=80=9C<running>" = (and =E2=80=9C<operational>) pointing to RFC8342 (NMDA). =  [PS: RFC 8340 is for =E2=80=9CTree Diagrams=E2=80=9D]


            Section 2.2.3 p 17 has the = phrase "following non-normative ".  Does that belong here?  Or = because this is XML, it can not be confused to be a normantive Yang = module?

            It was/is a little bit of everything   = \_o_/

            I created a new = introduction:

            = <t>These examples assume the existence of = an example
             module called = "ex-keystore-usage=E2=80=9D having the namespace
             "http://example.com/ns/example-keystore-usage".</t>

            And then changed the line as = follows:

            OLD:
              =           <t>The following = non-normative module is defined to illustrate these
                        =   groupings:</t>
            NEW:
              =           <t>Following is the = "ex-keystore-usage" module's YANG definition: 


            =       <symmetric-key>
            =      <encrypted-by>
            =             &n= bsp; <asymmetric-key-ref>hidden-asymmetric-key</asymmetric-k= \
             ey-ref>
            =             &l= t;/encrypted-by>

            The = "hidden-asymmetric-key" key appears later in the asymmetric-keys part of = the keystore example on p15.  I don't know how to prevent that = forward sort of reference for the readers, or if it is a problem.

            This = is not a problem, as ordering doesn=E2=80=99t = matter with YANG-defined models.  


            Section 2.2.3 p 18

                 list end-entity-cert-with-key = {
                   key name;
                   ...
            =        uses = ks:local-or-keystore-end-entity-cert-with-key-grouping;
            =        description
            =          "An end-entity = certificate, and its associated private key,
            =           that may be = configured locally or be a reference to a
            =           specific = certificate (and its associated private key) in
            =           the = keystore.";

            You can't rely on descriptions, = but I see no explicit reference to the private key in that end-entity = cert grouping.  That grouping is defined in Section 2.1.3.6 p 9, = and the keystore-reference is an = asymmetric-key-certificate-ref-grouping.  That grouping has an = asymmetric-key-ref and a cert.  The description above says "and its = associated private key".  So is the asymmetric-key-ref a ref to the = private key or to a key pair?

            Fixed. =  =E2=80=9Cassociated private key=E2=80=9D -> "associated = asymmetric key"

                  =   "An end-entity certificate and its = associated asymmetric
                    =  key, that may be configured locally or be a reference
                     to another = certificate (and its associated asymmetric
              =        key) in the keystore.=E2=80=9D;



            Section 2.3 p 25

            =    typedef symmetric-key-ref {
            =      type leafref {
            =        path = "/ks:keystore/ks:symmetric-keys/ks:symmetric-key"
            =           + = "/ks:name";
                 }

            Does default-deny-write belong here, or added = each time an item is defined of this type?

            No, because it is a typedef, and = typedefs don=E2=80=99t support extensions (search RFC 7950 for "typedef-stmt=E2=80=9D and "extension-stmt=E2=80=9D).


            Section 2.3 p 26

            =        case asymmetric-key-ref {
                     leaf = asymmetric-key-ref {
            =            type = leafref {
            =             &n= bsp;path "/ks:keystore/ks:asymmetric-keys/"
            =             &n= bsp;     + "ks:asymmetric-key/ks:name";
            =            }
            =            descript= ion
            =             "I= dentifies the asymmetric key used to encrypt this key.";
            =          }

            (a) "the asymmetric key used to encrypt" - the public key = part is used to encrypt, so is the asymmetric key just the public key or = a key-pair where the appropriate part of the key-pair is used according = to context?

            OLD:
                      =   "Identifies the asymmetric key used to encrypt this key.";
            NEW:
                      =  "Identifies the asymmetric key whose public key
                =         encrypted the = associated key.";


            (b) "encrypt this key" - The "this key" part is appropriate = if the assymmetric-key-ref is being used in an encrypted-by-choice = structure, but there are lots of places in this text where the type is = not in such a structure.  Is it the case that the uses always = resolve to be encrypting a key?

            Right, = per above, now "the associated key=E2=80= =9D and the =E2=80=9Cdescription" statement = for "encrypted-by-choice-grouping=E2=80=9D now = says:

                =   "A grouping that defines a choice that can be augmented = into
                   the 'encrypted-by' node = presented by the 'symmetric-key-grouping'
              =      and the 'asymmetric-key-pair-grouping' = groupings defined in
                   RFC = AAAA.=E2=80=9D;

            Indicating that = the =E2=80=9Cassociated key=E2=80=9D is defined in those two = groupings.  Good enough?


            (c) "encrypt" - Is it always = the case that asymmetric keys in the keystore will be used to encrypt = something?  There is no expectation that the asymmetric key-pair = will be used to sign something?

            An = asymmetric-key may be used to sign something, but this module has no = need to do that.  For instance, the module doesn=E2=80=99t support = the notion of a =E2=80=9Csigned key=E2=80=9D (a la =E2=80=9Cencrypted = key=E2=80=9D), beyond its support for certificates.  This doesn=E2=80= =99t preclude a consuming application from using an asymmetric key to = sign data if needed.


            Section 2.3 = p27

            =      description
            =        "A grouping that expands to = allow the symmetric key to be
            =         either stored locally, = within the using data model, or be
            =         a reference to a = symmetric key stored in the Keystore.";

            The = following is wordsmithing the description text, so a very-nitty-nit.

            ", or be" -> ", or"  (the "be" is = before the "either", don't need it)

            A = reader might be confused as to whether the disjunction was two disjuncts = or three.

            Fixed, in all four places where =E2=80=9Cor be=E2=80= =9D was being used.


            I might suggest using "i.e., within the using data store". =  Maybe also
            move the "be" inside the "either or" for = scoping
                   "A = grouping that expands to allow the symmetric key to either
            =         be stored locally, i.e., = within the using data model, or be
            =         a reference to a = symmetric key stored in the Keystore.";

            Added = =E2=80=9Ci.e.,=E2=80=9D

            The groupings = in this section have a descriptoin of the grouping, a description of the = key case and a description of the choice.  I thought it worked = better to place the description of the choice closer to the "choice = local or keystore" rather than at the end.

            Moved = all =E2=80=9Cchoice=E2=80=9D statement descriptions be before the = =E2=80=9Ccase=E2=80=9D statements.


            And finally. Descriptions very frequently (always?) conclude = with a "." but they are very frequently not sentences, so the "." is not = necessary.  I do not know if the RFC-Editor or the Style manual = cares.

            The descriptions should be sentences.  I = found only two instances that were missing an opening article (=E2=80=98A=E2= =80=99), which gave the appearance of not being a sentence=E2=80=A6but = you said there were =E2=80=9Cmany"?


            Section 2.3 p 28

            =    grouping = local-or-keystore-asymmetric-key-with-certs-grouping
            =    ...
            =       case keystore {
            =          if-feature = "keystore-supported";
            =          leaf = keystore-reference {
            =            type = ks:asymmetric-key-ref;
            =            descript= ion
            =             &n= bsp;"A reference to an asymmetric-key (and all of its
            =             &n= bsp; associated certificates) in the Keystore.";

            An example of my puzzle about the = local-or-keystore-asymmetric-key-with-certs-grouping keystore-reference. =  How are the certs to be found if the keystore-reference is to the = asymmetric key only?  Or must the asymmetric-key-ref sometimes = point just to a key and sometimes to a key+certs, as needed?

            An = asymmetric key "in the Keystore=E2=80=9D always allows certs to be = associated.  I understand that this isn=E2=80=99t true for = asymmetric keys in general.



            Section 3 p 31

            =  In some implementations, a server may support built-in keys. =  Built-
             in built-in keys

            "Built-in built-in" =3D> "Built-in"

            Fixed = - redundancy removed.


            Section 3 p 32

             In order = for the built-in keys (and/or their associated built-in
            =  certificates) to be referenced by configuration, the referenced = keys
             MUST first be copied into <running>. The = keys SHOULD be copied into
             <running> using the same "key" = values, so that the server can bind
             the references = to the built-in entries.

            =  Built-in "hidden" keys cannot be copied into other parts of the
             configuration because their private parts are hidden, = and therefore
             impossible to replicate.

            Section 4 p34 says built-in keys MUST be = hidden.  So they must be copied to <running> but they can't = be copied? Huh?


            OLD:
                  =   <t>Built-in "hidden" keys cannot be copied = into other parts of the 
                  =     configuration because their private parts = are hidden, and therefore
                    =   impossible to replicate.  Built-in = "encrypted" keys MAY be copied
                  =     into other parts of the configuration so long = as they maintain their
                    =   reference to the other built-in key that encrypted = them.</t>
            NEW:
                =     <t>In addition to copying keys into the = Keystore in &lt;running&gt;, 
              =         cleartext and encrypted keys may be = copied into other parts of 
                  =     configuration, but they will lose = their connection to having been
                  =     a built-in value.  Note that hidden keys = cannot be copied into
                    =   other parts of the configuration because doing would = lose the key's
                    =   connection to the built-in key, where the key's secret = value is 
                    =   stored.  Built-in "encrypted" keys MAY be = copied into other parts 
                  =     of the configuration so long as the reference = to the other built-in 
                  =     key that encrypted them is maintained.</t>



            The keys SHOULD be = copied into
             <running> using the same "key" values, so that = the server can bind
             the references to the built-in = entries.

            The word "key" is overloaded = in this document, like "The key characteristic of the built-in keys" and = "Key Words".  Here, the reference is surely to a required part of = the "list" syntax, so no way to use a different word.  Maybe say = 'the same list "key" values' or 'the same values for the list "key" = field/node'.

            Changed "Key characteristic" to "primary = characteristic=E2=80=9D.

            "Key = words=E2=80=9D is RFC 2119 language that cannot be altered.

            OLD:
                  =     The keys SHOULD be copied into
                    =   <running> using the same "key" values, so that = the server can bind
                    =   the references to the built-in entries.
            NEW:
                      The = keys SHOULD be copied
                    =   into &lt;running&gt; using the same value = for the list's "key" 
                  =     substatement, so that the server can bind = the references to the
                    =   built-in entries.


               =          =     Built-in "encrypted" keys MAY be copied
             into other parts of the configuration so long as they = maintain their
             reference to the other built-in key = that encrypted them.

            (a) Section 4 p34 says = "built-in keys MUST be hidden", so is there a way the hidden built-in = keys can be encrypted keys?

            Under = the hood, it is possible that a hidden key is encrypted, but if it is, = that information would be hidden too ;)

            (b) So encrypted built-in keys must always be encrypted by = other built-in keys?  Is there a way to represent that in the data = model?  (I explored this before.)

            =  <running> MAY be a subset of the built-in keys define in = <operational>

            "define" -> = "defined"

            FIXED.



             Only the referenced keys need to be = copied; that is, the keys in
             <running> MAY be = a subset of the built-in keys define in
            =  <operational>.  No keys may be added or changed (with = exception to
             associating additional certificates to = a built-in key); that is, the
             keys in = <running> MUST be a subset (which includes the whole of the
             set) of the built-in keys define in = <operational>.

            I don't understatnd = this part.  First it says

            "keys in = <running> MAY be a subset of the built-in keys define in = <operational>"

            and then

            "keys in <running> MUST be a subset ... = of the built-in keys define in <operational>".

            That is inconsistent, is it intended?

            Does the last sentence mean that if there are built-in keys, = no other keys may be added to the keystore?  I don't know what is = intended here.

            Removed the = last part: i.e., =E2=80=9Cthe keys in <running> MUST be a subset = (which includes the whole of the set) of the built-in keys define in = <operational>."

            NEW:
                  =   <t>Only the referenced keys need to be = copied; that is, the keys
                    =   in &lt;running&gt; MAY be a subset, = including the whole of the set, 
                =       of the built-in keys defined = in &lt;operational&gt;.</t>  
                    <t>No new built-in = keys may be added nor existing built-in changed, 
                      with exception to = associating additional certificates to an 
              =         existing built-in key.</t>


            About "exception to" - I use "exeption to <rule>" and = "exception for <a special case>".  I don't know if the = RFC-Editor or the Style manual cares.

            =E2=80=9Cexc= eption to=E2=80=9D =E2=80=94> =E2=80=9Cexception for=E2=80=9D

            Section 4.1 p34

            =  not support hidden keys, then the private data part of key MUST be =

            "of key" -> "of the root key"

            This = sentence no longer exists after the rewrite of the section addressing = the comment from Magnus.


            Section 4.1 p35

            =             &n= bsp;If the hidden root key is asymmetric, then the server
            =  SHOULD provide APIs enabling other keys to be both generated = and
             encrypted by it

            The = "both generated and encrypted by it" sounds like keys are being = generated by the root key.  I don't think that's generally true. =  Section 4.2 separates key generation and key encryption steps. =  I think this should be clearer.

            (The = mention of other crypto services moved to area before nits.)

            After = addressing the comment from Magnus, the new text is:

                  =     <t>Implementations SHOULD provide an API = that simultaneously generates
                  =       and encrypts a key (symmetric or = asymmetric) using a KEK.  Thusly
              =           newly generated key cleartext = values are never known to the
                  =       administrators generating the = keys.</t>

            Better?


            Section 4.2 p35

            (A discussion of = issues, not nits, was moved to area before nits.)

            Section 4.3 p35

            (A discussion of = issues, not nits, was moved to area before nits.)  
            Section 5.2 p38

            (A discussion = of issues, not nits, was moved to area before nits.)

            Okay.




                |  Please be = aware that this module uses the "key" and "private-
            =     |  key" nodes from the "ietf-crypto-types" = module
                | =  [I-D.ietf-netconf-crypto-types], where said nodes have the NACM
                |  extension "default-deny-all" = set, thus preventing unrestricted
            =     |  read-access to the cleartext key = values.

            This text missed the change A.19 to = add a "cleartext" prefix as in ietf-netconf-crypto-types.  The = "cleartext" prefix is present in the modules, tree-diagrams, XML, etc., = but the references in text here did not change.  (Actually, I see = several examples in the text in ietf-netconf-crypto-types where the = change was not made, e.g. p 9 says  '-  The "key" node can = encode any plain-text key value.' where the preceding tree diagram has a = node named "cleartext-key" and older versions said "key".)  I = appreciate the discussion of the default-deny-all in Section 3.5 p42 of = ietf-netconf-crypto-types and I think that a citation here would be = warranted and useful.

            Fixed: prefixed =E2=80=9Ccleartext-=E2=80=9C

            NEW:
                    =     <t>Please be aware that this module uses = the "cleartext-key" and 
                    =       "cleartext-private-key" nodes from the = "ietf-crypto-types" module 
                    =       = <xref target=3D"I-D.ietf-netconf-crypto-types"/>, where = said nodes
                          = have the NACM extension "default-deny-all" set, = thus preventing
                        =   uncontrolled read-access to the cleartext key = values.</t>

            Also fixed a number of = missing =E2=80=9Ccleartext-=E2=80=9C prefixes in the crypto-types = draft.


            BTW.  I = don't know the NACM well but could it be said that the default-deny-all = prevents uncontrolled access, but does not necessarily prevent = unrestricted access, because a present but careless access control might = not actually restrict access?

            Fixed. =  See =E2=80=9Cuncontrolled=E2=80=9D the the NEW = above.


            Section 6.2 p = 39

            "the the" -> "the"

            Fixed = (in other documents also) - thanks!

            Section 7.2 = p40

            The list of Informative References = includes:

            =  [I-D.ietf-netconf-keystore]
            =             Wa= tsen, K., "A YANG Data Model for a Keystore", Work in
            =             Pr= ogress, Internet-Draft, draft-ietf-netconf-keystore-17,
            =             20= May 2020, <https://tools.ietf.org/html/draft-ietf-
            =             ne= tconf-keystore-17>.

            Isn't this a self = reference to an earlier version?

            Note: ID = nits gives 11 warnings, but all are due to references to older versions = of existing drafts or to future versions not yet published.  The = latter case seems to be wrong, and the warning usually notes
               (However, the state information for = draft-ietf-netconf-keystore is not
            =    up-to-date.  The last update was unsuccessful)

            I have no idea what that means.  The = warnings are consistent, so may be something to watch.

            Generally speaking, a document should not = reference itself!  The self-reference in this document is coming = from Section 1.1 (Relation to other RFCs).  The XML feeding this = section is from a common snippet of xml2rfc XML that is stitched into = the same spot for each of the documents in the collection of RFCs-to-be, = per the "Relation to other RFCs=E2=80=9D section.   My choices = are:

            1) Copy-paste the common-text = into each document and then customize it by converting the = self-reference to something like =E2=80=9C<this document>=E2=80=9D, = and the remove the reference from the "Informative References=E2=80=9D = section.

            or

            2) Add an = RFC-editor note requesting that customization be made for each document = in the collection.

            Thoughts?


            K.


            =E2=80=94Sandy

            = --Apple-Mail=_0348A326-1A9C-4C92-A178-9883E263A74F-- From nobody Fri Aug 21 09:57:01 2020 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 A1B5A3A0D81 for ; Fri, 21 Aug 2020 09:56:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <159802901764.21588.1038409968581238410@ietfa.amsl.com> Date: Fri, 21 Aug 2020 09:56:57 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 16:56:58 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-08-27 Reviewer LC end Draft Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-09 Last calls: Reviewer LC end Draft Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-09 Daniel Gillmor 2020-06-12 draft-ietf-pce-stateful-pce-lsp-scheduling-26 Dan Harkins None draft-ietf-rtgwg-policy-model-03 David Mandelberg 2020-07-14 draft-ietf-idr-rfc8203bis-06 Kathleen Moriarty 2020-07-20 draft-ietf-ace-oscore-profile-11 Russ Mundy 2020-07-20 draft-ietf-ace-dtls-authorize-12 Yoav Nir None draft-ietf-netconf-trust-anchors-13 Tirumaleswar Reddy.K 2020-08-18 draft-ietf-roll-turnon-rfc8138-10 Vincent Roca 2020-04-23 draft-ietf-detnet-ip-over-mpls-06 Joseph Salowey 2020-08-14 draft-ietf-regext-rdap-partial-response-13 Rich Salz 2020-08-14 draft-ietf-suit-architecture-11 Sean Turner 2020-09-02 draft-ietf-lamps-ocsp-nonce-03 Mališa Vučinić 2020-08-28 draft-ietf-bess-evpn-na-flags-05 Carl Wallace 2020-08-26 draft-ietf-stir-cert-delegation-03 Samuel Weiler 2020-08-26 draft-ietf-mpls-spl-terminology-03 Samuel Weiler 2020-06-11 draft-ietf-trill-multilevel-single-nickname-13 Brian Weis 2020-08-26 draft-ietf-spring-srv6-network-programming-17 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-09 Paul Wouters 2020-05-25 draft-ietf-capport-architecture-09 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Klaas Wierenga Christopher Wood Paul Wouters Liang Xia Dacheng Zhang Derek Atkins John Bradley Nancy Cam-Winget Shaun Cooley Alan DeKok From nobody Fri Aug 21 10:10:46 2020 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 04DF43A0D76; Fri, 21 Aug 2020 10:10:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Samuel Weiler via Datatracker To: Cc: last-call@ietf.org, draft-ietf-trill-multilevel-single-nickname.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159802984090.28806.6174074934791715126@ietfa.amsl.com> Reply-To: Samuel Weiler Date: Fri, 21 Aug 2020 10:10:40 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-trill-multilevel-single-nickname-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 17:10:41 -0000 Reviewer: Samuel Weiler Review result: Ready Question for WG/authors: how much routing (bridging) instability does this naming scheme create when new interconnections are added, particularly of redundant connections (as suggested in Fig 1)? I'm imagining that interconnection (and disconnection) happen relatively easily and often and this this naming scheme might create instability that need not exist when a redundant link goes up or down. Other than that: I'm not happy with TRILL's security story, in general, but this doesn't seem to make it any worse. From nobody Fri Aug 21 10:15:13 2020 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 979973A094E; Fri, 21 Aug 2020 10:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psDlR0aPntqQ; Fri, 21 Aug 2020 10:15:08 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 3D58F3A0930; Fri, 21 Aug 2020 10:15:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.25.170.45; From: "Susan Hares" To: "'Samuel Weiler'" , Cc: , References: <159802984090.28806.6174074934791715126@ietfa.amsl.com> In-Reply-To: <159802984090.28806.6174074934791715126@ietfa.amsl.com> Date: Fri, 21 Aug 2020 13:14:40 -0400 Message-ID: <01de01d677de$90c62c80$b2528580$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQMkAZm0yr5XmaXrrgr+BH7yMpe6uKanuZbQ X-Antivirus: AVG (VPS 200821-2, 08/21/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-trill-multilevel-single-nickname-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 17:15:10 -0000 Samuel:=20 Can you tell me why you are not happy with TRILL's security situation? = Are you unhappy with IS-IS security situation?=20 Shepherd, Susan Hares=20 -----Original Message----- From: Samuel Weiler via Datatracker [mailto:noreply@ietf.org]=20 Sent: Friday, August 21, 2020 1:11 PM To: secdir@ietf.org Cc: last-call@ietf.org; = draft-ietf-trill-multilevel-single-nickname.all@ietf.org Subject: Secdir last call review of = draft-ietf-trill-multilevel-single-nickname-09 Reviewer: Samuel Weiler Review result: Ready Question for WG/authors: how much routing (bridging) instability does = this naming scheme create when new interconnections are added, = particularly of redundant connections (as suggested in Fig 1)? I'm = imagining that interconnection (and disconnection) happen relatively = easily and often and this this naming scheme might create instability = that need not exist when a redundant link goes up or down. Other than that: I'm not happy with TRILL's security story, in general, = but this doesn't seem to make it any worse. From nobody Sat Aug 22 10:08:54 2020 Return-Path: <010001741724e9a2-67e44258-e2fa-431a-a987-9836ecd1453d-000000@amazonses.watsen.net> 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 993D23A09BA; Sat, 22 Aug 2020 10:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 e358TCSwtq80; Sat, 22 Aug 2020 10:08:50 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F0A3A09BB; Sat, 22 Aug 2020 10:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1598116129; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=drLSgUriZUuTVL9XSFeIWcYHelcgBk0zM+qtxswotPU=; b=HPBHfFD2kk+Fb8hVNVo99hD8cLJyWlAnrPtvxjQIqtADLts2XmaC3jTg62t1MkbJ gUVFV9tRZU7/g23STlLx0PD6uAL5qp9I/2Iy1/gsib11VFDucQ0p/fiamjX1fTQjozf 9I7qfNzKCcU43pDoud/TP3ArH1fxjfDSLaBX+19U= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <24379.56023.497287.414181@fireball.acr.fi> Date: Sat, 22 Aug 2020 17:08:49 +0000 Cc: "netconf-chairs@ietf.org" , secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-ID: <010001741724e9a2-67e44258-e2fa-431a-a987-9836ecd1453d-000000@email.amazonses.com> References: <18A977F3-E1D5-4016-B54A-5BEFD9453E31@tislabs.com> <24379.56023.497287.414181@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.08.22-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [secdir] early secdir review of draft-ietf-netconf-keystore-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2020 17:08:52 -0000 Tero, just wondering, could the second review request have been for a = similarly named draft, draft-ietf-netconf-trust-anhors? Mahesh, I think I recall your saying that you would do a request for = both drafts, but so far only keystore has been reviewed, and twice at = that=E2=80=A6 K. > On Aug 18, 2020, at 9:42 AM, Tero Kivinen wrote: >=20 > Sandra Murphy writes: >> And I missed the fact that Magnus did a review as well. >=20 > Yes, it seems there was two review requests for the > draft-ietf-netconf-system-keytchain, one for early review and another > for last call review. I did not notice that there were two so I > did assignments for both... > --=20 > kivinen@iki.fi From nobody Sat Aug 22 19:23:44 2020 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 B9D913A10C7; Sat, 22 Aug 2020 19:23:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: last-call@ietf.org, regext@ietf.org, draft-ietf-regext-rdap-partial-response.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159814941271.29012.16953264278628400524@ietfa.amsl.com> Reply-To: Joseph Salowey Date: Sat, 22 Aug 2020 19:23:32 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-regext-rdap-partial-response-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2020 02:23:33 -0000 Reviewer: Joseph Salowey Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is the document is Ready The document is clear and has sufficient security considerations. From nobody Sun Aug 23 20:33:01 2020 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 3ED733A098A; Sun, 23 Aug 2020 20:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 ZHqM1v04sxxr; Sun, 23 Aug 2020 20:32:57 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 4A8563A0995; Sun, 23 Aug 2020 20:32:57 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id p37so3905548pgl.3; Sun, 23 Aug 2020 20:32:57 -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=8qmnNq/kB83sJSnUWZI41ra4NLbBx7klOKjU0uCaYrk=; b=LY/ows8Nnhm9hCfAcVUBXqbua72cjKujkflIoezVLWgjMo/IsxiBms5NqZ3dEld+gi xdIhjHCCdrbdn2zYWJgSV/irIYuLOyHi3AxVoNE1le3+CTs+DbRkABWUaQrhaWcvjpQQ TOc9hgeAyZ6CR66jxUkhhRsTS8Qjq6nKvPxAINCQIIKn9/nmBScNPlAS8k5YTXltxt2u iuFFVkcouVOl/ddSPrVyq7GMrsytcJ5iiOtEtg88QHF9Cjwo9gZIqhmICgyTv3jnLGgs /3f1zkWujEh9HUQrnlh1JGGs/WttJv5YFEwSMDWIp1zzl/I8j2axPZ6uY7JZnGk6rCx4 uZHw== 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=8qmnNq/kB83sJSnUWZI41ra4NLbBx7klOKjU0uCaYrk=; b=lP4y68C32laDt5Rc1k2t+pGrhMKI4CUgoSMdNQ0qQJ1vObLLpZ4w1wFazyv7263vGj aIJMLxIKyNbZvyWnYW/YTUPaFXfB6wqj2WhrGrqNHMLyPi+u13vyQokrJYCefFb/bybS h0E7sCcH+by7C0EmXRqr7Mno3wuQtYzVmr1RCnvBwyHVye88G3tao/C1OeWgwJl+BV5R Nw1SoINhg5yN8UfUWYi7SUqDx6YYGVX8IScKzyKyIQH9N8cEBm5VmwFoxkyZhMJ830hK cHAvWxYORwihK9vuep/K4ZvkR4XyXJ1w5yk35itujkO9wZsPEz7+17WUM13/wKxLYdom B8Bw== X-Gm-Message-State: AOAM532yEfgy0GdhDUguUcGjC4MgA5SFgpNzd7/K2HqJMe5oEvLW3Jll LF747MOyMWt3g73Y8Q0n64NDdlLHklQ= X-Google-Smtp-Source: ABdhPJwPRu0gQbpfyMogDNgplGXSmET2grW2OvHT7Xkx/zKcS5G2/N5hGovTiT41SpH6JhUk+AaARA== X-Received: by 2002:a05:6a00:847:: with SMTP id q7mr2679497pfk.172.1598239976705; Sun, 23 Aug 2020 20:32:56 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:ec63:ca69:e443:bff? ([2601:647:5600:5020:ec63:ca69:e443:bff]) by smtp.gmail.com with ESMTPSA id w187sm9340379pfd.87.2020.08.23.20.32.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Aug 2020 20:32:55 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F155ED8C-39E6-494E-9D33-C5D13773B80C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\)) Date: Sun, 23 Aug 2020 20:32:54 -0700 In-Reply-To: <010001741724e9a2-67e44258-e2fa-431a-a987-9836ecd1453d-000000@email.amazonses.com> Cc: Tero Kivinen , "netconf-chairs@ietf.org" , secdir@ietf.org To: Kent Watsen References: <18A977F3-E1D5-4016-B54A-5BEFD9453E31@tislabs.com> <24379.56023.497287.414181@fireball.acr.fi> <010001741724e9a2-67e44258-e2fa-431a-a987-9836ecd1453d-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.9.6) Archived-At: Subject: Re: [secdir] early secdir review of draft-ietf-netconf-keystore-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 03:32:59 -0000 --Apple-Mail=_F155ED8C-39E6-494E-9D33-C5D13773B80C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A SecDir review of both keystore and trust-anchors draft was requested. = Yoav Nir has been assigned to do the review of trust-anchors, which he = has not completed as yet. > On Aug 22, 2020, at 10:08 AM, Kent Watsen = wrote: >=20 > Tero, just wondering, could the second review request have been for a = similarly named draft, draft-ietf-netconf-trust-anhors? >=20 > Mahesh, I think I recall your saying that you would do a request for = both drafts, but so far only keystore has been reviewed, and twice at = that=E2=80=A6 >=20 > K. >=20 >=20 >> On Aug 18, 2020, at 9:42 AM, Tero Kivinen wrote: >>=20 >> Sandra Murphy writes: >>> And I missed the fact that Magnus did a review as well. >>=20 >> Yes, it seems there was two review requests for the >> draft-ietf-netconf-system-keytchain, one for early review and another >> for last call review. I did not notice that there were two so I >> did assignments for both... >> --=20 >> kivinen@iki.fi >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_F155ED8C-39E6-494E-9D33-C5D13773B80C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A = SecDir review of both keystore and trust-anchors draft was requested. = Yoav Nir has been assigned to do the review of trust-anchors, which he = has not completed as yet.

            On Aug 22, 2020, at 10:08 AM, = Kent Watsen <kent+ietf@watsen.net> wrote:

            Tero, = just wondering, could the second review request have been for a = similarly named draft, draft-ietf-netconf-trust-anhors?

            Mahesh, I think I recall your saying that you would do a = request for both drafts, but so far only keystore has been reviewed, and = twice at that=E2=80=A6

            K.


            On Aug = 18, 2020, at 9:42 AM, Tero Kivinen <kivinen@iki.fi> wrote:

            Sandra Murphy writes:
            And I missed the fact that Magnus did a review as well.

            Yes, it seems there was two = review requests for the
            draft-ietf-netconf-system-keytchain,= one for early review and another
            for last call review. I = did not notice that there were two so I
            did assignments = for both...
            --
            kivinen@iki.fi


            Mahesh Jethanandani
            mjethanandani@gmail.com





            = --Apple-Mail=_F155ED8C-39E6-494E-9D33-C5D13773B80C-- From nobody Mon Aug 24 14:31:13 2020 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 180783A0CC4 for ; Mon, 24 Aug 2020 14:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 Rpczt8xFaxAn for ; Mon, 24 Aug 2020 14:31:10 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3081A3A0CC1 for ; Mon, 24 Aug 2020 14:31:09 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 07OLV5HI017634; Mon, 24 Aug 2020 17:31:05 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 07OLV5HI017634 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1598304666; bh=5AmdrcqFfd834JsSeb1sZPBgW2hn+LvGEqVv57W4pX8=; h=From:To:Subject:Date:References:In-Reply-To:From; b=YHWtHVu9J71wILI/eyXMR2Dp0tBTofNb7lLTPC0zec9K1oe4ksI0NSgFciVzrb2op DdZXyIpGcI8bLwZzbg6tnYQVxnhKliuto2dCzcU6Psx3p5MpyQfM3huvuVnKQgQ2EG 8evUwOLdT4xb6fLMLlZ27xUsQLP2cLih5yfsqleQ= Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 07OLV4Al040836; Mon, 24 Aug 2020 17:31:04 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 24 Aug 2020 17:31:03 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Mon, 24 Aug 2020 17:31:03 -0400 From: Roman Danyliw To: Radia Perlman , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-bess-rfc5549revision-04 Thread-Index: AQHWY70XU77VA9/k+kyxXuT6xqYWp6lH85lg Date: Mon, 24 Aug 2020 21:31:03 +0000 Message-ID: <828c2d017dc64e63bf607321dd18ad46@cert.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.203.1] Content-Type: multipart/alternative; boundary="_000_828c2d017dc64e63bf607321dd18ad46certorg_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-bess-rfc5549revision-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 21:31:12 -0000 --_000_828c2d017dc64e63bf607321dd18ad46certorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFkaWEsIHRoYW5rIHlvdSBmb3IgdGhpcyByZXZpZXchDQoNCkkgaGFkIG5vdGhpbmcgZWxz ZSB0byBhZGQgZnJvbSB3aGF0IHdhcyBhbHJlYWR5IG5vdGVkIGhlcmUgYW5kIGJ5IG15IHBlZXIg QURzLg0KDQpUaGFua3MsDQpSb21hbg0KDQoNCg0KRnJvbTogaWVzZyA8aWVzZy1ib3VuY2VzQGll dGYub3JnPiBPbiBCZWhhbGYgT2YgUmFkaWEgUGVybG1hbg0KU2VudDogU3VuZGF5LCBKdWx5IDI2 LCAyMDIwIDEwOjI0IFBNDQpUbzogc2VjZGlyQGlldGYub3JnOyBUaGUgSUVTRyA8aWVzZ0BpZXRm Lm9yZz47IGRyYWZ0LWlldGYtYmVzcy1yZmM1NTQ5cmV2aXNpb24uYWxsQGlldGYub3JnDQpTdWJq ZWN0OiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYmVzcy1yZmM1NTQ5cmV2aXNpb24tMDQN Cg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkg ZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRz IGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRl biBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9y cy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29t bWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCg0KDQpTdW1t YXJ5OiBJIGhhdmUgZm91bmQgbm8gaXNzdWVzIHdpdGggdGhlIGRvY3VtZW50Lg0KDQpUaGlzIGRv Y3VtZW50IHNwZWNpZmllcyB0aGUgZXh0ZW5zaW9ucyBuZWNlc3NhcnkgdG8gYWxsb3cgYWR2ZXJ0 aXNpbmcgSVB2NCBOTFJJIG9yIFZQTi1JUFY0IE5MUkkgd2l0aCBhbiBJUHY2IG5leHQgaG9wIGFk ZHJlc3MuDQoNCg0KVGhlIGRvY3VtZW50IGlzIGZpbmUuDQoNCg0KDQpOaXQ6IEkgZGlkbid0IHF1 aXRlIHVuZGVyc3RhbmQgYSB3b3JkIGluIHRoZSBhY2tub3dsZWRnZW1lbnQgc2VjdGlvbg0KDQoi ICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIEZyYW5jb2lzIExlIEZhdWNoZXVyIGFu ZCBFcmljIFJvc2VuDQoNCiAgIGZvciB0aGUgZWRpdGlvbiBhbmQgdGhlaXIgd29yayBvbiBbUkZD NTU0OTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTU0OT5dLiINCg0KV2hhdCBkbyB5 b3UgbWVhbiBieSAiZWRpdGlvbiI/ICBEbyB5b3UgcGVyaGFwcyBtZWFuICJlZGl0aW5nIHdvcmsi Pw0KDQpXb3VsZCB5b3Ugc3RpbGwgYmUgcHJvcGVybHkgYWNrbm93bGVkZ2luZyB0aGVtIGlmIHlv dSByZW1vdmVkIHRoZSB3b3JkcyAidGhlIGVkaXRpb24gYW5kIiwgYW5kIG1hZGUgaXQgc2ltcGx5 ICJmb3IgdGhlaXIgd29yaw0KDQpvbiBSRkM1NTQ5Ij8NCg0KDQoNClJhZGlhDQo= --_000_828c2d017dc64e63bf607321dd18ad46certorg_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBSYWRp YSwgdGhhbmsgeW91IGZvciB0aGlzIHJldmlldyE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBo YWQgbm90aGluZyBlbHNlIHRvIGFkZCBmcm9tIHdoYXQgd2FzIGFscmVhZHkgbm90ZWQgaGVyZSBh bmQgYnkgbXkgcGVlciBBRHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvbWFuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBpZXNnICZs dDtpZXNnLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpSYWRpYSBQ ZXJsbWFuPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgSnVseSAyNiwgMjAyMCAxMDoyNCBQTTxi cj4NCjxiPlRvOjwvYj4gc2VjZGlyQGlldGYub3JnOyBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9y ZyZndDs7IGRyYWZ0LWlldGYtYmVzcy1yZmM1NTQ5cmV2aXNpb24uYWxsQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1iZXNzLXJmYzU1NDly ZXZpc2lvbi0wNDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRp cmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBi ZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuJm5ic3A7IFRoZXNlIGNvbW1lbnRzIHdlcmUgd3Jp dHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVj dG9ycy4mbmJzcDsgRG9jdW1lbnQNCiBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0 IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxi cj4NCjxicj4NCjxicj4NCjxicj4NClN1bW1hcnk6IEkgaGF2ZSBmb3VuZCBubyBpc3N1ZXMgd2l0 aCB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGlzIGRvY3VtZW50Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPnNwZWNpZmllcyB0aGUgZXh0ZW5zaW9ucyBuZWNlc3NhcnkgdG8gYWxsb3cgYWR2 ZXJ0aXNpbmcgSVB2NCBOTFJJIG9yIFZQTi1JUFY0IE5MUkkgd2l0aCBhbiBJUHY2IG5leHQgaG9w IGFkZHJlc3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5UaGUgZG9jdW1lbnQgaXMgZmluZS4mbmJzcDsgPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Tml0OiBJ IGRpZG4ndCBxdWl0ZSB1bmRlcnN0YW5kIGEgd29yZCBpbiB0aGUgYWNrbm93bGVkZ2VtZW50IHNl Y3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mcXVvdDsmbmJzcDsgVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayBGcmFuY29p cyBMZSBGYXVjaGV1ciBhbmQgRXJpYyBSb3NlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IGZvciB0aGUgZWRpdGlvbiBhbmQgdGhlaXIgd29yayBvbiBbPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU1NDkiIHRpdGxlPSImcXVvdDtBZHZlcnRpc2lu ZyBJUHY0IE5ldHdvcmsgTGF5ZXIgUmVhY2hhYmlsaXR5IEluZm9ybWF0aW9uIHdpdGggYW4gSVB2 NiBOZXh0IEhvcCZxdW90OyI+UkZDNTU0OTwvYT5dLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+V2hhdCBkbyB5b3UgbWVhbiBieSAmcXVvdDtlZGl0aW9uJnF1b3Q7PyZuYnNwOyBEbyB5 b3UgcGVyaGFwcyBtZWFuICZxdW90O2VkaXRpbmcgd29yayZxdW90Oz88bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPldvdWxkIHlvdSBzdGlsbCBiZSBwcm9wZXJseSBhY2tub3dsZWRnaW5nIHRoZW0g aWYgeW91IHJlbW92ZWQgdGhlIHdvcmRzICZxdW90O3RoZSBlZGl0aW9uIGFuZCZxdW90OywgYW5k IG1hZGUgaXQgc2ltcGx5ICZxdW90O2ZvciB0aGVpciB3b3JrPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5vbiBSRkM1NTQ5JnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SYWRpYTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_828c2d017dc64e63bf607321dd18ad46certorg_-- From nobody Tue Aug 25 18:22:16 2020 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 C74EA3A0B69; Tue, 25 Aug 2020 18:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, 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=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kv9A--7Xcyav; Tue, 25 Aug 2020 18:22:12 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539C23A0B68; Tue, 25 Aug 2020 18:22:11 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id CDC671B00332; Wed, 26 Aug 2020 04:22:08 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1598404928; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=34f31Julg5dd+Nzgb5nu8aWwaXR0WWwp5hl1ppLSL7E=; b=AnGBzX3Ia0EcPsrCN0tHhqvNaJXcUGZKCOpZgrT1hzun8l25t0BwOY3vanOghQE/071fio qobyl2HiQHIUH+zNLqRV3GzpC7qqSRXr+wp5ZFVs+TpkCGlGPOVxZMvc0kVEQ9GF2+QcT4 BVVJktbEf1XMpEHU5aBNejoEamUvIExOSMlB8OoKBCk9zoa8Izj6LvqgN4yU3b4iHBWGdZ BsuocR/geHOpNHIhwvUCT+QgTxCUQlHnpZicbMQefDPnAXEWMLhE+ZN9BX5Hd4zfn//2M9 6ibRKhVxuWEYQHaCbRHWWH+p0jtuK36c17XAvDmIxZNpPXAl5/wxZNrm7T48tg== Received: by fireball.acr.fi (Postfix, from userid 15204) id 6E4E225C0F0B; Wed, 26 Aug 2020 04:22:08 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24389.47424.358714.281469@fireball.acr.fi> Date: Wed, 26 Aug 2020 04:22:08 +0300 From: Tero Kivinen To: Kent Watsen Cc: "netconf-chairs\@ietf.org" , secdir@ietf.org In-Reply-To: <010001741724e9a2-67e44258-e2fa-431a-a987-9836ecd1453d-000000@email.amazonses.com> References: <18A977F3-E1D5-4016-B54A-5BEFD9453E31@tislabs.com> <24379.56023.497287.414181@fireball.acr.fi> <010001741724e9a2-67e44258-e2fa-431a-a987-9836ecd1453d-000000@email.amazonses.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 12 min X-Total-Time: 14 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1598404928; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=34f31Julg5dd+Nzgb5nu8aWwaXR0WWwp5hl1ppLSL7E=; b=Lto+KNCCxqEshiJ5bm6inCDXFNy6lC2FA4/HWeHpIO/049ao8P1KUWAzgMr8miO3AL9WGp 3OLdgu1xg9IFa+mc3J6mwxczcSfAQ0j+1BO+Ib9oDIaftQRZ2AE7AonlCVkdNFETjzb8Fv pFgHB1fzYNf7iTZdm6itTelrnMRxGVnuwJWqk2F6AgE1B+pTainSKN4aE4qbXduA2inqyr /slm2XmWiIusH4YUh7mZ0ReAYAIoyCZW4JBAMZULOCEGHTymfR1tXYwxBjrSFStSXz8Ef8 uvB6AYjV3lI8ADGuawKB49HygXXHmIylssB7Fa8+Hjgwyd4NiaCh8cGtwizRgA== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1598404928; a=rsa-sha256; cv=none; b=cqT6vtI3kpZ+9txWRL8lQ5+YLicIF4WkR3z31c5iDR0GntfsVeZZTW4y1pcn6WDqiAEMjl JXBGH1T2jJQFvqHmusjkemh2B40Hi5O1jjsnc2iQTdNN5TZEo0s2poq1ANDRr1AAuGfiUD tZ0sxU/JTuq3IACxi4By0+/vuuSwiCELaLy8JtJZCW75qrQV/eKQXA7sTzal4BnCXJUPCa pvV6hA1aBLIwRLDAln/tFDltfpmZccFG+I/kmP0AUNM1FZlBmujrkfpSERj1HZWtrq7HDX /e9VwWjgwfWHXrlhJ5UiMOJyBsn3oQkSZiQHjs6XogBrkhgHc3/r5MQUj2EZRg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [secdir] early secdir review of draft-ietf-netconf-keystore-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 01:22:15 -0000 Kent Watsen writes: > Tero, just wondering, could the second review request have been for > a similarly named draft, draft-ietf-netconf-trust-anhors=3F=20 Datatracker shows there was two requests for the same draft: https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/history/ 2020-07-10=0918=09Tero Kivinen=09Request for Early review by SECDIR is =09=09=09 =09=09assigned to Magnus Nystrom=20 2020-07-10=0918=09Tero Kivinen=09Request for Early review by =09=09=09 =09=09SECDIR is assigned to Magnus =09=09=09 =09=09Nystrom 2020-07-10=0918=09Tero Kivinen=09Request for Last Call review =09=09=09 =09=09by SECDIR is assigned to =09=09=09 =09=09Sandra Murphy =20 2020-07-10=0918=09Tero Kivinen=09Request for Last Call review =09=09=09 =09=09by SECDIR is assigned to =09=09=09 =09=09Sandra Murphy =20 2020-07-09=0918=09Mahesh Jethanandani=09Requested Last Call =09=09=09 =09=09review by SECDIR=20 2020-07-09=0918=09Mahesh Jethanandani=09Requested Early review =09=09=09 =09=09by SECDIR=20 So there is both Last Call and Early Review requests done by Mahesh Jethanandani on 2020-07-09. I did assign last call review request to Sandra, and early review request to Magnus. You can ignore the fact that the assigned lines are always duplicated in the log. I have no idea why it is, but that happens for every assignment.=20 > Mahesh, I think I recall your saying that you would do a request for > both drafts, but so far only keystore has been reviewed, and twice > at that=E2=80=A6 https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/histo= ry/ 2020-07-10=0911=09Tero Kivinen=09Request for Last Call review =09=09=09 =09=09by SECDIR is assigned to Yoav Nir=20 2020-07-10=0911=09Tero Kivinen=09Request for Last Call review =09=09=09 =09=09by SECDIR is assigned to Yoav =09=09=09 =09=09Nir=20 2020-07-09=0911=09Mahesh Jethanandani=09Requested Last Call =09=09=09 =09=09review by SECDIR=20 There is open review request done for draft-ietf-netconf-trust-anhors draft also, done same day as other one, but it has not yet been done by Yoav... --=20 kivinen@iki.fi From nobody Wed Aug 26 15:33:54 2020 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 67B6C3A097E; Wed, 26 Aug 2020 15:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do0cW7-flZYb; Wed, 26 Aug 2020 15:33:47 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650099.outbound.protection.outlook.com [40.107.65.99]) (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 B84FE3A0965; Wed, 26 Aug 2020 15:33:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hCzEBvvmLlOmkXAba84oDtVGTE/L4gPHerj6n1iIH81zLfe/rs61jqmCUQAvoo+YD/w6xDUuXPgs2JXcbFwUuOy47l6fJ1IuY4jApDhdbKMvXWTeSCxw9UbcR3aNLsmSfrWnkK53FVZafG7UKCtkqTqImQhnprQZYeouLUHOZWQZcnhwu40liY+T0kFD06d2vyVrRSowTir9EsjnCoaxQGt0/4nauBmOit9JuH+4t2p7wKmAw95SvPb3Le8PiBo833cYusmTeMPnrmmea910fyjEkLq0HulSuiqxH0T3WoFusuAMqLp0H1rMOeYq/EVGLrPCZgqmqd0ui2IjTPK+jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ljksb4UioGm66w2regbo2/4obXm1aAcQFjX1YJPF8Wk=; b=kawAUJsQW4Dktqy7sXHa6m6j65BG2hU24eNfqJ9zJf7F2WHWlkURX9XHcW/gCqHjNNCScIvjiRSJCdEW9ITmyiEcemYfGvGe1ePnVob3Hu8Ya9dxF+i027trlnVYu7nk1v+FByLOo+cDGP8Vvi/jl5oUyttNTJ4eQpPP8QLnaO2Zw2VEEK6eMXh5oHroygMXSvo/brV1/Gb97+o0PFhuXJf+VvNSZikGsM/DHjC7X75A8zzcT7yffHmvZKXHP6OK1ERFB9FDC7GdiNjUm5YizG91KW/YCYEGL6URI7SHwQQU12HmbUIGFMpWBVvQbOCMNRyngJdniMWNZVoEx6uPjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ljksb4UioGm66w2regbo2/4obXm1aAcQFjX1YJPF8Wk=; b=MCFfNTnU2ZippKIUZ7MNkPizysD8VcrJt4oyg8ky5KsWgZVItLMkIhCLREao45RDQXrnBCh4ebmBT4ZkZZ49+FNR287S/eBFWm05aLYZ63LfMK/rWYMmZOWWdAcmWO2U8NSUzzWQ7RygTNqIjceFSdvoQ1udmmJlvmEH5+52l4A= Received: from (2603:10b6:610:a9::23) by CH2PR00MB0711.namprd00.prod.outlook.com (2603:10b6:610:ad::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3367.0; Wed, 26 Aug 2020 22:33:41 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::b8b7:3f55:bae6:5458]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::b8b7:3f55:bae6:5458%6]) with mapi id 15.20.3368.000; Wed, 26 Aug 2020 22:33:41 +0000 From: Mike Jones To: Kyle Rose , "secdir@ietf.org" CC: "draft-ietf-cbor-date-tag.all@ietf.org" , "last-call@ietf.org" , "cbor@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-cbor-date-tag-05 Thread-Index: AdZx1BxyoBjm9wtuR3uPvOkylOb0YQKJJuNA Date: Wed, 26 Aug 2020 22:33:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-14T00:28:56Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5ae9dac8-a305-4f45-8149-fa8770de83f5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: krose.org; dkim=none (message not signed) header.d=none;krose.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.86.243] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 70253109-12f4-4b27-665b-08d84a1015a0 x-ms-traffictypediagnostic: CH2PR00MB0711: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6GdMAxVwpLtJW4Zf3fe053sC9OpQwRHpPPWKegIi3oaXSghTGU34/I6dmUK7eQGlfKaoTp+3UrgCmwGJF04xNXbARnqVrgii6A8JTcvzHbZ2HCW95jvdknfMQYw9i/ot6iq/WczLo5W4CijP5SkIcXQBCgThD1vfeX8zD4x38UNbghaSVR3/kZlkF7Neij/oQnT1XfmYQ//dxCzLBU8Mb24FmnP3MaeNkRoDY3ITX56UouF+DetgtZGEmOw+PS5QBX0nQz9XNQ8K4YXm57WqRVHeOvfXctubabvd0v9JJS1gPn7bFTq+aZuzl0XRV3cLQN28sUDCIU1764sQqZ1xZJ+4sP2BzAwtgHPIy5umJAqeRjQ4rDh/VaCEJPoBTNDApBMlUgggnlNGtZPfa/pKEA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(376002)(136003)(366004)(346002)(33656002)(66946007)(66556008)(66446008)(66476007)(64756008)(52536014)(86362001)(71200400001)(966005)(4326008)(7696005)(478600001)(53546011)(83080400001)(55016002)(82950400001)(5660300002)(82960400001)(6506007)(83380400001)(316002)(166002)(8990500004)(26005)(186003)(9326002)(54906003)(2906002)(9686003)(8676002)(76116006)(110136005)(8936002)(10290500003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: US5Wd1nt1GBbkgQ5tc0Bk3YvfkqD2dctv/4E9dLbZyfJUGIb/51BluZNDWkHejQIW8/EYiAlcKWD2b1bFuPj2ioHGyMSkuxdF7KI+4jVLPhW9IcDhk6lgwI/aUGN7cTJpmLtthFgIWNutOSI07eaEKHwwrArkl68Mvi1InvN42cOYiSXl8ZG+7fuZ/YKU99qqmOWnJeoeCjHeFiyGgRkHvWQVKUT/LhqRaRSJGuQTjW/2vOkCfe7blsvOxP1mO2oJOpQwEa4ZvXD+6Q6KS8YQvm1RBIJLiunqAfFXE6NVKFeY7H573hnTNRu4gEKMFTe9PqMiVaqYuFahkx02cW7HxVQKkyw/mOVH8eFytBsqbY5odyj2yhEXDhEhcHStHxVxsryLYHQalmupTt9VcOZ7wP7dP1PFzDteoesPhuh05YJtWLAOVLbZVMbT6kAO3vz6zF/BCKIL7kUki6JqlgYmv6wMn8fO2kLfINMA/mo08t+mMA+7CUx8Y7g+jhO5fTDrxqaR+cY0RKLL8j4lASarbxDzDNyfY6UEmKEa7ZATDv8VP8sd0uqWIFA0Hu/jvZ6KAKVWeRl5v+FR2isvcrSQOt/SRgg5TKTbyB3DnVGvI82Z5EprQNqR9GO5VQQaKcJwXgJYvY+3vSv1gVaKKurjQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB067816A0AD84C4DFEA0D8B06F5541CH2PR00MB0678namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70253109-12f4-4b27-665b-08d84a1015a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2020 22:33:41.4247 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IGvMxMB8G8xNngRso5rotAiDGusC+ShPgNkbTclsq5+4aH/w8JXk8xIk1QCZlLBDjbjAaWnhASw2kSsShxfDUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0711 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-cbor-date-tag-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 22:33:49 -0000 --_000_CH2PR00MB067816A0AD84C4DFEA0D8B06F5541CH2PR00MB0678namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS3lsZSwNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2Jvci1k YXRlLXRhZy0wNiBhZGRzIHRoZSBjZXJ0aWZpY2F0ZSBleHBpcmF0aW9uIGV4YW1wbGUgdGhhdCB5 b3Ugc3VnZ2VzdGVkLiAgVGhhbmtzIGFnYWluIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmV2aWV3 IHRoZSBkcmFmdCENCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTWlrZSBKb25lcw0KU2VudDogVGh1cnNkYXks IEF1Z3VzdCAxMywgMjAyMCA1OjQ1IFBNDQpUbzogJ0t5bGUgUm9zZScgPGtyb3NlQGtyb3NlLm9y Zz47IHNlY2RpckBpZXRmLm9yZw0KQ2M6IGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy5hbGxAaWV0 Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZzsgY2JvckBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFNl Y2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wNQ0KDQoN ClRoYW5rcyBmb3IgeW91ciB0aG91Z2h0ZnVsIHJldmlldywgS3lsZS4gIE15IHJlcGxpZXMgdG8g eW91ciBjb21tZW50cyBhcmUgaW5saW5lLi4uDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogS3lsZSBSb3NlIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZzxt YWlsdG86bm9yZXBseUBpZXRmLm9yZz4+DQpTZW50OiBNb25kYXksIEF1Z3VzdCAxMCwgMjAyMCAx MTo0OCBBTQ0KVG86IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPg0KQ2M6 IGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYt Y2Jvci1kYXRlLXRhZy5hbGxAaWV0Zi5vcmc+OyBsYXN0LWNhbGxAaWV0Zi5vcmc8bWFpbHRvOmxh c3QtY2FsbEBpZXRmLm9yZz47IGNib3JAaWV0Zi5vcmc8bWFpbHRvOmNib3JAaWV0Zi5vcmc+DQpT dWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWNib3ItZGF0ZS10 YWctMDUNCg0KDQoNClJldmlld2VyOiBLeWxlIFJvc2UNCg0KUmV2aWV3IHJlc3VsdDogSGFzIE5p dHMNCg0KDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNl Y3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRv Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJl IHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBk aXJlY3RvcnMuDQoNCkRvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQg dGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoN Cg0KDQpUaGlzIGRvY3VtZW50IGlzIHJlYWR5IHdpdGggbml0cy4gSSBzZWUgbm8gaXNzdWVzIG9m IGludGVyZXN0IHRvIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZS4NCg0KDQoNCkkgZG8gaGF2ZSB0 aHJlZSBjb21tZW50cywgaG93ZXZlcjoNCg0KDQoNCiogSW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNlY3Rpb24sIGEgYmV0dGVyIGV4YW1wbGUgbWlnaHQgYmUgdGhlIHBvdGVudGlhbCBp bmFwcHJvcHJpYXRlbmVzcyBvZiB1c2luZyBhbiBpbXByZWNpc2UgbWVjaGFuaXNtIGZvciBzcGVj aWZ5aW5nIGNlcnRpZmljYXRlIGV4cGlyYXRpb24uDQoNCg0KDQpJJ2xsIHBsYW4gdG8gYWRkIHRo aXMgZXhhbXBsZSB3aGVuIGFkZHJlc3Npbmcgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQoN Cg0KKiBJdCdzIG5vdCBjbGVhciBob3cgdGhpcyBpcyBpbnRlbmRlZCB0byB3b3JrIGZvciBkYXRl cyBwcmlvciB0byB0aGUgc3RhcnQgb2YgdGhlIEdyZWdvcmlhbiBjYWxlbmRhciBpbiAxNTgyLiBX aGF0IGRvIG5lZ2F0aXZlIGludGVnZXIgdmFsdWVzIG1lYW4gd2hlbiB0aGV5IGltcGx5IGEgZGF0 ZSBiZWZvcmUgMTUtT2N0LTE1ODI/IElzIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIgZGVmaW5lZCBm b3IgYWxsIHRpbWU/IEluIGEgYnJpZWYgaW52ZXN0aWdhdGlvbiwgSSd2ZSBiZWVuIHVuYWJsZSB0 byBmaW5kIHRoZSBhbnN3ZXIgdG8gdGhpcy4NCg0KDQoNClNlZSB0aGUgc2VjdGlvbiBpbiB0aGUg SW50cm9kdWN0aW9uIG9uIHRoZSByZWxhdGlvbnNoaXAgdG8gdGhlIE1vZGlmaWVkIEp1bGlhbiBE YXRlIHZhbHVlIGFuZCB0aGVuIHNlZSBodHRwczovL2NvcmUyLmdzZmMubmFzYS5nb3YvdGltZS8g Zm9yIHRoZSByZWxhdGlvbnNoaXAgb2YgdGhlIE1vZGlmaWVkIEp1bGlhbiBEYXRlIHRvIHRoZSBK dWxpYW4gRGF0ZSwgYSB0aW1lc2NhbGUgZGVmaW5lZCBieSB0aGUgU21pdGhzb25pYW4gQXN0cm9u b21pY2FsIE9ic2VydmF0b3J5IGJlZ2lubmluZyBhdCBub29uIDEgSmFudWFyeSA0NzEzIEIuQy4g IFRoYXQgc2VlbXMgdG8gZ28gZmFyIGJhY2sgZW5vdWdoIGZvciBtb3N0IHByYWN0aWNhbCBwdXJw b3Nlcy4NCg0KDQoNCkludGVyZXN0aW5nbHksIGFjY29yZGluZyB0byBodHRwczovL2VuLndpa2lw ZWRpYS5vcmcvd2lraS9KdWxpYW5fZGF5Og0KDQrigJxUaGUgTW9kaWZpZWQgSnVsaWFuIERhdGUg KE1KRCkgd2FzIGludHJvZHVjZWQgYnkgdGhlIFNtaXRoc29uaWFuIEFzdHJvcGh5c2ljYWwgT2Jz ZXJ2YXRvcnkgaW4gMTk1NyB0byByZWNvcmQgdGhlIG9yYml0IG9mIFNwdXRuaWsgdmlhIGFuIElC TSA3MDQgKDM2LWJpdCBtYWNoaW5lKSBhbmQgdXNpbmcgb25seSAxOCBiaXRzIHVudGlsIEF1Z3Vz dCA3LCAyNTc2LiBNSkQgaXMgdGhlIGVwb2NoIG9mIFZBWC9WTVMgYW5kIGl0cyBzdWNjZXNzb3Ig T3BlblZNUywgdXNpbmcgNjMtYml0IGRhdGUvdGltZSwgd2hpY2ggYWxsb3dzIHRpbWVzIHRvIGJl IHN0b3JlZCB1cCB0byBKdWx5IDMxLCAzMTA4NiwgMDI6NDg6MDUuNDcuWzE4XSBUaGUgTUpEIGhh cyBhIHN0YXJ0aW5nIHBvaW50IG9mIG1pZG5pZ2h0IG9uIE5vdmVtYmVyIDE3LCAxODU4IGFuZCBp cyBjb21wdXRlZCBieSBNSkQgPSBKRCAtIDI0MDAwMDAuNS7igJ0NCg0KDQoNCiogSW4gYSB2ZXJ5 IGdyb3NzIHNlbnNlLCB0aGlzIHNwZWNpZmljYXRpb24gKmlzKiBhY3R1YWxseSB0aWVkIHRvIHRo ZSBwcmV2YWlsaW5nIHRpbWVzY2FsZSwgbGVhcCBzZWNvbmRzIGFuZCBhbGw6IGlmIHRoZSB3aG9s ZSB3b3JsZCB3ZXJlIHRvIHRyYW5zaXRpb24gZnJvbSBVVEMgdG8gVEFJIGFuZCBzdG9wIGFkZGlu ZyBsZWFwIHNlY29uZHMsIHByZXN1bWFibHkgaW1wbGVtZW50YXRpb25zIHdvdWxkIGNvbnRpbnVl IHRvIGdlbmVyYXRlIGRhdGVzIGZvciB0aGlzIHNwZWNpZmljYXRpb24gYnkgdHJ1bmNhdGluZyB0 aGUgbG9jYWwgdGltZXN0YW1wIHRvIHRoZSBkYXRlLCB3aGljaCB3b3VsZCBjYXVzZSBpdCB0byBk cmlmdCBhbG9uZyB3aXRoIFRBSSBhd2F5IGZyb20gVVRDIG92ZXIgdGltZS4gVGhlcmUgd291bGRu J3QgYmUgYSBodWdlIHByYWN0aWNhbCBlZmZlY3QgaGVyZSBnaXZlbiBob3cgbGl0dGxlIHRoZXkg YXJlIGV4cGVjdGVkIHRvIGRpdmVyZ2Ugb3ZlciB0aGUgZm9yZXNlZWFibGUgZnV0dXJlLCBidXQg aXQgd291bGQgbWVhbiB0aGF0IGRhdGVzIGVuY29kZWQgaW4gdGhpcyBmb3JtYXQgdG9kYXkgd291 bGQgbm90IGNhcnJ5IGVub3VnaCBpbmZvcm1hdGlvbiB0byBwcmVjaXNlbHkgaW5kaWNhdGUgYSBk YXRlIGluIHRoZSBmYXIgZnV0dXJlIGV2ZW4gaWYgdGhlIHRhcmdldCB0aW1lc2NhbGUgd2VyZSB1 bmRlcnN0b29kIHRocm91Z2hvdXQgc2luY2UgdGhlIHNvdXJjZSB0aW1lc2NhbGUgaXNuJ3QgcGFy dCBvZiB0aGUgZW5jb2RpbmcuDQoNCg0KDQpJZiBpdOKAmXMgZ29vZCBlbm91Z2ggZm9yIHRoZSBT bWl0aHNvbmlhbiBBc3Ryb25vbWljYWwgT2JzZXJ2YXRvcnkgKGFsYmVpdCwgdXRpbGl6aW5nIGEg ZGVmaW5lZCBpbnRlZ2VyIG9mZnNldCksIGl04oCZcyBnb29kIGVub3VnaCBmb3IgbWUuIDstKSAg VGltZWtlZXBpbmcgaXMgdWx0aW1hdGVseSBhIGh1bWFuIGN1bHR1cmFsIGVuZGVhdm9yIGFuZCBp dOKAmXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24gdG8gcHJvYmUgaXRz IG1hbnkgdmFyaWF0aW9ucyBhbmQgZm9pYmxlcy4gIFRoZSBlc3NlbmNlIG9mIGRhdGVzIGlzIHRo YXQgZWFjaCB0aW1lIHRoZSB3b3JsZCBnb2VzIHJvdW5kLCB0aGVzZSB2YWx1ZXMgaW5jcmVtZW50 LiAgVGhhdCBzYWlkLCBpZiB5b3UgaGF2ZSBzcGVjaWZpYyB0ZXh0IHlvdeKAmWQgbGlrZSB0byBz ZWUgYWRkZWQsIEnigJltIG9wZW4gdG8gaXQuDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVzdCB3aXNoZXMsDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN Cg0KDQpQLlMuICBJIG5ldmVyIGV4cGVjdGVkIHRoYXQgd3JpdGluZyB0aGlzIHZlcnkgc2ltcGxl IHNwZWNpZmljYXRpb24gd291bGQgcmVzdWx0IGluIHN1Y2ggaW50ZXJlc3RpbmcgZGlzY3Vzc2lv bnMgYWJvdXQgdGltZWtlZXBpbmchDQoNCg0K --_000_CH2PR00MB067816A0AD84C4DFEA0D8B06F5541CH2PR00MB0678namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1 NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5IaSBLeWxlLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jYm9y LWRhdGUtdGFnLTA2Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jYm9y LWRhdGUtdGFnLTA2PC9hPiBhZGRzIHRoZSBjZXJ0aWZpY2F0ZSBleHBpcmF0aW9uIGV4YW1wbGUg dGhhdCB5b3Ugc3VnZ2VzdGVkLiZuYnNwOyBUaGFua3MgYWdhaW4gZm9yIHRha2luZyB0aGUgdGlt ZSB0byByZXZpZXcgdGhlIGRyYWZ0ITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBNaWtlIEpvbmVzIDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDEz LCAyMDIwIDU6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+ICdLeWxlIFJvc2UnICZsdDtrcm9zZUBrcm9z ZS5vcmcmZ3Q7OyBzZWNkaXJAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYtY2Jv ci1kYXRlLXRhZy5hbGxAaWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZzsgY2JvckBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTA1PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5UaGFua3MgZm9yIHlvdXIgdGhvdWdodGZ1bCByZXZpZXcsIEt5bGUuJm5ic3A7 IE15IHJlcGxpZXMgdG8geW91ciBjb21tZW50cyBhcmUgaW5saW5lLi4uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogS3ls ZSBSb3NlIHZpYSBEYXRhdHJhY2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5v cmciPm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGJyPg0KU2VudDogTW9uZGF5LCBBdWd1c3Qg MTAsIDIwMjAgMTE6NDggQU08YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9y ZyI+c2VjZGlyQGlldGYub3JnPC9hPjxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0 Zi1jYm9yLWRhdGUtdGFnLmFsbEBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLmFs bEBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86bGFzdC1jYWxsQGlldGYub3JnIj5sYXN0 LWNhbGxAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86Y2JvckBpZXRmLm9yZyI+DQpjYm9y QGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRy YWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wNTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5S ZXZpZXdlcjogS3lsZSBSb3NlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5SZXZpZXcgcmVzdWx0OiBIYXMgTml0czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5J IGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJl Y3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVp bmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiZuYnNwOyBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0 ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3Rv cnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Eb2N1bWVudCBlZGl0 b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBh bnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5UaGlzIGRvY3VtZW50IGlzIHJlYWR5IHdpdGggbml0cy4gSSBzZWUgbm8gaXNzdWVzIG9mIGlu dGVyZXN0IHRvIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+SSBkbyBoYXZlIHRocmVlIGNvbW1lbnRzLCBob3dldmVyOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4qIEluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9u LCBhIGJldHRlciBleGFtcGxlIG1pZ2h0IGJlIHRoZSBwb3RlbnRpYWwgaW5hcHByb3ByaWF0ZW5l c3Mgb2YgdXNpbmcgYW4gaW1wcmVjaXNlIG1lY2hhbmlzbSBmb3Igc3BlY2lmeWluZyBjZXJ0aWZp Y2F0ZSBleHBpcmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkknbGwgcGxhbiB0byBhZGQgdGhpcyBleGFtcGxlIHdoZW4gYWRkcmVz c2luZyBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4qIEl0J3Mgbm90IGNs ZWFyIGhvdyB0aGlzIGlzIGludGVuZGVkIHRvIHdvcmsgZm9yIGRhdGVzIHByaW9yIHRvIHRoZSBz dGFydCBvZiB0aGUgR3JlZ29yaWFuIGNhbGVuZGFyIGluIDE1ODIuIFdoYXQgZG8gbmVnYXRpdmUg aW50ZWdlciB2YWx1ZXMgbWVhbiB3aGVuIHRoZXkgaW1wbHkgYSBkYXRlIGJlZm9yZSAxNS1PY3Qt MTU4Mj8gSXMgdGhlIEdyZWdvcmlhbiBjYWxlbmRhciBkZWZpbmVkIGZvciBhbGwgdGltZT8NCiBJ biBhIGJyaWVmIGludmVzdGlnYXRpb24sIEkndmUgYmVlbiB1bmFibGUgdG8gZmluZCB0aGUgYW5z d2VyIHRvIHRoaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+U2VlIHRoZSBzZWN0aW9uIGluIHRoZSBJbnRyb2R1Y3Rpb24gb24gdGhlIHJl bGF0aW9uc2hpcCB0byB0aGUgTW9kaWZpZWQgSnVsaWFuIERhdGUgdmFsdWUgYW5kIHRoZW4gc2Vl DQo8YSBocmVmPSJodHRwczovL2NvcmUyLmdzZmMubmFzYS5nb3YvdGltZS8iPmh0dHBzOi8vY29y ZTIuZ3NmYy5uYXNhLmdvdi90aW1lLzwvYT4gZm9yIHRoZSByZWxhdGlvbnNoaXAgb2YgdGhlIE1v ZGlmaWVkIEp1bGlhbiBEYXRlIHRvIHRoZSBKdWxpYW4gRGF0ZSwgYSB0aW1lc2NhbGUgZGVmaW5l ZCBieSB0aGUgU21pdGhzb25pYW4gQXN0cm9ub21pY2FsIE9ic2VydmF0b3J5IGJlZ2lubmluZyBh dCBub29uIDEgSmFudWFyeSA0NzEzIEIuQy4mbmJzcDsgVGhhdA0KIHNlZW1zIHRvIGdvIGZhciBi YWNrIGVub3VnaCBmb3IgbW9zdCBwcmFjdGljYWwgcHVycG9zZXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkludGVyZXN0aW5nbHksIGFjY29yZGluZyB0byA8YSBocmVm PSJodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9KdWxpYW5fZGF5Ij4NCmh0dHBzOi8vZW4u d2lraXBlZGlhLm9yZy93aWtpL0p1bGlhbl9kYXk8L2E+OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPuKAnFRoZSBNb2RpZmllZCBKdWxpYW4gRGF0ZSAoTUpEKSB3YXMg aW50cm9kdWNlZCBieSB0aGUgU21pdGhzb25pYW4gQXN0cm9waHlzaWNhbCBPYnNlcnZhdG9yeSBp biAxOTU3IHRvIHJlY29yZCB0aGUgb3JiaXQgb2YgU3B1dG5payB2aWEgYW4gSUJNIDcwNCAoMzYt Yml0IG1hY2hpbmUpIGFuZCB1c2luZyBvbmx5IDE4IGJpdHMNCiB1bnRpbCBBdWd1c3QgNywgMjU3 Ni4gTUpEIGlzIHRoZSBlcG9jaCBvZiBWQVgvVk1TIGFuZCBpdHMgc3VjY2Vzc29yIE9wZW5WTVMs IHVzaW5nIDYzLWJpdCBkYXRlL3RpbWUsIHdoaWNoIGFsbG93cyB0aW1lcyB0byBiZSBzdG9yZWQg dXAgdG8gSnVseSAzMSwgMzEwODYsIDAyOjQ4OjA1LjQ3LlsxOF0gVGhlIE1KRCBoYXMgYSBzdGFy dGluZyBwb2ludCBvZiBtaWRuaWdodCBvbiBOb3ZlbWJlciAxNywgMTg1OCBhbmQgaXMgY29tcHV0 ZWQgYnkgTUpEDQogPSBKRCAtIDI0MDAwMDAuNS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiogSW4gYSB2ZXJ5 IGdyb3NzIHNlbnNlLCB0aGlzIHNwZWNpZmljYXRpb24gKmlzKiBhY3R1YWxseSB0aWVkIHRvIHRo ZSBwcmV2YWlsaW5nIHRpbWVzY2FsZSwgbGVhcCBzZWNvbmRzIGFuZCBhbGw6IGlmIHRoZSB3aG9s ZSB3b3JsZCB3ZXJlIHRvIHRyYW5zaXRpb24gZnJvbSBVVEMgdG8gVEFJIGFuZCBzdG9wIGFkZGlu ZyBsZWFwIHNlY29uZHMsIHByZXN1bWFibHkgaW1wbGVtZW50YXRpb25zIHdvdWxkIGNvbnRpbnVl DQogdG8gZ2VuZXJhdGUgZGF0ZXMgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbiBieSB0cnVuY2F0aW5n IHRoZSBsb2NhbCB0aW1lc3RhbXAgdG8gdGhlIGRhdGUsIHdoaWNoIHdvdWxkIGNhdXNlIGl0IHRv IGRyaWZ0IGFsb25nIHdpdGggVEFJIGF3YXkgZnJvbSBVVEMgb3ZlciB0aW1lLiBUaGVyZSB3b3Vs ZG4ndCBiZSBhIGh1Z2UgcHJhY3RpY2FsIGVmZmVjdCBoZXJlIGdpdmVuIGhvdyBsaXR0bGUgdGhl eSBhcmUgZXhwZWN0ZWQgdG8gZGl2ZXJnZSBvdmVyDQogdGhlIGZvcmVzZWVhYmxlIGZ1dHVyZSwg YnV0IGl0IHdvdWxkIG1lYW4gdGhhdCBkYXRlcyBlbmNvZGVkIGluIHRoaXMgZm9ybWF0IHRvZGF5 IHdvdWxkIG5vdCBjYXJyeSBlbm91Z2ggaW5mb3JtYXRpb24gdG8gcHJlY2lzZWx5IGluZGljYXRl IGEgZGF0ZSBpbiB0aGUgZmFyIGZ1dHVyZSBldmVuIGlmIHRoZSB0YXJnZXQgdGltZXNjYWxlIHdl cmUgdW5kZXJzdG9vZCB0aHJvdWdob3V0IHNpbmNlIHRoZSBzb3VyY2UgdGltZXNjYWxlIGlzbid0 IHBhcnQNCiBvZiB0aGUgZW5jb2RpbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SWYgaXTigJlzIGdvb2QgZW5vdWdoIGZvciB0aGUgU21p dGhzb25pYW4gQXN0cm9ub21pY2FsIE9ic2VydmF0b3J5IChhbGJlaXQsIHV0aWxpemluZyBhIGRl ZmluZWQgaW50ZWdlciBvZmZzZXQpLCBpdOKAmXMgZ29vZCBlbm91Z2ggZm9yIG1lLiA7LSkgJm5i c3A7VGltZWtlZXBpbmcgaXMgdWx0aW1hdGVseSBhIGh1bWFuIGN1bHR1cmFsIGVuZGVhdm9yIGFu ZCBpdOKAmXMgYmV5b25kDQogdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiB0byBwcm9i ZSBpdHMgbWFueSB2YXJpYXRpb25zIGFuZCBmb2libGVzLiZuYnNwOyBUaGUgZXNzZW5jZSBvZiBk YXRlcyBpcyB0aGF0IGVhY2ggdGltZSB0aGUgd29ybGQgZ29lcyByb3VuZCwgdGhlc2UgdmFsdWVz IGluY3JlbWVudC4mbmJzcDsgVGhhdCBzYWlkLCBpZiB5b3UgaGF2ZSBzcGVjaWZpYyB0ZXh0IHlv deKAmWQgbGlrZSB0byBzZWUgYWRkZWQsIEnigJltIG9wZW4gdG8gaXQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBCZXN0IHdpc2hlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QLlMuJm5ic3A7IEkgbmV2 ZXIgZXhwZWN0ZWQgdGhhdCB3cml0aW5nIHRoaXMgdmVyeSBzaW1wbGUgc3BlY2lmaWNhdGlvbiB3 b3VsZCByZXN1bHQgaW4gc3VjaCBpbnRlcmVzdGluZyBkaXNjdXNzaW9ucyBhYm91dCB0aW1la2Vl cGluZyE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_CH2PR00MB067816A0AD84C4DFEA0D8B06F5541CH2PR00MB0678namp_-- From nobody Wed Aug 26 20:14:26 2020 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 D91233A0CA7; Wed, 26 Aug 2020 20:14:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Brian Weis via Datatracker To: Cc: draft-ietf-spring-srv6-network-programming.all@ietf.org, spring@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159849805983.7699.460089427690333419@ietfa.amsl.com> Reply-To: Brian Weis Date: Wed, 26 Aug 2020 20:14:19 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-spring-srv6-network-programming-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 03:14:20 -0000 Reviewer: Brian Weis Review result: Has Nits This document is titled “SRv6 Network Programming”, which is attention grabbing. It fleshes out how Segment Routing routes IPv6 packets by Segment ID (SID), as well as defining the format of a SID for IPv6. The Introduction states, “An ingress node steers a packet through an ordered list of instructions, called segments.” When one considers this statement along with the document title, it’s apparent that network devices are indeed being given “instructions” in the programming sense, where each “instruction” is encoded in an IPv6 address. An “instruction” (i.e., SRv6 SID) comprises a locator (which is used to route to a particular network device), and also directs the network device acting as the locator how to process the IPv6 packet. With the help of an IPv6 Segment Routing Header (SRH) header, a series of “instructions” can source route a packet through the network, where each network device acting as a locator learns how to handle the packet before possibly sending it on to the next SID (if any). The encoding of an IPv6 address as an SRv6 SID includes a locator, a code indicating a certain function, and optionally arguments to that function. An initial set of codes (and their associated algorithms) is defined in this document. Most of the codes describe how the egress router should decapsulate the packet, with might include defining which routing table the receiving router should look up after decapsulation. The Security Considerations section points to the Security Considerations of the architecture document and the SRH document. Both documents focus on the fact that SRv6 is intended to be used within a single domain (e.g., provider network) and discuss routing mitigations such as filtering external traffic appropriately. They seem to assume that the boundaries of the domain itself are inviolate such that the domain boundary devices are not subverted, and that there are no bad actors within the domain. These are common assumptions for service provider networks where Segment Routing is intended to be deployed. However, it cannot be certain that all networks deploying Service Routing to be free of bad actors, and there will certainly be some benefit to a bad actor changing “instructions” encoded in IPv6 addresses. Perhaps there is opportunity for mischief in changing the routing table argument in an End.DT46, for example. Also, as other SRv6 functions are defined (e.g., packet inspection functions), it would be important to ensure that those SIDs are not modified to avoid or decrease the quality of those inspection functions. The SRH document does describe an HMAC TLV that is intended to mitigate these kinds of attacks. Since neither of the referenced documents Security Considerations mention it, it would be a good idea to describe here that there are threats to changing SIDs, and point out how to mitigate them with the HMAC TLV. Also, if I’m not mistaken, when there is just one SID then it is placed in the IPv6 DA and there is no SRH header or HMAC TLV. This is a general problem with ensuring that the DA on packets are not changed in transit, and one could use IPsec to mitigate that issue. It’s probably worthwhile mentioning something like that. From nobody Thu Aug 27 04:53:51 2020 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 4342A3A0C13 for ; Thu, 27 Aug 2020 04:53:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <159852922983.2299.4263200695366613849@ietfa.amsl.com> Date: Thu, 27 Aug 2020 04:53:50 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 11:53:50 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-08-27 Reviewer LC end Draft Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-09 For telechat 2020-09-10 Reviewer LC end Draft Watson Ladd R2020-03-13 draft-ietf-detnet-mpls-11 Last calls: Reviewer LC end Draft Derek Atkins 2020-09-04 draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-09 Dan Harkins None draft-ietf-rtgwg-policy-model-03 Russ Housley R2020-09-08 draft-ietf-lwig-curve-representations-12 Watson Ladd R2020-03-13 draft-ietf-detnet-mpls-11 David Mandelberg 2020-07-14 draft-ietf-idr-rfc8203bis-06 Kathleen Moriarty 2020-07-20 draft-ietf-ace-oscore-profile-11 Russ Mundy 2020-07-20 draft-ietf-ace-dtls-authorize-12 Yoav Nir None draft-ietf-netconf-trust-anchors-13 Tirumaleswar Reddy.K 2020-08-18 draft-ietf-roll-turnon-rfc8138-10 Vincent Roca 2020-04-23 draft-ietf-detnet-ip-over-mpls-06 Rich Salz 2020-08-14 draft-ietf-suit-architecture-11 Sean Turner 2020-09-02 draft-ietf-lamps-ocsp-nonce-03 Mališa Vučinić 2020-08-28 draft-ietf-bess-evpn-na-flags-05 Carl Wallace 2020-08-26 draft-ietf-stir-cert-delegation-03 Samuel Weiler 2020-08-26 draft-ietf-mpls-spl-terminology-03 Klaas Wierenga 2020-09-09 draft-ietf-v6ops-slaac-renum-03 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-09 Christopher Wood 2020-09-09 draft-ietf-v6ops-cpe-slaac-renum-04 Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model-08 Paul Wouters 2020-05-25 draft-ietf-capport-architecture-09 Liang Xia 2020-09-04 draft-ietf-v6ops-nd-cache-init-04 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Nancy Cam-Winget Shaun Cooley Alan DeKok Linda Dunbar Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Phillip Hallam-Baker From nobody Thu Aug 27 06:03:56 2020 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 577753A0819; Thu, 27 Aug 2020 06:03:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Samuel Weiler via Datatracker To: Cc: last-call@ietf.org, draft-ietf-mpls-spl-terminology.all@ietf.org, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159853342829.4954.15202194373803926022@ietfa.amsl.com> Reply-To: Samuel Weiler Date: Thu, 27 Aug 2020 06:03:48 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mpls-spl-terminology-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 13:03:49 -0000 Reviewer: Samuel Weiler Review result: Ready None to see here; move along. This clarifies the name of an IANA registry and explains why such clarification is needed. There is no security impact. From nobody Thu Aug 27 09:11:31 2020 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 4D29E3A0FE9; Thu, 27 Aug 2020 09:11:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: last-call@ietf.org, draft-ietf-suit-architecture.all@ietf.org, suit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159854468417.31349.14137152546699566319@ietfa.amsl.com> Reply-To: Rich Salz Date: Thu, 27 Aug 2020 09:11:24 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-suit-architecture-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 16:11:25 -0000 Reviewer: Rich Salz Review result: Ready The security directorate tries to review all IETF documents prior to IESG review. This should be considered as input to the security AD's, or otherwise general Last Call comments. I apologize for the lateness of this review. Hopefully since a new draft is expected, this might be useful anyway. This is READY (reasonable folks may disagree of course). There are no nits that aren't already covered. I have some suggestions: - I wish the terminology were in alphabetical order. - The requirements list should say "each is covered in more detail in the following subsections" or similar. The topic, updating firmware on IoT devices, is very important. The document defines requirements, explains why, and then describes an architecture that could meet those requirements. Examples cover a variety of instantiations. I think this is the first time I have seen a ladder diagram for processing steps, as opposed to protocol interchanges. This is a very well-written document. From nobody Thu Aug 27 09:31:23 2020 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 5ADD83A1068 for ; Thu, 27 Aug 2020 09:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAHH0IM6fZsd for ; Thu, 27 Aug 2020 09:31:20 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 A07953A1063 for ; Thu, 27 Aug 2020 09:31:20 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07RGVDhV019925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2020 12:31:18 -0400 Date: Thu, 27 Aug 2020 09:31:13 -0700 From: Benjamin Kaduk To: Robert Sparks Cc: secdir@ietf.org Message-ID: <20200827163113.GO16914@kduck.mit.edu> References: <159708756719.15053.15537532147789441272@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <159708756719.15053.15537532147789441272@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lamps-cms-update-alg-id-protect-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 16:31:22 -0000 Thanks, Robert; I entered a No Objection ballot with some more basically editorial remarks. -Ben On Mon, Aug 10, 2020 at 12:26:07PM -0700, Robert Sparks via Datatracker wrote: > Reviewer: Robert Sparks > 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. > > This document is ready for publication as Proposed Standard RFC. > > >From the abstract: > > > This document updates the Cryptographic Message Syntax (CMS) > > specified in RFC 5652 to ensure that algorithm identifiers in signed- > > data and authenticated-data content types are adequately protected. > > I sent minor nits directly to the editor. > > > From nobody Thu Aug 27 12:35:14 2020 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 173F53A1251; Thu, 27 Aug 2020 12:35:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: last-call@ietf.org, lwip@ietf.org, draft-ietf-lwig-curve-representations.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159855690603.24456.6910199800419438393@ietfa.amsl.com> Reply-To: Russ Housley Date: Thu, 27 Aug 2020 12:35:06 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lwig-curve-representations-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 19:35:06 -0000 Reviewer: Russ Housley Review result: Ready I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-lwig-curve-representations-12 Reviewer: Russ Housley Review Date: 2020-08-27 IETF LC End Date: 2020-09-08 IESG Telechat date: unknown Thank you for addressing my earlier comments on -08. Summary: Ready Major Concerns: None Minor Concerns: None Nits: The Introduction talks about the traditional "short" Weierstrass curve model, and then most everywhere else talks about short-Weierstrass form. Can one phrase be used throughout? Question: Is support for these curves with in PKIX certificates (see RFC 5280 and RFC 5480) and CMS (see RFC 5652 and RFC 5753) as simple as assigning an object identifier for the two named curves? If so, can Section 10 be expanded to cover these too? From nobody Sat Aug 29 15:03:18 2020 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 B7B993A10F5; Sat, 29 Aug 2020 15:03:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd via Datatracker To: Cc: last-call@ietf.org, draft-ietf-detnet-mpls.all@ietf.org, detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159873859265.10254.15047947315298424271@ietfa.amsl.com> Reply-To: Watson Ladd Date: Sat, 29 Aug 2020 15:03:12 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-detnet-mpls-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 22:03:13 -0000 Reviewer: Watson Ladd Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is has nits. First the good parts: this document has a very well-thought Security Considerations section that describes the threats unique to this setting and makes a reference to an upcoming architecture draft. However, I found analysis of how the protocol should be deployed or configured or is designed to address those threats to be lacking in a few places. The discussion of DOS attacks is good: it says to avoid impacts on the DetNet services traffic must be policed or dropped at the edge. I would like to see a similar statement made about the consequences and mitigations for interior network corruption. It reads almost like a sentence or two was inadvertently deleted. However, if I understand the MPLS architecture correctly a compromised node can inject a label stack that results in interference with the DetNet flows, and this is quite difficult to avoid in the general case. I'm not knowledgeable in this area by any means. Perhaps it's necessary to say that all the MPLS nodes are assumed to be trusted and otherwise the DetNet services cannot be provided. I think this can be addressed pretty quickly. Sincerely, Watson Ladd From nobody Sun Aug 30 19:01:32 2020 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 6599C3A0C9D; Sun, 30 Aug 2020 19:01:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia via Datatracker To: Cc: draft-ietf-v6ops-nd-cache-init.all@ietf.org, v6ops@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159883928237.28454.12784503452648077331@ietfa.amsl.com> Reply-To: Liang Xia Date: Sun, 30 Aug 2020 19:01:22 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-v6ops-nd-cache-init-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 02:01:23 -0000 Reviewer: Liang Xia Review result: Ready This document discusses how the neighbor discovery state machine on a first-hop router is causing user-visible connectivity issues when a new (not being seen on the network before) IPv6 address is being used. As described in the Security Considerations, it documents the operational issue and does not introduce any new security considerations. From nobody Mon Aug 31 04:43:14 2020 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 A9ACD3A12A0 for ; Mon, 31 Aug 2020 04:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 Zve3ZhJPM5sC for ; Mon, 31 Aug 2020 04:43:11 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 7719B3A129E for ; Mon, 31 Aug 2020 04:43:11 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id v54so2966836qtj.7 for ; Mon, 31 Aug 2020 04:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=x2cvn3rctiENL93z7Z0Wt28DE3/+ueo6Z3VyVHVYc3A=; b=uz7lxFxpI6gpFdyVT4QriRM43JuUd23qAR6bjGEpoiTqoqGdNeulpQfte9QHRx/Cpf YqAooS94d4Ab17NPLJUYuCP9aNDnkd+u86GdGzNr2ss/8yf5LUbg6w1xka9f56VoNady /owpVcWGG1Wb2w5K+/FwsoJ/qu4e7zyT0WRGs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=x2cvn3rctiENL93z7Z0Wt28DE3/+ueo6Z3VyVHVYc3A=; b=mRFirh789NpIBFZX1u0c4hcK4M9kG+jk5Pl/Ko3aE1Congpi8gzbnMyD9YpRLkHlRz /s/DFM7TGfPZvGMdig1SjNsQ2+937wMrxkIrKljvbGuB469RO8uYVh1wkLgTgL1yDeZ/ vXnl1p08TWbPDlobnnk9NmeB63S4hoa1N+Uqv5FCXoAfZyCeklHBZbw1SqlhSXT5UnuZ bKfnWgIbgufj1E/DcoB8GGlPQChqNxDpXFC2L+XwElMYwstPAS6hYJswcrMWywYyX9TC k+eTnBkko8p/9iDJjBqzk+ioj1qCNR/j6Po4AFOSHpjDOpKLCvPPWfoTSsmH6k6aGGit 2pmA== X-Gm-Message-State: AOAM531HvvkCcJMqSb5CRgTEH7J6OuaXql5eAkjNdJeFAAM5Dn468PUB hcja9TJzN7eULM5rLZFF6ckhFY2pGq2PihLj X-Google-Smtp-Source: ABdhPJzNwFjYUsSoLIb+xzRieGMFdXT+RPcgg56246UZjLbnSA+xfq9U9/UvbWXk4RTH6ltX3Ee9bw== X-Received: by 2002:ac8:411b:: with SMTP id q27mr792857qtl.255.1598874190113; Mon, 31 Aug 2020 04:43:10 -0700 (PDT) Received: from [192.168.2.18] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id v56sm3887386qtc.49.2020.08.31.04.43.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Aug 2020 04:43:09 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.10.19.200810 Date: Mon, 31 Aug 2020 07:43:09 -0400 From: Carl Wallace To: , , Message-ID: <0A4A83A8-8090-4F5A-9380-3408B8986114@redhoundsoftware.com> Thread-Topic: secdir review of draft-ietf-stir-cert-delegation-03 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-stir-cert-delegation-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 11:43:13 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how authority over telephone numbers and related identifiers can be delegated from a parent certificate to a subordinate certificate. I am not versed in STIR but have a few questions and comments: 1) Section 4 states "STIR delegate certificates are certificates containing a TNAuthList object that have been signed with the private key of a parent certificate that itself contains a TNAuthList object." Section 4.1 references the use of "by-reference rather than by value, where a URL in the certificate points to a secure, dynamically-updated list of the telephone numbers in the scope of authority of a certificate". If the statement requiring inclusion of the TNAuthList extension is intended to preclude the AIA-based by-reference approach, this should be clearly stated. If this is not the intent, then the statement should be generalized to allow for either mechanism. 2) Assuming by-reference is intended, section 4.1 should include some guidance re: when the encompassing check must be performed. The current language states the check "might be performed at the time the delegate certificate is issued, or at the time that a verification service receives an inbound call, or potentially both." 3) Some discussion of handling certification paths with both TNAuthList extensions and AIA-based by-reference objects is likely needed. 4) Why is the authority token draft in the informative section instead of normative? ACME itself is in the normative and the importance of this draft to the setting of basic constraints may justify listing as normative and citing it in the security considerations section.