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
