Rene: It is not a gatekeeper of any sort.
I will not be able to another review for a couple of weeks. You have asked at a particularly busy time for me. Russ > On Jul 14, 2020, at 1:45 PM, Rene Struik <[email protected]> wrote: > > Hi Russ: > > 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. > > 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/# > > For the current draft, see > https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/ > > I am looking forward hearing back from you. > > Best regards, Rene > > On 2020-03-10 11:19 a.m., Rene Struik wrote: >> Hi Russ: >> >> I tried to take into account your comments with >> draft-ietf-lwig-curve-representations-09. >> >> I will send out a separate email to the list highlighting main changes. >> >> Below, I will explain how I tried and accommodate your previous comments on >> the 08-draft, now that the new draft is out. >> >> 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).} >> >> >> Best regards, Rene >> >> On 11/26/2019 5:21 PM, Rene Struik wrote: >>> Hi Russ: >>> >>> Thanks. >>> >>> On 11/26/2019 4:10 PM, Russ Housley wrote: >>>> >>>>> On Nov 26, 2019, at 2:54 PM, Rene Struik <[email protected]> wrote: >>>>> >>>>> Dear Russ: >>>>> >>>>> Thanks for your review (and speedy turn-around). >>>>> >>>>> 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). >>>>> >>>>> Best regards, Rene >>>>> >>>>> On 11/26/2019 12:58 PM, Russ Housley via Datatracker wrote: >>>>>> Reviewer: Russ Housley >>>>>> Review result: Has Issues >>>>>> >>>>>> 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-08 >>>>>> Reviewer: Russ Housley >>>>>> Review Date: 2019-11-26 >>>>>> IETF LC End Date: unknown >>>>>> IESG Telechat date: unknown >>>>>> >>>>>> Summary: Has Issues >>>>>> >>>>>> >>>>>> Major Concerns: >>>>>> >>>>>> 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. >>>>>> >>>>>> 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." >>>>> >>>>> <<RS >>>> I do not see how the second paragraph gives any direction regarding the >>>> IANA registries. >>> >>> 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. From a >>> Spartan writing perspective, it could indeed be argued that one could guess >>> this oneself. <<RS >> >> 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: >> >> 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. >> >> <<RS1 >> >>> >>>> >>>>>> Minor Concerns: >>>>>> >>>>>> Requirements Language section is out of date. It should reference >>>>>> RFC 8174 in addition to RFC 2119, as follows: >>>>>> >>>>>> 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...."? <<RS >>>> RFC 8174 calls for this exact text. >>> RS>> My remark above was more a "Strunk and White" remark. <<RS >> RS1>> Changed, as requested. <<RS1 >>>> >>>>>> 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).)" <<RS >>>> Thanks. >>>> >>>>>> 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." <<RS >>>> 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). <<RS >> >> RS1>>The added text now reads as follows: >> >> 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. >> >> <<RS1 >> >>>> >>>>>> 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. <<RS >>>> Yes, I understand that. Some of the appendicies have introductory text, >>>> but other do not. I think they all should have introductory text. >> >> RS1>> I added some introductory text to each appendix. >> >> <<RS1 >> >>>> >>>>>> Nits: >>>>>> >>>>>> 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. <<RS >>>> I think it would be better to say: ... at the end of the Montgomery ladder >>>> ..." >> RS1>> Changed as suggested. <<RS1 >>>> >>>> Russ >>>> >>> >> > > -- > email: [email protected] | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 > _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
