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

Nico Williams <nico@cryptonector.com> Mon, 22 June 2020 19:01 UTC

Return-Path: <nico@cryptonector.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 989B23A1099 for <cfrg@ietfa.amsl.com>; Mon, 22 Jun 2020 12:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 mRls7KiArcla for <cfrg@ietfa.amsl.com>; Mon, 22 Jun 2020 12:01:11 -0700 (PDT)
Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810F93A1146 for <cfrg@ietf.org>; Mon, 22 Jun 2020 12:01:08 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 23B27181904; Mon, 22 Jun 2020 19:01:07 +0000 (UTC)
Received: from pdx1-sub0-mail-a54.g.dreamhost.com (100-96-10-13.trex.outbound.svc.cluster.local [100.96.10.13]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 7A9A8182015; Mon, 22 Jun 2020 19:01:06 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a54.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Mon, 22 Jun 2020 19:01:06 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Grain-Industry: 0e6a7f2546d6b232_1592852466882_1677762089
X-MC-Loop-Signature: 1592852466882:1494722737
X-MC-Ingress-Time: 1592852466881
Received: from pdx1-sub0-mail-a54.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a54.g.dreamhost.com (Postfix) with ESMTP id 8C910B3A1B; Mon, 22 Jun 2020 12:01:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=02S+M1ST/Y0p3e s8XKTEL/nFUXM=; b=PY+jJU3iH4z0xb5M9uKUTaQ8iZ8YtEQMHTYCc+m9a7BIiY qvN8hwm9uNPhQffZmIS4JqF4l7ejPGDThe9SwpZ2eMVfypn+caquAftjbVSxCEYA VT/28EWbg0jCkjSEh6nuLT8qaywiRJmr8RUkgCG0lknJpVHLG2t2Jqu2p6Qig=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 69A5EB3A20; Mon, 22 Jun 2020 12:00:57 -0700 (PDT)
Date: Mon, 22 Jun 2020 14:00:53 -0500
X-DH-BACKEND: pdx1-sub0-mail-a54
From: Nico Williams <nico@cryptonector.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Cc: Loup Vaillant-David <loup@loup-vaillant.fr>, "<cfrg@ietf.org>" <cfrg@ietf.org>
Message-ID: <20200622190052.GN3100@localhost>
References: <326ebefc65c17f7fc11879b9b966a1e4585b1f16.camel@loup-vaillant.fr> <CADi0yUM6MQd0TPczK+YKSdbu1nzFaV+peC_0yf9Soat8d3+eLg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CADi0yUM6MQd0TPczK+YKSdbu1nzFaV+peC_0yf9Soat8d3+eLg@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudekvddgudefgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuggftrfgrthhtvghrnhepffdtkeethfeuteeviefgfeegjeetjedvhfehgfdvtdefueejheelgeeuhffghffgnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/Wu7gfuJT7Kj7ngJIHhMpjj9_LGA>
Subject: Re: [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 19:01:22 -0000

On Mon, Jun 22, 2020 at 11:01:30AM -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?

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

Using ephemeral DH in lieu of nonces != re-using ephemeral DH in lieu...

> [...]
> 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.

As others have said: to avoid the Dual_EC DRBG + extended nonce style of
in-band subliminal channel, nonces must be small or not be used at all.
Using ephemeral DH key agreement shared keys as nonces reduces the
freedom an implementation has to leak bits of PRNG state or keys
in-band.  Of course, there are lots of ways to leak bits in-band, and
even more out-of-band, so perhaps this should not be a concern.

> 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

Key hygiene, sure.  Perhaps one can do an additional ephemeral DH key
agreement exchange for nonce agreement if this is an issue.  I hope the
nonce agreement need not be as strong / costly as the primary key
agreement.

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

This sort of thing can always happen.  We just have to write good docs.
We can't remove all footguns in crypto.  At some point we need to choose
between footguns to remove or keep.

> 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
> [...]

In this case you need to separate nonce agreement from key agreement,
but then you start wondering why reuse key agreement keys.  If it's for
key escrow, find a better way (encrypt the keys to the escrow agent and
send them there).  If dual use can produce a good reason (and pressure)
to never reuse keys, then dual use might be a good thing anyways.

Assuming no DH keypair reuse, is there a reason not to use DH key shared
keys as a sourc eof "nonces"?

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

Nico
--