Re: [TLS] Explicit use of client and server random values

Mike Hamburg <> Thu, 17 December 2015 22:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 532051A8A1C for <>; Thu, 17 Dec 2015 14:33:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.556
X-Spam-Level: *
X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0h3IZxaX9yDa for <>; Thu, 17 Dec 2015 14:33:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DFEB01A1A66 for <>; Thu, 17 Dec 2015 14:33:13 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id A1FEFF210A; Thu, 17 Dec 2015 14:29:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=sldo; t=1450391342; bh=tqniVZ5ft0IrO0rF3ZE/vYL3P0M3mmPtGSocYtjdxrI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=kM3zeFVuqm2IZzJrg8q/0O6sQUhXSyUPDy34l+XdR1rRPile6lJHMxLGWNoMwA0CD I06s2M1hi6nRDtKmO9cwO9ZYs7Z5Hc0lLN00wBDxoma7qTV8NFOF0H+CSU6c5+uy/W QceFnj00DMLQ1hO9gFjEJDh2Yum1mjDvOE7AHzOo=
Content-Type: multipart/alternative; boundary="Apple-Mail=_1E11E9BB-990F-41EE-96B4-AF4275D3DC40"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Mike Hamburg <>
In-Reply-To: <>
Date: Thu, 17 Dec 2015 14:33:11 -0800
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Eric Rescorla <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Explicit use of client and server random values
X-Mailman-Version: 2.1.15
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: Thu, 17 Dec 2015 22:33:15 -0000

> On Dec 17, 2015, at 12:11 PM, Eric Rescorla <> wrote:
> On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk < <>> wrote:
> I have mentioned this in private conversations but let me say this here: I would prefer that the nonces be explicitly concatenated to the handshake hash.  That is, 
> handshake_hash = Hash(
>                             client random            ||
>                             server random            ||
>                             Hash(handshake_messages) ||
>                             Hash(configuration)      ||
>                            )
> The reason is that nonces are essential for freshness and session uniqueness and I want to see them explicitly included in the signed/mac-ed/KDF-ed information. I can envision a future variant/mode of the protocol where parties do not transmit nonces but have a synchronized state that they advance separately and use as nonces (e.g., for key refreshing) - in such case the nonces would not be included in the handshake-hash computation.
> So while the redundancy of having them twice in the handshake_hash calculation may be annoying, this adds robustness to the security (and analysis) of the protocol.
> This change doesn't make implementation or specification significantly more difficult.
> Does anyone  else object or feel it makes analysis harder? :)
> -Ekr

While I haven’t been following TLS 1.3 development all that closely, I will question this request.

TLS is annoying to implement and analyze in part because it hashes more-or-less arbitrary parts of the handshake messages together, in arbitrary order, at arbitrary times.  Removal of all the explicit hashing of client/server random in TLS 1.3 makes it clearer what’s going on, and makes implementations simpler.  Some of the crypto operations still feel pretty arbitrary (particularly Finished), but things seem to be improving overall.  In this context, it feels like adding client random and server random back to the hash is a regression.

From an analysis point of view, the client and server random are parseable from Hash(handshake messages) because they are concatenated with framing information.  But here, they are concatenated without framing information.  So I don’t understand Hugo’s contention that the old scheme leads to trouble if the nonce changes sizes in a later version, and that the new scheme does not.  It seems to me that the reverse is more likely to be true.

— Mike