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

Watson Ladd <[email protected]>
Newsgroups gmane.ietf.curdle,gmane.ietf.secsh
Message-ID <CACsn0c=AiBYQB-r+xH=bycqJRS420mKgxw5tvsxN9C7LYUxfLQ@mail.gmail.com>
On Wed, Aug 17, 2016 at 7:15 AM, Daniel Migault
<[email protected]> 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 protected]] On Behalf Of denis bider
> (Bitvise)
> Sent: Tuesday, August 16, 2016 5:19 PM
> To: Curdle <[email protected]>
> Cc: [email protected]; [email protected]; Mark D. Baushke <[email protected]>
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/curdle
>



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

_______________________________________________
Curdle mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/curdle
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.