Re: [TLS] More hello entropy? (was: PR 508: Move downgrade sentinel to end)

Ilari Liusvaara <> Mon, 04 July 2016 13:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE52D12B01E for <>; Mon, 4 Jul 2016 06:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R7t_NLC96EL7 for <>; Mon, 4 Jul 2016 06:24:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3067012B055 for <>; Mon, 4 Jul 2016 06:24:44 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 720627F51 for <>; Mon, 4 Jul 2016 16:24:43 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id XPVpiKd3RxXf for <>; Mon, 4 Jul 2016 16:24:43 +0300 (EEST)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1DD6CC4 for <>; Mon, 4 Jul 2016 16:24:43 +0300 (EEST)
Date: Mon, 04 Jul 2016 16:24:41 +0300
From: Ilari Liusvaara <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <>
Subject: Re: [TLS] More hello entropy? (was: PR 508: Move downgrade sentinel to end)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Jul 2016 13:24:48 -0000

On Sun, Jul 03, 2016 at 09:22:27PM -0400, Dave Garrett wrote:
> On Sunday, July 03, 2016 07:02:05 pm Eric Rescorla wrote:
> > OTOH, those bytes will be more unique over time (because they are
> > guaranteed not to repeat for a very long time after the second has passed),
> > so intuitively this seems like a wash.
> Under the "Reevaluate handshake contents" part of the current TLS WG
> charter [0], we have the question: "Are bigger randoms required?". Did
> the WG ever fully discuss this and come to a decision?

I haven't seen a discussion. And my own opinion is "definitely not".

However, shortening the randoms is different thing. And what makes
this even nastier is that this isn't about what TLS 1.3 needs, but
what TLS 1.2 needs.

What does TLS 1.2 actually expect out of ClientRandom and ServerRandom?

I think for ClientRandom, TLS 1.2 wants "Globally unique nonce". And
for ServerRandom, "Nonce unique w.r.t. server key".

TLS 1.3 has these a lot weaker: The "Globally unique nonce" from
client is now the entiere ClientHello (and corresponding server
nonce is the entiere ServerHello). If using DHE-type key exchange,
both include short-lived public keys.

(This actually comes from TLS 1.3 not using randoms for anything,
causing some additional headache for contexts where privsep is

> Adding a
> supplemental entropy extension would be trivial, if we wanted to
> do so.

Unfortunately, this only concerns TLS 1.2 mode on server-to-client
direction, which is just about the nastiest case.

- Can't stuff it in base ServerHello
- Can't stuff it in any existing extension (I think at least some
  TLS clients do check that all lengths match exactly).
- Can't stuff it in any new extension (not supported!)

> (I see there was consideration of doing so a while ago [1].)

BTW: The intended purpose of that extended-random was apparently to
make exploiting DUAL_EC_DRBG easier (AFAICT, cuts down bruteforcing
from 32 to 16 bits).

The reasons stated for longer-than-256-bit randoms in that draft
was likely to be cryptographically pretty bogus.