Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)

[denis bider <ietf-ssh3%denisbider.com@localhost>]

Comments:


- If we're being comprehensive, we should include a position with regard to Curve25519 and Curve448:

https://tools.ietf.org/html/draft-josefsson-ssh-curves-03

I suggest we take the following positions:

curve25519-sha256    SHOULD
curve448-sha256      SHOULD, or MAY?

That being said:


- Given the recent NSA recommendations, it seems to me it would be prudent to update the Curve25519/Curve448 draft, and to replace the SHA-256 algorithm with SHA-512 for Curve448. This would create the method "curve448-sha512" instead of "curve448-sha256".

Simon, what do you think? Could your draft be updated to do that?

It seems to me that this would meet the NSA's long-term guidelines, whereas curve448-sha256 doesn't.


- As Niels points out - now that the modifiers are SHOULD / MAY / ..., we ought to specify the verb this refers to. I would be more comfortable assuming that our target audience are developers, and that these modifiers refer to "implement". I'm less comfortable reaching out to end users, dispensing advice about deployed configurations - but I'm not firmly against it.


- If we're going to have text saying SHA-1 is begrudgingly acceptable for backwards compatibility, we can't simultaneously say that it is "NOT SECURE" in all caps. Conversely - if we do say it is "NOT SECURE", we can't have a graceful transition away from SHA-1. We must in that case pursue an aggressive transition, including condemnation of existing products that use it.

It seems to me we don't have reason enough to be that aggressive. If someone asks why SHA-1 is not currently secure for key exchange, we can't point to a document saying "here's how to break diffie-hellman-group14-sha1". What we have is concerns that such attacks might exist in the future, given weaknesses known today.

Bottom line - I think the following is fine:

"The SHA-1 [algorithm] SHOULD NOT be used. If it is used, it should only be provided for backwards compatibility[,] should not be used in new designs[,] and should be phased out of existing key exchanges as quickly as possible"

But it's not currently accurate to say:

"... because it is NOT SECURE."

It may instead be accurate to say:

"... because of its known weaknesses."


- Niels has suggested that it's onerous to have so many "MUST" curves. We've already reduced the number of MUST curves from three (in RFC 5656) to two (in this draft). I'm not sure that either nistp384 or nistp521 are suitable candidates for demotion. However, if we make changes here, it seems we should keep nistp384 as MUST, and demote nistp521 to SHOULD. This is due to that nistp384 meets current longest-term guidelines; whereas nistp521 seems to be overkill, and slower.

 

----- Original Message -----
From: Mark D. Baushke
Sent: Friday, February 12, 2016 11:48
To: denis bider
Cc: Peter Gutmann ; ietf-ssh%NetBSD.org@localhost
Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)

Hi denis,

You have made some good points. I have updated my draft to -02 and it is
in the process of being uploaded to the ietf servers.

For now, you can see the latest edition here:

  https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/

I think I have the normative vs informative references in their proper
locations, please let me know of any nits that still need to be
addressed.

-- Mark