On Tue, Aug 17, 2021 at 07:25:33PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > I see absolutely nothing wrong with using FFDH(E) and ECDH, as long as at > least one of the keys is ephemeral. There is no need to “warn away”, IMHO.
That's an interesting position to take. Let me see if I understand it correctly. (I will just write "DH" even though I mean (EC)DH.) Static-static DH results in re-generating the same derived key on multiple protocol instantiations, which is in some sense reusing a single key for multiple things and thus disrecommended. Though, in TLS, we have the Randoms that go into the key schedule, so the actual traffic/Finished/etc. keys will diverge even for the static-static case. However, it's hard to do formal analysis when the same secret is used across many protocol instantiations spread out over time, and one has to ensure that the Randoms actually are non-repeating in order for this to be a reliable scheme. So there's plenty of risk here and reasons to stay away. Ephemeral-static DH makes a new derived key for each protocol instantiation and simplifies the analysis (though subject to similar caveats as above about actually using a unique ephemeral value each time). It's clearly an improvement over static-static, but anyone armed with a protocol transcript who discovers the secret part of the static DH value can recover the derived key and deprotect the application data. Forward secrecy is not obtained until the "static" private value is discarded, leaving risk of loss of confidentiality due to endpoint compromise. Ephemeral-ephemeral DH also makes a new derived key for each protocol instantiation, but also allows the private DH values to be discarded "immediately", before any significant application data is protected using key material stemming from the derived key. This provides the strongest kind of forward secrecy (provided that endpoints actually discard the private ephemeral values), and is again a step up from the ephemeral-static case. In light of the above, it seems that your concerns are more focused on "key reuse" than forward secrecy. Is that correct? I have heard a lot of people saying that forward secrecy is important to them, so it's not clear that your stance is the consensus position. Thanks, Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
