Re: [TLS] rm Hello.random w/ (EC)DHE [was OPTLS: Signature-less TLS 1.3]

Martin Thomson <martin.thomson@gmail.com> Mon, 10 November 2014 19:05 UTC

MIME-Version: 1.0
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5CFDCC9@XMB116CNC.rim.net>
References: <810C31990B57ED40B2062BA10D43FBF5CFDCC9@XMB116CNC.rim.net>
Date: Mon, 10 Nov 2014 11:04:54 -0800
Message-ID: <CABkgnnVLOZSK_U2bDJKQ0fUyvkUyJ83W71Yym+GeZ2xnyLtxjg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Dan Brown <dbrown@certicom.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z6jXze3arp7tDY8JZzDAlaWyhXA
Cc: "hoeteck@alum.mit.edu" <hoeteck@alum.mit.edu>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] rm Hello.random w/ (EC)DHE [was OPTLS: Signature-less TLS 1.3]
Precedence: list

On 10 November 2014 09:58, Dan Brown <dbrown@certicom.com> wrote:
> When using (EC)DHE (inc. OPTLS below), the TLS random nonces
> (ClientHello.random and ServerHello.random) seem redundant (unless one
> re-uses ephemeral secret keys (but then maybe a counter or secure time would
> be almost as good a nonce as a random in this case), or perhaps for some
> other reason I’m missing), and perhaps even a point of fragility (e.g. if a
> common generator for nonces and keys is weak, or corrupted). So, does it
> make sense to remove these Hello.randoms, when using (EC)DHE, or to replace
> them with something milder, like Hello.time, Hello.counter, or just
> Hello.nonce?

Aren't they still highly relevant in the resumption cases?  In which
case, a new source of entropy ensures that two sessions resumed from
the same base don't have synchronized keys.

[TLS] rm Hello.random w/ (EC)DHE [was OPTLS: Sign… Dan Brown
Re: [TLS] rm Hello.random w/ (EC)DHE [was OPTLS: … Martin Thomson
Re: [TLS] rm Hello.random w/ (EC)DHE [was OPTLS: … Geoffrey Keating
Re: [TLS] rm Hello.random w/ (EC)DHE [was OPTLS: … Nico Williams