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.
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.
-
-
Right, you can save the CPU required for parameter generation and validation. I consider that a perf/power optimization.
-
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.
End of conversation
New conversation -
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.