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

Hugo Krawczyk <hugo@ee.technion.ac.il> Fri, 18 December 2015 05:40 UTC

Return-Path: <hugokraw@gmail.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 BE8D71B3351 for <tls@ietfa.amsl.com>; Thu, 17 Dec 2015 21:40:28 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 UL6HgRHPdXJL for <tls@ietfa.amsl.com>; Thu, 17 Dec 2015 21:40:26 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 DD39F1A8749 for <tls@ietf.org>; Thu, 17 Dec 2015 21:40:25 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id l133so65530841lfd.2 for <tls@ietf.org>; Thu, 17 Dec 2015 21:40:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=C4+P/frq/dw/8xFJuIH7+tJdbHr3OhnwrW5Ev2rsAww=; b=f6yhcYeIT07IjUj/0gNMSp8eTnKaIMx9J/SQaLf9CIIDyrIkEj/PClommTafMLMKll 7GjsKGoPJnkLwpAd1YX6gd5bjxNeQQ5UNA3RGE1GmX61b/qcx51QvXgTq3o7VB0N5tBl Dy2K6p/rL/isSa3hLufJYUNHzs7bdSd7NKD7NnJg+M971gg7+07ozC9GUaBd7N72NoHx JL8K00N9gAByibqlA3D87VRPxAmXtfH6uJIvkqIZEAAU3vVl+FGuPMvliTCf+yS/q2zZ IivUGuYyRw4SzMWhz687hpdC+Cz6olKV5FXg8bNKZlaeX3C2+kVK/d6hgYWl5bwFOYXA q/gw==
X-Received: by 10.25.153.144 with SMTP id b138mr444602lfe.167.1450417224060; Thu, 17 Dec 2015 21:40:24 -0800 (PST)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.25.168.210 with HTTP; Thu, 17 Dec 2015 21:39:54 -0800 (PST)
In-Reply-To: <ED5D0D59-C8C2-490E-A0C5-1F7830D6E384@shiftleft.org>
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> <ED5D0D59-C8C2-490E-A0C5-1F7830D6E384@shiftleft.org>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Fri, 18 Dec 2015 00:39:54 -0500
X-Google-Sender-Auth: YojmqLEyYO_dMRQmTWXdNtSHrB8
Message-ID: <CADi0yUODjfdD8==_dgqQPEDUnJAQufzKmukqfDZtNW_ZwACkMw@mail.gmail.com>
To: Mike Hamburg <mike@shiftleft.org>
Content-Type: multipart/alternative; boundary=001a11401aec6a946f05272593f6
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rnisDXE1SbPr472AQSWfi42xiMk>
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: Fri, 18 Dec 2015 05:40:28 -0000

On Thu, Dec 17, 2015 at 5:33 PM, Mike Hamburg <mike@shiftleft.org> wrote:

>
>
> On Dec 17, 2015, at 12:11 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> 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
>
>
> While I haven’t been following TLS 1.3 development all that closely, I
> will question this request.
>
> TLS is annoying to implement and analyze in part because it hashes
> more-or-less arbitrary parts of the handshake messages together, in
> arbitrary order, at arbitrary times.  Removal of all the explicit hashing
> of client/server random in TLS 1.3 makes it clearer what’s going on, and
> makes implementations simpler.
>

​How does removal of explicit hashing of the nonces make things clearer?
What are the things that are made clearer?

​


>  Some of the crypto operations still feel pretty arbitrary (particularly
> Finished), but things seem to be improving overall.  In this context, it
> feels like
> ​​
> adding client random and server random back to the hash is a regression.
>

​What do you mean by ​

​"
​
 adding client random and server random back to the hash is a regression
​"?
Why "back"? Were they removed? What's the regression?
You are probably not suggesting to omit them, right? Are you worried about
the redundancy of being hashed twice? Is it a security issue or an
implementation issue?
​
.​

>
> From an analysis point of view, the client and server random are parseable
> from Hash(handshake messages) because they are concatenated with framing
> information.
>

​They are parseable, but I am not sure they are *uniquely* parseable - a
fixed location in the stream does make them uniquely parseable.

​


>  But here, they are concatenated without framing information.
>

​The nonces are the main framing information - they are the (honest
parties') unique identifier of the handshake.

​


> So I don’t understand Hugo’s contention that the old scheme leads to
> trouble if the nonce changes sizes in a later version, and that the new
> scheme does not.  It seems to me that the reverse is more likely to be true.
>

​I'm clearly not following your argument.

​Hugo
​

>
> Cheers,
> — Mike
>