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

Dave Garrett <> Wed, 16 December 2015 20:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 398A71A89B0 for <>; Wed, 16 Dec 2015 12:30:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cRk0gd-96SRx for <>; Wed, 16 Dec 2015 12:30:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 510F91A88DF for <>; Wed, 16 Dec 2015 12:30:09 -0800 (PST)
Received: by with SMTP id 21so44559245qgx.1 for <>; Wed, 16 Dec 2015 12:30:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=lAENXlh0/ryfiGotb5vhZoEdSOXKLd6aiYqDwPzzv6c=; b=Z+In5Zv3sV6Org1zfLH9fErT8MyYozgZ0RmCmRm1jNb7QiPhXQIT8i4kggvjuC0ezg d7kwTOSxuE34Wnhwt3phtPvE2ooF3xn17WBM+6SuldFzFf0g9om5wRtnkLhqhXfb7V5Z cihJXIihshsUL+1NIBNc2yakfT3CHjTXt2CJ5IIYEsZUmFbmwlaFAnmDiJVgOdNSJ5e1 aqSoYeCaXxyNszxyfHcbwsHQNctBbuFIPfoVkL9dO7AMdENEY044UJX+V23twQpj8+VR NMdq1IfDyVJ0ag3PUFhohF68SNBtzcYKQE+5KGQ/I7saB6oXAiwP9giLZOf/rsS55dy+ lPow==
X-Received: by with SMTP id q130mr56131147qhb.24.1450297808562; Wed, 16 Dec 2015 12:30:08 -0800 (PST)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id z65sm3232924qhb.22.2015. (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 16 Dec 2015 12:30:07 -0800 (PST)
From: Dave Garrett <>
To: John Foley <>
Date: Wed, 16 Dec 2015 15:30:05 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
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: Wed, 16 Dec 2015 20:30:11 -0000

On Wednesday, December 16, 2015 11:12:42 am John Foley wrote:
> I apologize if this topic was previously discussed, I've only recently 
> joined the TLS mailer list.  While reviewing the TLS 1.3 draft (revision 
> 10), section 7 begins with the following wording:
>     In order to begin connection protection, the TLS Record Protocol
>     requires specification of a suite of algorithms, a master secret, and
>     the client and server random values.
> However, when reading through all of section 7, there appears to be no 
> explicit use for the client and server random values.  While these 
> values would be used implicitly when the handshake messages are hashed, 
> and thus have bearing on the key schedule calculation, there appears to 
> be no explicit use of the client and server random values similar to 
> section 6.3 in the TLS 1.2 spec.
> Am I interpreting this properly?

Yes, with the exception of the new downgrade protection mechanism that rides in the server random (in draft11 WIP), randoms are used implicitly via the handshake hash.

> If the client and server random values 
> are no longer explicitly used in any key derivation logic, maybe this 
> should be noted in section 6.3.1, as implementors will no longer need to 
> parse these values when processing incoming messages.  Additionally, the 
> intro to section 7 is misleading to implementors, as it implies the 
> client and server random values are needed to derive the key schedule.

There's still a lot of stuff with "TODO" notes on it in there that needs revision with regard to this. In particular, SecurityParameters still contains the randoms as well as the old master secret. I agree that this needs explicit explanation.

> The following issue and PR appear to be related to my question:

Not really. The issue there was a suggestion to regen the randoms on retry request. Yes, it touches the randoms, but it's a tangential issue. In any case, the idea in question has been shelved.


When referencing sections in the draft, please do so not just by number. Those can change as sections change. I suggest linking to one of the numbered drafts and citing its section, where possible. 6.3.1 is already different between draft10 and the current draft11 WIP.