Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> writes:
> Hi Mark,
>
> Please see inline. I have removed the comments where your suggested
> solution is fine and I have nothing further to say.
I have done likewise.
> 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.
....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.
....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.
>
> ---
>
> 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.
-- Mark
