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

John Foley <foleyj@cisco.com> Wed, 16 December 2015 21:14 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 B1A1D1A8A79 for <tls@ietfa.amsl.com>; Wed, 16 Dec 2015 13:14:32 -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 hkQULs30qUWT for <tls@ietfa.amsl.com>; Wed, 16 Dec 2015 13:14:31 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E731A8A6D for <tls@ietf.org>; Wed, 16 Dec 2015 13:14:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2858; q=dns/txt; s=iport; t=1450300470; x=1451510070; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Vl4hb4qfy1V+NeeidHbMLMLHZPiDxlqNPEv6Ii3d5ik=; b=AeIHGvTOSUwMnixADOfdpD88vJTCXzMHkZyGEeBsyBXuWBsk43Kp78U0 mtazpnMbJXttHU/Jw+T6dOIDCJ++uIqc7z05wpr8gWvjXgJICPenTNIw9 /PitBSzaGtttEpl9py8UDQ3vBv8MbjUpnxpuDjBLCEHW1rIxxpn65Dwds g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSAgBs03FW/4QNJK1egzpSvmUBDYFjI?= =?us-ascii?q?YVsAoEtOBQBAQEBAQEBgQqENQEBBDhAARALGAkWDwkDAgECAUUGDQgBAYgrDr4?= =?us-ascii?q?dAQEBAQEBAQEBAQEBAQEBAQEBARYEi1OCcYFRhH4FjiyIUIU5gnGFHoFchEWDB?= =?us-ascii?q?ZN1HwEBQoIQHoF0hWYBAQE?=
X-IronPort-AV: E=Sophos;i="5.20,438,1444694400"; d="scan'208";a="56193133"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Dec 2015 21:14:30 +0000
Received: from [64.102.56.172] (dhcp-64-102-56-172.cisco.com [64.102.56.172]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tBGLETb2006150; Wed, 16 Dec 2015 21:14:29 GMT
To: Dave Garrett <davemgarrett@gmail.com>
References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com>
From: John Foley <foleyj@cisco.com>
Message-ID: <5671D454.6000506@cisco.com>
Date: Wed, 16 Dec 2015 16:15:00 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <201512161530.06122.davemgarrett@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Yse-1TYiuV7AZnLXwm7bxCBQn4Y>
Cc: tls@ietf.org
Subject: Re: [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 21:14:32 -0000

On 12/16/2015 03:30 PM, Dave Garrett wrote:
> 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:
>>
>> https://github.com/tlswg/tls13-spec/issues/185
>> https://github.com/tlswg/tls13-spec/pull/189
> 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.
>
>
> Dave
>
>
> PS
> 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.
> .
>
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.