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