[Cfrg] Using ephemeral DH in lieu of fresh nonces

Hugo Krawczyk <hugo@ee.technion.ac.il> Mon, 22 June 2020 15:02 UTC

Return-Path: <hugokraw@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A3E3A0DB9 for <cfrg@ietfa.amsl.com>; Mon, 22 Jun 2020 08:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.396
X-Spam-Level:
X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48LJdN_DDKjF for <cfrg@ietfa.amsl.com>; Mon, 22 Jun 2020 08:02:00 -0700 (PDT)
Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E313A0D98 for <cfrg@ietf.org>; Mon, 22 Jun 2020 08:01:59 -0700 (PDT)
Received: by mail-ej1-f41.google.com with SMTP id a1so4300586ejg.12 for <cfrg@ietf.org>; Mon, 22 Jun 2020 08:01:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=oR/DQIToHJJch9t8JEuMr1h02BNgE0VHMtnRaJSRbm8=; b=YjPMP0tK7rjhe8JhGh9HzPouLHNYxtE7EbElJIc+4zn/PP7djURAr0z53NDU1/DdIp aNlrtJVf8hgHZ1G5c+joeRndl8wlGeouyeizxu0iDSRfZS6vkl9LEIpzqol3BavxcEqW Kxu3o0QTiRTMY++tmgfdputNFJKFJSENNg3wpqITrX0T/J/tghfY4sa2OYlwrTLkuBrh eN1ReucwERDf0OshzrmhiSn3uEyKjPQbK5Ze2PiLedHilVyAB/Y3YDzwquUjwy3w3sIl OoTE+uPTSmTrwQZotw7oDHGNSlYlj1cL2bcS+5jcpe/ukoOIqTrEPQNhrlX+EHsGrmxG rmKw==
X-Gm-Message-State: AOAM5332GODWjNK8ckYOc8iaG80e0tc6wf6gh7I2a6OBEcpEbq1MaPvL knZEy7ICVY9Ha68ZI2LktKN6w4RS5N5kAHKOWPpH0qvf
X-Google-Smtp-Source: ABdhPJw1Ww0cubiIE+CXcZJfaYIFVXJQYQq8JWl+a1XVskfyINPDrF1kYqRRFMZWKo4GYPKL8ZaMuvo8c1HaTbj1jVw=
X-Received: by 2002:a17:906:8401:: with SMTP id n1mr15685105ejx.479.1592838117593; Mon, 22 Jun 2020 08:01:57 -0700 (PDT)
MIME-Version: 1.0
References: <326ebefc65c17f7fc11879b9b966a1e4585b1f16.camel@loup-vaillant.fr>
In-Reply-To: <326ebefc65c17f7fc11879b9b966a1e4585b1f16.camel@loup-vaillant.fr>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Mon, 22 Jun 2020 11:01:30 -0400
Message-ID: <CADi0yUM6MQd0TPczK+YKSdbu1nzFaV+peC_0yf9Soat8d3+eLg@mail.gmail.com>
To: Loup Vaillant-David <loup@loup-vaillant.fr>, "<cfrg@ietf.org>" <cfrg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002f166005a8ad86ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/5ithq2sRpf7QZZ_pk_jrdGJwy3k>
Subject: [Cfrg] Using ephemeral DH in lieu of fresh nonces
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2020 15:02:04 -0000

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
>