Viktor Dukhovni <[email protected]> writes: >In OpenSSL, I am shepherding a PR that adds support for RFC7919 in TLS 1.2, >with only mutually supported negotiated groups used when support for any >FFDHE groups is signalled by the client.
Is that a good idea? When this last came up the consensus was not to implement it because of the braindead requirement that "if none of the client- proposed FFDHE groups are known and acceptable to the server, then the server MUST NOT select an FFDHE cipher suite", meaning that if you don't correctly guess an acceptable-to-the-server DH suite then it can't continue with, say, the de facto standard RFC 3526 values but has to fall back to RSA, the least secure mechanism there is (this is assuming ECDH has already been passed by, i.e. the priority is ECDH > DH > RSA). My comment at the time, as part of an ongoing discussion on why 7919 doesn't work, was: 7919 is a my-way-or-the-highway spec, or more accurately my-way-or-no-way. You can't say "I'd like to do DH-2048" as with SSH, you can only use the one value that 7919 specifies and if either side chooses some other DH-2048 value you're required to fall back to RSA. When this was discussed on the TLS list, the general response, from those who commented, was that they weren't going to use it because of this and other problems it had. Some of these issues were brought up long ago (e.g. [2]), but ignored. So 7919 is pretty much a non-starter. All the list archive URLs have changed to ones with random noise in them so I don't know what particular message [2] referenced but the discussion was in December 2015. Compare this to SSH with "I'd like a prime in the range x...y bits", which works fine. 7919 in contrast is "you have to guess whether I can do 7919 and then guess which values I want, and if you get it wrong your penance is to use RSA" (the RFC also gives you the option of disconnecting, which is probably even worse, but whatever you do you're not allowed to continue with perfectly valid and known-good values like the 3526 ones). Peter. _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
