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

Eric Rescorla <ekr@rtfm.com> Thu, 17 December 2015 20:11 UTC

Return-Path: <ekr@rtfm.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 5EB711B303E for <tls@ietfa.amsl.com>; Thu, 17 Dec 2015 12:11:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
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 EvdCjYa9fHR9 for <tls@ietfa.amsl.com>; Thu, 17 Dec 2015 12:11:55 -0800 (PST)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 718971A8903 for <tls@ietf.org>; Thu, 17 Dec 2015 12:11:55 -0800 (PST)
Received: by mail-yk0-x232.google.com with SMTP id 140so32910572ykp.0 for <tls@ietf.org>; Thu, 17 Dec 2015 12:11:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ihvedxQO4cLn08qVZMgEu39GZWtaTPwzJAJyb/8LsFo=; b=Z2h8Q87WWFqVJ4lk8/y9f3QO1eE/XwyjpDHiA/6SaPpTSvlhndZWsVfLDSaRV9JUCL sY0h5ygzjta7FeWXQquRFl2bawK5dYqWZLKrsGYdi+RNZFOVBuQxYVshnkj0lvZaFF9K 54jqoWSF5Fkvi3TbFMAF9LbaRrrfsQmbdBs6cP4no8x/jX53GpWNt1kdY1kzztWWHJCO 67to5yC+noR08/13F9o/H68xNdUHfJ091YOuC4vEBZtMXqJY70Jnul5vuxCcSKlvyLVV 2a6fbGC93rz+GZhbmfw0ZyBbe1SUKdcYyEnHAgk2SvNuNdImZWJ2HwmXQD6m6zqClo4d 5YtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ihvedxQO4cLn08qVZMgEu39GZWtaTPwzJAJyb/8LsFo=; b=d1d+CqzWy2IDY4SkKyd20QwHkgdXtrnMK4qnY3PbDP0DpueQpRPEh0YdR3ymc3/L59 ny1zqQ/m623cJ2hAnYpkAi6nqUMn79XwdieE0d/2GzPMzmJxTUNScG+U5GErr7RnGc5J kpjDGIJ4UmWdUMbSoaTte1dz4YgB8ZYYiid3kdhz50tpM9bYXGt+Do9BMzv9rOY7TifX SazEGt0mP/Uz1H/xxxjeUl4YNgoCLlSJSLMqJ0vRucZpFnEdBkY4wFFioeOV+ebi9wrL 3FpHIxS12+jsFtwUNjL29Es+ag3QllvVOI/BJGCUC13jiGTmEv5Sl+fIOWu/rZY1cUL7 SqgA==
X-Gm-Message-State: ALoCoQlr2CicccCMt1WRtLm4vYdN5HkTNi1Wd+ytPtejexQF1dRh6JFYmh/insjdVMzxS++hZOOGZzgytObouZ0yx+J4EPY0hQ==
X-Received: by 10.13.193.4 with SMTP id c4mr19928555ywd.192.1450383114664; Thu, 17 Dec 2015 12:11:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Thu, 17 Dec 2015 12:11:15 -0800 (PST)
In-Reply-To: <CADi0yUMwR7KuZOK4XF93gKqbzp1R3ynTrK92ZgieF57EJVQkkg@mail.gmail.com>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 17 Dec 2015 15:11:15 -0500
Message-ID: <CABcZeBPjFV+moohtdkcso8Ah=550yvNuT0066EiG2q+Wqxg4Yw@mail.gmail.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Content-Type: multipart/alternative; boundary=001a114caa9e5682b705271da291
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/8RnMiKD25jEujS9TG8MkSP7QMXc>
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: Thu, 17 Dec 2015 20:11:57 -0000

On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk <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            ||
>
>                             server random            ||
>
>                             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? :)

-Ekr



Another reason for including them (in particular as the leading values) in
> the computation of handshake_hash is to have them always located at the
> same position in the hashed stream. It is needed to make sure that these
> streams are unique per session (in theory, and maybe in practice, an
> attacker may play games changing the boundary of nonces by changing
> surrounding bytes in the stream).
>
> If this augmenting of handshake_hash is not adopted then there should be a
> note cautioning against excluding the nonces from the transmitted messages.
> If possible, it would be good to move them to a fixed position (from the
> start of the input to the handshake_hash).
>
> Hugo
>
> On Thu, Dec 17, 2015 at 10:13 AM, John Foley <foleyj@cisco.com> wrote:
>
>> On 12/16/2015 04:28 PM, Dave Garrett wrote:
>>
>>> On Wednesday, December 16, 2015 04:15:00 pm John Foley wrote:
>>>
>>>> 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.
>>>>
>>> I suggest filing an issue or submitting a PR with a starting point set
>>> of changes and discussing it with ekr.
>>>
>>>
>> I've submitted https://github.com/tlswg/tls13-spec/issues/378.  If you
>> give me a few days, I'll update this issue with KAT values per revision
>> 10.  Since it sounds like there are changes forthcoming in this section of
>> the draft, I'll hold off on the PR until later. Hopefully someone else will
>> volunteer to verify my KAT values.
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>