Re: [Curdle] Second AD Review: draft-ietf-curdle-ssh-curves.

[Ron Frederick <[e-mail]>]

Hi Mark,

On Aug 3, 2019, at 2:52 PM, Mark Baushke <mdb=[e-mail]> wrote:
> I have updated and uploaded the draft. Please let me know of any issues.


Here are a few thoughts on version 9 of the draft:

In section 3, you say “Key-agreement schemes Curve25519 and Curve448”, but these algorithms are not key-agreement schemes by themselves. I’d recommend going with the proposed SSH names here if you are discussing the full key agreement scheme and not the underlying elliptic curve algorithms. In other words, I’d suggest “Key-agreement schemes curve25519-sha256 and curve448-sha512” (possibly with quotes around each), as done earlier in this section.
When detecting the all-zeroes value, the new text says it should “abort if so, as described in Section 6” of RFC 7748. However, the original RFC doesn’t actually define what “abort” means. It says “abort if so (see below)”, but I don’t know what that is referring to. The only mention of “abort” is in sections 6.1 and 6.2, and nothing in section 7 seems to really expand on what should be done if the all-zeroes check matches. This is more a fault of RFC 7748 than it is of this doc, but since you are now recommending to “abort” in this doc, it would be good to be more specific about what that means for an SSH client/server.
I’m also not sure the sentence about “Alternative implementations” of these functions. There isn’t a lot of clarity on how one would determine in an alternate implementation when “either input forces the shared secret to one of a small set of values”. Since this point is covered already in RFC 7748 and this doc says “No further validation is required beyond what is discusses in RFC 7748”, though, I think it might be better to just leave this out.
-- 
Ron Frederick
[e-mail]