Asking for TLS 1.3 clients to refuse to talk to servers that reuse DH params is not helpful. A server can escrow a single secret and derive unique but predictable DH params. For example: hash a secret with the client random to generate the DH private key.
Hmmm. Counter: First, it's a good check against a maybe inadvertent mistake, that's helpful! Second, it lowers the impact of future weakdh/logjam style problems. Third, it increases the cost of DH escrow a little, enough maybe for it to be non-default even in enterprise cases.
-
-
It does prevent mistakes. It also prevents servers from reusing keys as an optimization when safe. Main point: it’s not helpful for preventing scalable escrow.
-
It's not a performance optimization, because the DH params can be generated asynchronously and in advance of the handshake - but it is a cost optimization for providers and their customers. I just don't think it's worth it. But I'm rarely CPU bound at edge.
- 2 more replies
New conversation -
-
-
Does it prevent DH escrow? No! Should TLS1.3 recommend it anyway: absolutely! I hope SSLLabs includes it in ratings, for the same reasons.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.