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

Benjamin Kaduk <bkaduk@akamai.com> Tue, 05 January 2016 20:36 UTC

Return-Path: <bkaduk@akamai.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 8C1A51A90E0 for <tls@ietfa.amsl.com>; Tue, 5 Jan 2016 12:36:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8f3TltgjW1na for <tls@ietfa.amsl.com>; Tue, 5 Jan 2016 12:36:36 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 243C01A90DC for <tls@ietf.org>; Tue, 5 Jan 2016 12:36:36 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7386E433456; Tue, 5 Jan 2016 20:36:35 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5DA3E433445; Tue, 5 Jan 2016 20:36:35 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1452026195; bh=OVNHIQI98Jn+BS0ma/NmJg7hjjlXeMDgrMSFfAbKFZM=; l=5334; h=To:References:Cc:From:Date:In-Reply-To:From; b=uaEp/L9sFuxJto9AEazw7g4+IdvDSSKAhXk/ijDJPocS48KIMQV6ZEk1VRE6Z2tEs 8QwiAnQwRdaUJvxFJMvcKHPfb4ZClzOzu3U92vSAX4m9M8/Y+Wy0nYVomXEK4Yti/G ACvPLNQed6tz/zoQwVWG61OThUysXKgJd/bxTlYg=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 18B0C2029; Tue, 5 Jan 2016 20:36:35 +0000 (GMT)
To: Eric Rescorla <ekr@rtfm.com>, Hugo Krawczyk <hugo@ee.technion.ac.il>
References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com> <5671D454.6000506@cisco.com> <201512161628.02986.davemgarrett@gmail.com> <5672D12D.4010003@cisco.com> <CADi0yUMwR7KuZOK4XF93gKqbzp1R3ynTrK92ZgieF57EJVQkkg@mail.gmail.com> <CABcZeBPjFV+moohtdkcso8Ah=550yvNuT0066EiG2q+Wqxg4Yw@mail.gmail.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <568C2952.7010503@akamai.com>
Date: Tue, 05 Jan 2016 14:36:34 -0600
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: <CABcZeBPjFV+moohtdkcso8Ah=550yvNuT0066EiG2q+Wqxg4Yw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------040902040108020200060302"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ScCcwuGBmBfBupwRk-cblOsbMRE>
Cc: "tls@ietf.org" <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: Tue, 05 Jan 2016 20:36:37 -0000

On 12/17/2015 02:11 PM, Eric Rescorla wrote:
>
>
> On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk <hugo@ee.technion.ac.il
> <mailto:hugo@ee.technion.ac.il>> wrote:
>
>     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 ||
>
>     serverrandom ||
>
>     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.
>
>  
> This change doesn't make implementation or specification significantly
> more difficult.
> Does anyone  else object or feel it makes analysis harder? :)
>

I don't object, but since elsewhere in the thread the possibility of
changing the size of or omitting the randoms in the future came up, I
will mention the possibility of adding length/framing information and/or
labels into the hash input as well as the randoms themselves.

-Ben