[TLS] Explicit use of client and server random values

John Foley <foleyj@cisco.com> Wed, 16 December 2015 16:12 UTC

Return-Path: <foleyj@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id ED9061A0397 for <tls@ietfa.amsl.com>; Wed, 16 Dec 2015 08:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id P5QX_kSlBC6L for <tls@ietfa.amsl.com>; Wed, 16 Dec 2015 08:12:50 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946EA1A1B22 for <tls@ietf.org>; Wed, 16 Dec 2015 08:12:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1389; q=dns/txt; s=iport; t=1450282332; x=1451491932; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=Dam+1YEDcu7jtp4ZBuRnTO3kkWC8pUcgR7uFA81wsao=; b=l6GNnysyINzgyhUG1yA4hf5RI3cH+ENfNx9gzixv4sEKLD6AAGltl69p ykXE3xKi7RGf7dGknzlZovW0vPkPmacJEVvw0KbaCl4WKnOZHLtPYEwr6 edx6Z0Krf8Mt7v+C55O93OgV5GpkmfGz+bfmP4/5l9wzrQCxh2hMW35Rd 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHBQAsjHFW/4cNJK1egzpSvmWBYyGHF?= =?us-ascii?q?zoSAQEBAQEBAYEKhF4VQDYCBRYLAgsDAgECAVgIAQGIKw6cOY9wkhABCx0EgQG?= =?us-ascii?q?NQ4FRZYJQgUkFjiyIUIEMhC2CcYUeiSaTdSgEN4QihTUBAQE?=
X-IronPort-AV: E=Sophos;i="5.20,437,1444694400"; d="scan'208";a="218636863"
Received: from alln-core-2.cisco.com ([]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Dec 2015 16:12:11 +0000
Received: from [] (dhcp-64-102-56-172.cisco.com []) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBGGCB31025844 for <tls@ietf.org>; Wed, 16 Dec 2015 16:12:11 GMT
From: John Foley <foleyj@cisco.com>
To: tls@ietf.org
Message-ID: <56718D7A.4000302@cisco.com>
Date: Wed, 16 Dec 2015 11:12:42 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/FEuqrYnCmcYEgpIBlWVmSQjGm3U>
Subject: [TLS] Explicit use of client and server random values
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Dec 2015 16:12:52 -0000

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?  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.

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