Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

On 8/17/21, 16:16, "Benjamin Kaduk" <[e-mail]> 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!