Subject: [Lwip] Secdir early review of draft-ietf-lwig-curve-representations-08

From: Russ Housley via Datatracker <[email-masked]>
Date: Tue, 26 Nov 2019 09:58:22 -0800

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 subsections.

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.

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.

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.

I expected Section 9 to say something about public keys being unique
identifiers of the private key holder.

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.

Nits:

Section 4.2 says: "... at the end of hereof ...".  This does not tell
me anything useful.  I suggest deleting this phrase.

I suggest turning the numbered paragraphs in Section 5 into subsections.

---

From: Rene Struik <[email-masked]>
Date: Tue, 26 Nov 2019 14:54:30 -0500

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:
> and JOSE (not object identifiers) are requested in the subsection.
>

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

>     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all

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

> 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
> 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

> 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
> 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 suggest turning the numbered paragraphs in Section 5 into subsections.
RS>> Will do. <<RS

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Russ Housley <[email-masked]>
Date: Tue, 26 Nov 2019 16:10:54 -0500

> On Nov 26, 2019, at 2:54 PM, Rene Struik <[email-masked]> wrote:
> 
> Dear Russ:
> 
> 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
> 
> 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>> 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>> 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.

> 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>> 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.

> 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 ..."

Russ

---

From: Rene Struik <[email-masked]>
Date: Tue, 26 Nov 2019 17:21:16 -0500

Hi Russ:

Thanks.

> 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

> RFC 8174 calls for this exact text.
RS>> My remark above was more a "Strunk and White" remark. <<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