Re: [Gen-art] Genart last call review of draft-ietf-curdle-ssh-curves-09

["Mark D. Baushke" <[e-mail]>]

Christer Holmberg <[e-mail]> 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