10

According to the second draft of the TLS 1.3 specification, custom DH groups have been deprecated. As we all know, hardcoded DH groups are vulnerable to a precomputation attack that allows retroactive decryption. Since TLS 1.3 doesn't deprecate DH for key exchange entirely, I imagine this means it will fall back to the standard groups (e.g. Oakley groups). With this in mind, why does TLS 1.3 deprecate custom DH groups? Why not do the opposite and deprecate standard groups instead, or even deprecate all DH key exchange to make way for ECC?

Improve this question
2
  • 2
    The TLS1.3 drafts propose using the DHE groups already standardized for existing TLS versions by rfc7919, which differ from IKE/Oakley (partly) because "Using the same groups in multiple protocols increases the value for an attacker with the resources to crack any single group." It uses a similar NUMS scheme but with e instead of pi, thus giving different results. And it has no groups smaller than 2048, which even the Logjam researchers consider safe unless quantum.
    – dave_thompson_085
    Mar 19, 2018 at 7:44
  • 1
    @dave_thompson_085 Unfortunately that means that, if a classical algorithm for solving the discrete log problem for DHE 2048 is found that requires, say, 10$ billion USD and a year to crack a single group, the situation would be pretty bleak. That's $1 per year to attack 10 billion connections. If custom DH groups were used, it would make it such that an attacker with the same capabilities would have to spend the same resources to attack one series of connections. I for one am certainly not worth $10 billion.
    – forest
    Mar 19, 2018 at 7:49

1 Answer 1

Reset to default
9

With TLS 1.2 the server first needed to tell the client within the ServerKeyExchange message about the parameters of the DHE group it supports. Only then the client could act on these. With TLS 1.3 the client chooses instead from a set of named groups from start. Since the client now chooses the groups instead of the server the key exchange can start immediately (all information are known from start) which cuts a full RTT from the handshake, resulting in better performance.

Of course, in theory one could also still have custom groups this way, only that the client defines these groups this time and not the server. I cannot find any specific information why custom groups where removed but it seemed to happen during some interim meeting in mid 2014 based on this message in the TLS mailing list. I cannot find any information about this on the official meeting in 03/2014 nor on the next one in 07/2014.

But, some information in the paper Indiscreet Logs: Persistent Diffie-Hellman Backdoors in TLS from 2016 might point into the right direction. This paper discusses deniable backdoors using custom DH groups and in VII. Discussion A. Mitigation Strategies various strategies are discussed to prevent such backdoors, like disabling DHE completely or using only known good (named) DH groups similar to what is done with ECC. If fully removing DHE is not an option then having a fixed set of named DHE parameters looks like the easiest way to handle this problem.

Improve this answer
6
  • Thank you, this makes sense. I am disappointed that TLS 1.3 did not at least provide support for custom DH groups, but given that they now support Curve25519 in ECDH, there's less reason to stick with a DHE suite. Still, the fact that it supports DHE at all while removing support for custom groups is a bit disturbing. As for the client defining the groups, that would make for a severe fingerprinting vector so I doubt that that would be widely implemented.
    – forest
    Mar 19, 2018 at 6:34
  • Wouldn't checking for primality (impossible to trick unless you know the witnesses that are to be used) and making sure there are no small primes prevent such backdoors?
    – forest
    May 3, 2018 at 23:31
  • 1
    @forest: I think the question in your comment would be better asked at Cryptography. But I can imagine that this kind of checks is too expensive to do on each TLS handshake and thus only known-good groups are used.
    – Steffen Ullrich
    May 4, 2018 at 4:46
  • Personally I can do without all the testing of custom groups. Of course, it is very likely that the server will not accept custom groups created by the client (so the additional RTT cost will likely be incurred). But it seems likely that breaking keys on "broken" groups is possible. So this decision comes at a price, at least for DH over finite groups (i.e. "normal" DH), correct?
    – Maarten Bodewes
    Jan 4, 2019 at 11:41
  • 1
    @MaartenBodewes: If I understand you correctly than you refer to breaking any of the groups predefined in TLS 1.3. While this is unlikely at the moment it is not unlikely forever - but this is true with all the cryptographic primitives. That's why after a while some ciphers and groups are considered too weak and should no longer be used - this happened in the past too. See also Why is Mozilla recommending predefined DHE groups?.
    – Steffen Ullrich
    Jan 4, 2019 at 12:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .