[Cfrg] Using ephemeral DH in lieu of fresh nonces

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.pdf )

Hugo

On Fri, Jun 19, 2020 at 12:34 PM Loup Vaillant-David <loup@loup-vaillant.fr>
wrote:

> >From the latest draft:
>
>   https://tools.ietf.org/html/draft-haase-cpace-01
>
> """ Let sid be a session id byte string chosen for each protocol
> """ session before protocol execution; The length len(sid) SHOULD be
> """ larger or equal to 16 bytes.
>
> """ It is RECOMMENDED sid, is generated by sampling ephemeral random
> """ strings.
>
> Unlike ZPAD, The draft doesn't explain this recommendation.
> What problem may occur if we omit sid altogether?
>
> Even if G ends up being reused across several sessions, I don't believe
> there's any way to tell, because Ya and Yb are uniformly distributed if
> ya and yb are indeed random. I feel like I'm missing something.
>
> Loup.
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>