Re: [Cfrg] Using ephemeral DH in lieu of fresh nonces

[Loup Vaillant-David <[e-mail]>]

Hi Hugo,

Thank you so much for your response, it forced me to change my mind on
a couple points.

How using a primitive for several purposes was new to me. Now I need to
re-consider the design of Monokex, my Noise-like protocol framework
(Noise is amazing, but I felt it could be further simplified): both
framework use ephemeral keys as nonces. The Noise specifications
insists that no party shall send encrypted stuff before they mix their
own ephemeral key in the key mix.

Composition attacks also make my head hurt, so squashing them simply
with a session id sounds like a good safety belt, in case I design a
brittle protocol that would otherwise be vulnerable.

Loup.


On Mon, 2020-06-22 at 11:01 -0400, Hugo Krawczyk wrote:
> In the email below, Loup raises a natural question: Why not reuse
> ephemeral DH values in a protocol instead of fresh nonces?
> 
> Formalisms apart, fresh non-repeating session identifiers are
> essential for many reasons: against replay attacks, for binding
> session flows together, avoiding  "composition attacks" (e.g., where
> flows from different sessions are mixed-and-matched), ensuring domain
> separation, etc. A natural implementation of session id's uses
> session-specific fresh random nonces. An equally natural question
> (and I think your email was referring to this issue) is why not use
> the ephemeral DH in lieu of random nonces, after all these values are
> selected as fresh random values for each session. 
> 
> A generic reason (which I strongly advocate) for not doing so is that
> one should avoid having the same element in the protocol to serve 
> two separate functionalities/roles (in this case it would be using a
> DH value as key share and also as nonce/sessionid). This results in
> fragile protocols that can easily go wrong with variants of the
> protocol or when the protocol evolves over time, and is prone to bad
> implementations. For example, if one of the roles of this element is
> not  required anymore (due to changes in the protocol or changes in
> the setting where the protocol operates), the element may be changed
> "without remembering" that it had this other role. 
> 
> Concretely, in the case of using ephemeral DH values for freshness,
> there are good practical examples where security breaks with the dual
> use of these values. For example, an application may decide (e.g.,
> for performance reasons) that they do not need "perfect" forward
> secrecy, but that a one-minute forward-secrecy window of repeated
> ephemeral DH values is enough for the application. With repeated DH
> values used as session ids, the uniqueness of the session id is
> gone.  This is also the case of applications that need to avoid
> forward secrecy at all (see requests for a static version of TLS 1.3
> in the TLS mailing list). Yet another example is the SIGMA-I protocol
> (used in TLS 1.3 and IKEv1). If the initiator sends g^x in the first
> message, this value can be used against replay attacks in the
> responder's signature. Then, someone decides (and there may be good
> reasons for that) to send g^x only in the third message and you lose
> your anti-replay mechanism.
> 
> Mea culpa: I have used ephemeral DH values in the dual functionality
> of key shares and session identifiers in several of my papers for the
> sake of analysis/notation simplicity. But you should not do it when
> building real-world implementations. In the SIGMA instantiation in
> draft-krawczyk-cfrg-opaque, for example, nonces are used in addition
> to DH values. (See also appendix B of 
> https://webee.technion.ac.il/~hugo/sigma-pdf.pdfdf )
> 
> Hugo