On 8/17/21, 16:16, "Benjamin Kaduk" <bka...@akamai.com> wrote: > 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.) And a very nice analysis, thank you! > 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. . . . . So there's plenty of risk here and reasons > to stay away. Correct. Agreed. > Ephemeral-static DH makes a new derived key for each protocol > instantiation and > simplifies the analysis . . . 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. Correct. Relative risks and concerns of client vs. server security are out of scope for this discussion. > Ephemeral-ephemeral DH also makes a new derived key for each protocol > instantiation, > but also allows the private DH values to be discarded "immediately", . . > . . . I'd say, "*requires* the private DH values to be discarded 'immediately'". > 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. It certainly is, and IMHO it's the preferred way, unless realities (of the environment, etc.) disallow it. > In light of the above, it seems that your concerns are more focused on > "key reuse" than > forward secrecy. Is that correct? Ha! Both are important, but absolutely - "key reuse" is a much bigger (and immediate!) concern. In my environment there are other ways to mitigate (not alleviate completely!) the threat to forward secrecy. > 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. I cannot claim consensus. Forward secrecy is probably as important to me as it is to the next guy - it's about the price I'd have to pay for it, the relative (not necessarily monetary) cost, and the willingness to consider other mitigation methods. Thanks!
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
