|
Hi Mark,
Section 1:
----------- >> Q1_1: >> ...elided... >>> RFC5656 covers three specific constructions: >>> >>> a) Elliptic Curve Diffie-Hellman (ECDH),> >>> b) Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and >>> c) Elliptic Curve Digital Signature Algorithm (ECDSA). >>> >>> This draft does not cover the use of a digital signature algoirthm >>> or apply the Curve25519 or Curve448 constructions to the use of >>> ECMQV and focuses entirely on ECDH key exchange extensions for a >>> different construction of elliptic curves. >> >> Would it be good to indicate that in a note? > > Possibly. I could add this as the final sentence to the first paragraph > of the introduction: > > Other parts of <xref target="RFC5656"/>, such as Elliptic Curve > Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve > Digital Signature Algorithm (ECDSA) are not considered in this > document. Looks good.
...elided... >>> It seems a bit detailed to me for an introduction. Let me know if >>> you have any suggestions on a revision. >> >> I think the text looks good, and it is for sure a good clarification >> for a non-security person like myself :) > > Okay, I will keep at as revised with the only other question being the > addition of the sentence noted previously. Ok.
...elided... >> Personally I would use "describe", but my main issue is being >> consistent - no matter what word is used :) > > I will retain the 'This document defines...' text. > > I believe that there is a difference between defines and describes. The > former is normative text and the latter is more informative. Sure, and if you think there are situations where you want to use both, that's fine. But, often people just use the word that comes to their mind when writing (or adding text written by someone else), and that causes the inconsistence
in terminology.
---
Q1_5: >>>> The text says: >>>> >>>> >>>> “This document provide Curve25519 as the preferred choice, but >>>> suggests that the fall back option Curve448 is implemented to provide >>>> an hedge against unforeseen analytical advances against Curve25519 >>>> and SHA-256.” >>>> >>>> - Is the only reason why one should implement Curve448 that something >>>> MAY happen to Curve25519 in the future? >>> >>>No, the Curve448 also has a stronger cryptographic security strength. If >>>it becomes a requirement to use a minimum of 128 bits of security >>>strength, then Curve25519 may be rejected by some and thus the need to >>> provide for something stronger. >> >> Wouldn't it be enough to say that, instead of talking about unforeseen >> analytical advances etc? I noted that the sec-dir reviewer had some >> comments on that too. >> >> Please see below for suggested modified text. >> >>> Let me know if you which to have me remove the entire paragraph or not. >> >> I think you could keep the paragraph, but instead say something like: >> >> “This document provide Curve25519 as the preferred choice, but >> suggests that the Curve448 is implemented in order to provide >> 128 bits of security strength, should that become a requirement. >> >> At the time of writing this specification high-quality free >> implementations of Curve25519 had been in deployed use for >> several years, while Curve448 implementations were slowly >> appearing, so it was accepted that adoption of Curve448 >> would be slower." >> >>> Should I upload my updated draft-ietf-curdle-ssh-curves-10.xml or >>> do you have additional suggestions? > > I have adopted your two paragraphs to replace the one paragraph that was > previously present. > >> I haven't seen the update draft yet, but if you are ok with my >> suggestions you can go ahead to upload. If you are not ok with my >> suggestions, then let me know :) > > Only one questions remains as the last sentence of the first paragarph > of the introduction. The text you suggested looks good.
So, as far as I'm concerned, go ahead and make the change and submit the -10 version
🙂
Regards,
Christer
|
