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

Hugo Krawczyk <> Thu, 17 December 2015 20:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1E1A31B3064 for <>; Thu, 17 Dec 2015 12:03:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7MhD5CxfRytO for <>; Thu, 17 Dec 2015 12:03:17 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C3FB21B3062 for <>; Thu, 17 Dec 2015 12:03:15 -0800 (PST)
Received: by with SMTP id kw15so52030336lbb.0 for <>; Thu, 17 Dec 2015 12:03:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=zoVGQhl4Z9NsjtphIz6LSv/O9Rq0WX8RMDLkM9ajO6M=; b=WJcnZVeCpVvfmdU9lHFvv+9t6pb1OapvNJI+7kYUO3yYIgB5eg/iZ9Sd27THeO1KQj DmjFv/KCDXEh3QNPWcb4DOp/g5pZRqS07LIHIFMcrVBSCcnU8Fg5Re4Z1thYSl3wqiGW aBe4j8SZT3lKVCrQH5I01aBNKbFys/tlWwkNs7aVuIrt8zCEeJRLAdW4sUb8lgsYegHW 3qZd5ANoSEZVp8VBIoEMUorFnb8L7gVTwMGaG+zqeGkaDTc7Y4DAtb8Almjlq1+CdBxU qevmFAzSry2dktSwGikgwk5b7K6GjXZBUungbcoaXpHsJgUjX/byOoBgY69Tz1q9u5GD 32Wg==
X-Received: by with SMTP id zw5mr22304307lbb.95.1450382593991; Thu, 17 Dec 2015 12:03:13 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 17 Dec 2015 12:02:44 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Hugo Krawczyk <>
Date: Thu, 17 Dec 2015 15:02:44 -0500
X-Google-Sender-Auth: H1eZUUzChpxNU4JV5hg1y4wTiAo
Message-ID: <>
To: John Foley <>
Content-Type: multipart/alternative; boundary=001a11c2345e4dab2f05271d831d
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 20:03:19 -0000

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.

Another reason for including them (in particular as the leading values) in
the computation of handshake_hash is to have them always located at the
same position in the hashed stream. It is needed to make sure that these
streams are unique per session (in theory, and maybe in practice, an
attacker may play games changing the boundary of nonces by changing
surrounding bytes in the stream).

If this augmenting of handshake_hash is not adopted then there should be a
note cautioning against excluding the nonces from the transmitted messages.
If possible, it would be good to move them to a fixed position (from the
start of the input to the handshake_hash).


On Thu, Dec 17, 2015 at 10:13 AM, John Foley <> wrote:

> On 12/16/2015 04:28 PM, Dave Garrett wrote:
>> On Wednesday, December 16, 2015 04:15:00 pm John Foley wrote:
>>> Thanks for answering my questions.  Have you considered adding KAT
>>> values for the key derivation steps?  This would be helpful to
>>> implementors.  RFC5869 already has KAT values for HKDF-Extract and
>>> HKDF-Expand.  But the TLS 1.3 spec has added HKDF-Expland-Label.
>>> Additionally, It would be useful to show intermediate KAT values for
>>> xSS, xES, mSS, and mES.
>> I suggest filing an issue or submitting a PR with a starting point set of
>> changes and discussing it with ekr.
> I've submitted  If you
> give me a few days, I'll update this issue with KAT values per revision
> 10.  Since it sounds like there are changes forthcoming in this section of
> the draft, I'll hold off on the PR until later. Hopefully someone else will
> volunteer to verify my KAT values.
> _______________________________________________
> TLS mailing list