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

[Watson Ladd <watsonbladd%gmail.com@localhost>]

On Wed, Aug 17, 2016 at 7:15 AM, Daniel Migault
<daniel.migault%ericsson.com@localhost> 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:curdle-bounces%ietf.org@localhost] On Behalf Of denis bider
> (Bitvise)
> Sent: Tuesday, August 16, 2016 5:19 PM
> To: Curdle <curdle%ietf.org@localhost>
> Cc: djm%mindrot.org@localhost; ietf-ssh%netbsd.org@localhost; Mark D. Baushke <mdb%juniper.net@localhost>
> 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:
>
>
>
> 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
>
>
>
>
> _______________________________________________
> Curdle mailing list
> Curdle%ietf.org@localhost
> https://www.ietf.org/mailman/listinfo/curdle
>



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