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.
-
-
Replying to @grittygrease
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.
2 replies 0 retweets 0 likes -
Replying to @colmmacc
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.
1 reply 0 retweets 1 like -
Replying to @grittygrease
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.
1 reply 0 retweets 0 likes -
Replying to @colmmacc
Right, you can save the CPU required for parameter generation and validation. I consider that a perf/power optimization.
1 reply 0 retweets 0 likes
Well so is RC4 then ;-) Good crypto costs cycles; in this case I'd pay the cycles (and renewable energy!) to have a measure of protection against mistakes and improved future attacks on DH, especially ECDH and QC.
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.