Subject: RE: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2

From: Peter Gutmann <[email-masked]>
Date: Wed, 17 Aug 2016 11:26:28 +0000

denis bider (Bitvise) <[email-masked]> writes:

>this comment is with respect to the following draft specifying new Diffie-
>Hellman groups for SSH key exchange:

A further comment on the draft:

   The United States Information Assurance Directorate (IAD) at the
   National Security Agency (NSA) has published a FAQ
   [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve
   Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes
   less than SHA2-384 are no longer sufficient for transport of Top
   Secret information.  It is for this reason that this draft moves
   ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange
   method. 

So you've got an arbitrary ruling by some random US govt. agency that's
dictating how the entire world's SSH implementations have to function (sigh).
We know from global TLS scans that pretty much the entire planet uses SHA-256,
with SHA-384 and SHA-512 essentially lost in the noise.  However, this spec is
making the universal worldwide standard a MAY and the least-used form of the
entire SHA-2 family a MUST.  If the NSA's IAD wants to use whatever weird
config they decide on they can create their own spec (Suite B, anyone?), but a
global standard should go with whatever the world as a whole has decided on,
and that's overwhelmingly SHA-256.

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 17 Aug 2016 11:45:14 +0000

Speaking as an individual, I strongly agree with Peter; SHA256 should be MUST and any other variant should be a MAY.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Tue, 16 Aug 2016 15:19:14 -0600

Hello everyone,

this comment is with respect to the following draft specifying new Diffie-Hellman groups for SSH key exchange:

https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-03

The current version of the draft specifies the following:

  diffie-hellman-group14-sha256     MAY/OPTIONAL
  diffie-hellman-group16-sha512     SHOULD/RECOMMENDED
  diffie-hellman-group18-sha512     MAY/OPTIONAL
 
A previous version of this draft specified the following methods:

https://tools.ietf.org/html/draft-baushke-ssh-dh-group-sha2-03

  diffie-hellman-group14-sha256     MAY/OPTIONAL
  diffie-hellman-group15-sha512     MUST/REQUIRED/SHALL
  diffie-hellman-group16-sha512     SHOULD/RECOMMENDED
  diffie-hellman-group17-sha512     MAY/OPTIONAL
  diffie-hellman-group18-sha512     MAY/OPTIONAL
 
Note the presence of additional groups 15 and 17 which were removed in version 4 of the original Baushke draft.

Groups 15 and 17 were removed based on feedback from one implementer. Basically, this feedback was one line:

> +1 to dropping the odd-numbered groups and onlist listing group14/16/18

I would like to counter this, and move to restore the previous table including groups 15 and 17 - or failing that, at least group 15 - with the same parameters as above, in version 3 of the original Baushke draft.

My reasons for proposing this are as follows:

- According to NSA recommendations, the 3072-bit strength would be the current sweet spot between performance and acceptable security. Group 15 is 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit.

- The additional security of group 16 in comparison to group 15 is estimated to be small. Symmetric security estimates I've seen are 80 bits for group 1 (1024-bit), 112 bits for group 14 (2048-bit), and 128 bits for group 15 (3072-bit). Based on this, I expect the security of group 16 (4096-bit) to be between 136 - 144 symmetric bits.

- Based on practical measurements, it appears that group 16 is about a factor of 2 slower than group 15. With group 15, I'm getting about 20 full DH key exchanges per second; with group 16, I am getting around 10. I think this difference is significant, and can affect real world usage scenarios on heavily loaded servers.

At this time, I do not have a particular need for group 17 (or 18), but I find it peculiar that this draft would not specify a group that matches the exact recommended DH group size suggested by the NSA. It is weird that we have to choose either between group 14, which does not meet the requirements; or group 16, which is significantly slower.

For our next Bitvise SSH Server and Client versions, I have implemented support for groups 15 as well as 16, where group 15 is implemented with SHA-512, as specified above. When using DH key exchange, our SSH Server will favor group 15, whereas group 16 will be disabled by default for performance (but it will be enabled and preferred in the SSH Client).

denis

---

From: Watson Ladd <[email-masked]>
Date: Wed, 17 Aug 2016 07:28:56 -0700

On Wed, Aug 17, 2016 at 7:15 AM, Daniel Migault
<[email-masked]> wrote:
> Hi,
>
>
>
>
>
> Going briefly through the draft, it seems redundant to have MAY/OPTIONAL,
> SHOULD/RECOMMENDED, MAY/OPTIONAL.  I am not sure this does not result in a
> combination of recommendation for the users as well as a recommendation on
> algorithms to implement. I would recommend we only focus on requirements for
> algorithm implementation. We should also specify that all non specified
> algorithms in this document are “MAY”.

There must be a single algorithm that everyone is required to
implement. Make it P256 SHA2. Do not make it P384. There are no
efficient constant time implementations. (I have written a constant
time P384 this summer at Mozilla: it is not that fast). By contrast
OpenSSL has a constant time P256 implementation (possibly not used by
default: the rumors are unclear. Can you guys go ahead and ensure that
it is used by default?)

That's on top of everyone uses P256+SHA256.

>
>
>
> I have not found any recommendations for these algorithms at the IANA web
> page [1], nor in another document. If that is the case, maybe this document
> should clarify this so a status can be assigned for each kex. The IANA page
> also does not mention all algorithm and I have not found documentation for
> all suites found in the manual.
>
>
>
> Updating the different algorithm should consider two aspects: security and
> interoperability, which means a SHOULD NOT status is expected to be done for
> a cipher suite with a SHOULD status. In other words going from MUST to
> SHOULD NOT should be avoided unless there are strong reasons to do so. So
> maybe we should do a little bit more cleanup.
>
>
>
> I do not know the current status for SSH but it would be good to end up in
> group1 and SHA1 set to MUST NOT – eventually SHOULD NOT later being updated
> to MUST NOT.
>
>
>
> SHA256 set to MUST, SHA386 to MAY and SHA512 set to SHOULD to have it ready
> when SHA256 will be replaced.
>
>
>
> Maybe we should also consider the current use of the various group, and
> those not widely used may be set to MAY.
>
>
>
> BR,
>
> Daniel
>
>
>
> [1]
> http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16
>
>
>
>
>
> From: Curdle [mailto:[email-masked]] On Behalf Of denis bider
> (Bitvise)
> Sent: Tuesday, August 16, 2016 5:19 PM
> To: Curdle <[email-masked]>
> Cc: [email-masked]; [email-masked]; Mark D. Baushke <[email-masked]>
> Subject: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2
>
>
>
> Hello everyone,
>
>
>
> this comment is with respect to the following draft specifying new
> Diffie-Hellman groups for SSH key exchange:
>
>
>
> I would like to counter this, and move to restore the previous table
> including groups 15 and 17 - or failing that, at least group 15 - with the
> same parameters as above, in version 3 of the original Baushke draft.
>
>
>
> - According to NSA recommendations, the 3072-bit strength would be the
> current sweet spot between performance and acceptable security. Group 15 is
> 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit.
>
>
>
> - The additional security of group 16 in comparison to group 15 is estimated
> to be small. Symmetric security estimates I've seen are 80 bits for group 1
> (1024-bit), 112 bits for group 14 (2048-bit), and 128 bits for group 15
> (3072-bit). Based on this, I expect the security of group 16 (4096-bit) to
> be between 136 - 144 symmetric bits.
>
>
>
> - Based on practical measurements, it appears that group 16 is about a
> factor of 2 slower than group 15. With group 15, I'm getting about 20 full
> DH key exchanges per second; with group 16, I am getting around 10. I think
> this difference is significant, and can affect real world usage scenarios on
> heavily loaded servers.
>
>
>
> At this time, I do not have a particular need for group 17 (or 18), but I
> find it peculiar that this draft would not specify a group that matches the
> exact recommended DH group size suggested by the NSA. It is weird that we
> have to choose either between group 14, which does not meet the
> requirements; or group 16, which is significantly slower.
>
>
>
> For our next Bitvise SSH Server and Client versions, I have implemented
> support for groups 15 as well as 16, where group 15 is implemented with
> SHA-512, as specified above. When using DH key exchange, our SSH Server will
> favor group 15, whereas group 16 will be disabled by default for performance
> (but it will be enabled and preferred in the SSH Client).
>
>
>
> denis
>
>
>
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 17 Aug 2016 14:35:40 +0000

If that is the default, it would ease to deprecate what we want to deprecate. And I agree its status should be indicated in the draft.

BR, 
Daniel

-----Original Message-----
From: Watson Ladd [mailto:[email-masked]] 
Sent: Wednesday, August 17, 2016 10:29 AM
To: Daniel Migault <[email-masked]>
Cc: denis bider (Bitvise) <[email-masked]>; Curdle <[email-masked]>; [email-masked]; [email-masked]; Mark D. Baushke <[email-masked]>
Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2

On Wed, Aug 17, 2016 at 7:15 AM, Daniel Migault <[email-masked]> wrote:
> Hi,
>
>
>
>
>
> Going briefly through the draft, it seems redundant to have 
> MAY/OPTIONAL, SHOULD/RECOMMENDED, MAY/OPTIONAL.  I am not sure this 
> does not result in a combination of recommendation for the users as 
> well as a recommendation on algorithms to implement. I would recommend 
> we only focus on requirements for algorithm implementation. We should 
> also specify that all non specified algorithms in this document are “MAY”.

There must be a single algorithm that everyone is required to implement. Make it P256 SHA2. Do not make it P384. There are no efficient constant time implementations. (I have written a constant time P384 this summer at Mozilla: it is not that fast). By contrast OpenSSL has a constant time P256 implementation (possibly not used by
default: the rumors are unclear. Can you guys go ahead and ensure that it is used by default?)

>
>
>
> I have not found any recommendations for these algorithms at the IANA 
> web page [1], nor in another document. If that is the case, maybe this 
> document should clarify this so a status can be assigned for each kex. 
> The IANA page also does not mention all algorithm and I have not found 
> documentation for all suites found in the manual.
>
>
>
> Updating the different algorithm should consider two aspects: security 
> and interoperability, which means a SHOULD NOT status is expected to 
> be done for a cipher suite with a SHOULD status. In other words going 
> from MUST to SHOULD NOT should be avoided unless there are strong 
> reasons to do so. So maybe we should do a little bit more cleanup.
>
>
>
> group1 and SHA1 set to MUST NOT – eventually SHOULD NOT later being 
> updated to MUST NOT.
>
>
>
> SHA256 set to MUST, SHA386 to MAY and SHA512 set to SHOULD to have it 
> ready when SHA256 will be replaced.
>
>
>
> Maybe we should also consider the current use of the various group, 
> and those not widely used may be set to MAY.
>
>
>
> BR,
>
> Daniel
>
>
>
> [1]
>> +1 to dropping the odd-numbered groups and onlist listing 
>> +group14/16/18
>
>
>
> including groups 15 and 17 - or failing that, at least group 15 - with 
> the same parameters as above, in version 3 of the original Baushke draft.
>
>
>
> current sweet spot between performance and acceptable security. Group 
> 15 is 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit.
>
>
>
> - The additional security of group 16 in comparison to group 15 is 
> estimated to be small. Symmetric security estimates I've seen are 80 
> bits for group 1 (1024-bit), 112 bits for group 14 (2048-bit), and 128 
> bits for group 15 (3072-bit). Based on this, I expect the security of 
> group 16 (4096-bit) to be between 136 - 144 symmetric bits.
>
>
>
> factor of 2 slower than group 15. With group 15, I'm getting about 20 
> full DH key exchanges per second; with group 16, I am getting around 
> 10. I think this difference is significant, and can affect real world 
> usage scenarios on heavily loaded servers.
>
>
>
> At this time, I do not have a particular need for group 17 (or 18), 
> but I find it peculiar that this draft would not specify a group that 
> matches the exact recommended DH group size suggested by the NSA. It 
> is weird that we have to choose either between group 14, which does 
> not meet the requirements; or group 16, which is significantly slower.
>
>
>
> For our next Bitvise SSH Server and Client versions, I have 
> implemented support for groups 15 as well as 16, where group 15 is 
> implemented with SHA-512, as specified above. When using DH key 
> exchange, our SSH Server will favor group 15, whereas group 16 will be 
> disabled by default for performance (but it will be enabled and preferred in the SSH Client).
>
>
>
> denis
>
>
>
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 17 Aug 2016 14:15:27 +0000

Hi,

Going briefly through the draft, it seems redundant to have MAY/OPTIONAL, SHOULD/RECOMMENDED, MAY/OPTIONAL.  I am not sure this does not result in a combination of recommendation for the users as well as a recommendation on algorithms to implement. I would recommend we only focus on requirements for algorithm implementation. We should also specify that all non specified algorithms in this document are "MAY".

I have not found any recommendations for these algorithms at the IANA web page [1], nor in another document. If that is the case, maybe this document should clarify this so a status can be assigned for each kex. The IANA page also does not mention all algorithm and I have not found documentation for all suites found in the manual.

Updating the different algorithm should consider two aspects: security and interoperability, which means a SHOULD NOT status is expected to be done for a cipher suite with a SHOULD status. In other words going from MUST to SHOULD NOT should be avoided unless there are strong reasons to do so. So maybe we should do a little bit more cleanup.

I do not know the current status for SSH but it would be good to end up in group1 and SHA1 set to MUST NOT - eventually SHOULD NOT later being updated to MUST NOT.

SHA256 set to MUST, SHA386 to MAY and SHA512 set to SHOULD to have it ready when SHA256 will be replaced.

Maybe we should also consider the current use of the various group, and those not widely used may be set to MAY.

BR,
Daniel

[1] http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16

From: Curdle [mailto:[email-masked]] On Behalf Of denis bider (Bitvise)

Hello everyone,

denis