[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [173.37.142.93]) (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: A0AHBQAsjHFW/4cNJK1egzpSvmWBYyGHFzoSAQEBAQEBAYEKhF4VQDYCBRYLAgsDAgECAVgIAQGIKw6cOY9wkhABCx0EgQGNQ4FRZYJQgUkFjiyIUIEMhC2CcYUeiSaTdSgEN4QihTUBAQE
X-IronPort-AV: E=Sophos;i="5.20,437,1444694400"; d="scan'208";a="218636863"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Dec 2015 16:12:11 +0000
Received: from [64.102.56.172] (dhcp-64-102-56-172.cisco.com [64.102.56.172]) 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: https://github.com/tlswg/tls13-spec/issues/185 https://github.com/tlswg/tls13-spec/pull/189
- [TLS] Explicit use of client and server random va… John Foley
- Re: [TLS] Explicit use of client and server rando… Dave Garrett
- Re: [TLS] Explicit use of client and server rando… John Foley
- Re: [TLS] Explicit use of client and server rando… Dave Garrett
- Re: [TLS] Explicit use of client and server rando… John Foley
- Re: [TLS] Explicit use of client and server rando… Hugo Krawczyk
- Re: [TLS] Explicit use of client and server rando… Eric Rescorla
- Re: [TLS] Explicit use of client and server rando… Salz, Rich
- Re: [TLS] Explicit use of client and server rando… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Explicit use of client and server rando… Mike Hamburg
- Re: [TLS] Explicit use of client and server rando… Hugo Krawczyk
- Re: [TLS] Explicit use of client and server rando… Mike Hamburg
- Re: [TLS] Explicit use of client and server rando… Hugo Krawczyk
- Re: [TLS] Explicit use of client and server rando… Benjamin Kaduk