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 <[email protected]> wrote: > > 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
