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

Hugo Krawczyk <hugo@ee.technion.ac.il> Sat, 19 December 2015 00:03 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 923CC1A00DC for <tls@ietfa.amsl.com>; Fri, 18 Dec 2015 16:03:12 -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 8NFckbPUH8L7 for <tls@ietfa.amsl.com>; Fri, 18 Dec 2015 16:03:09 -0800 (PST)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 C86421A00D5 for <tls@ietf.org>; Fri, 18 Dec 2015 16:03:00 -0800 (PST)
Received: by mail-lb0-x234.google.com with SMTP id yq9so52530869lbb.3 for <tls@ietf.org>; Fri, 18 Dec 2015 16:03:00 -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=+BOeJ1SGaqzjW2UpKizdFZLPm3FZSAPymBo48d120cU=; b=PIyWnYc4yCgKVBHCzdU5e2fcVe494AFzSzXdcmDWPgeTjzTF607rUPVuougohu030X f/TBeTsXPttjLD1FTZahOeoCSxjtU1ZO7VOfARaFxSGSWy40K/XjbdZZkebulZGVWsnZ HkxcKJF5cf609Sz+udDjUafxKj9Ea0HS1tgTIECoM4QLu+rEKeQS0+wWJYfNd7+a/OAm kQM2BRnAf8BwEa63h8l+DZ8LhF6c6pnXjoPXueTYMGt5tsPBg/k7O+jW+k3uBzq9uNr0 qxkmcZrVO6Tu9/Umw/Mjq9DONZ8aqagKkbfnw25QI22x2oxnn3tr9D0JusaBrkGK6Vhn n91Q==
X-Received: by 10.112.173.202 with SMTP id bm10mr2508376lbc.56.1450483378826; Fri, 18 Dec 2015 16:02:58 -0800 (PST)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.25.168.210 with HTTP; Fri, 18 Dec 2015 16:02:29 -0800 (PST)
In-Reply-To: <518C2E3A-D72E-443D-80CF-C27E085292EC@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> <CADi0yUODjfdD8==_dgqQPEDUnJAQufzKmukqfDZtNW_ZwACkMw@mail.gmail.com> <518C2E3A-D72E-443D-80CF-C27E085292EC@shiftleft.org>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Fri, 18 Dec 2015 19:02:29 -0500
X-Google-Sender-Auth: nnXgLr4xy5lFIsiAt-czjoBNXTI
Message-ID: <CADi0yUMzmtf44RAh=FSbxShORYVbyKH=KBysMak_Ank0w4jt9A@mail.gmail.com>
To: Mike Hamburg <mike@shiftleft.org>
Content-Type: multipart/alternative; boundary=001a11c3440e8c32c3052734fa5c
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/G6R6vgf2CitDnufLfPJp4gkEh7I>
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: Sat, 19 Dec 2015 00:03:12 -0000

On Fri, Dec 18, 2015 at 3:55 PM, Mike Hamburg <mike@shiftleft.org> wrote:

> Whoops, big-R to reply all...
>
> On Dec 17, 2015, at 9:39 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
>
>
> 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
>>
>
> Sorry Hugo, I misread the proposal as using the nonces and handshake hash
> when signing, but not elsewhere.  On rereading, it is still entirely
> consistent, and isn’t being added “back” anywhere, except perhaps to some
> memory structure in the handshake code.  It also definitely isn’t a
> security problem, and it isn’t as annoying for implementations as I had
> figured (but it does require extra memory, which I had hoped to see
> removed).
>
> However, I’m somewhat confused about your statement that the framing
> information is the honest parties’ unique identifier of the handshake.  I
> had thought that TLS 1.3 was going to a model where the handshake trace
> (and configuration, for 0-RTT) was the real session identifier, and the
> nonces were there exclusively to make that trace unique.
>

In analysis we build on unique session identifiers which can be defined in
different ways but need always be part of the authenticated information
(sometimes, authentication can be implicit, i.e. non-explicit, by making
this information part of the input to the KDF).
When parties share state, state information may be used as part of the
unique session identifier. If this part is not transmitted and you only
authenticate information that went over the wire you may be missing
important inputs to authentication/KDF.
​I cannot predict all ways people can eventually construct logical session
identifiers but I can hope that these will always include session-specific
nonces, hence I want to make sure that they get included in the
authentication inputs (which in TLS 1.3 is governed by the handshake_hash).​
Of course, nonces by themselves are often not sufficient as session
identifiers but they are an essential piece [0].

 ​


>  This is a huge improvement from TLS 1.2, where the session identifier is
> sometimes the nonces and sometimes the trace and sometimes something in
> between (Server Certificate Verify eg).  It further means that future
> versions could drop the nonces entirely if they require one-use ephemeral
> key exchange.
>

​See [0]
​


>  It seems that you’re suggesting that the session identifier is the tuple
> (nonces, trace, configuration), which seems redundant to me.  Perhaps it is
> required by the security model (eCK?) to have a stable session identifier?
>

​I believe that any security model will need a unique way to refer to a
session and bind information to it.
​


>
> I’m concerned about parseability in two ways.  One, if the nonces ever
> change size in future versions, or are omitted due to required one-use
> ephemeral key exchange, then we will have to change how handshake_hash is
> calculated, and we will have to make sure that it cannot cause problems due
> to collisions with the current handshake_hash calculation.
>
> Two, if the handshake messages fed into the hash function are not uniquely
> parseable, that’s going to be a serious problem for analyzing TLS 1.3, and
> should be a top priority to fix.
>

​I, too, assume that non-unique parseability can create all kind of
problems. But I can also see parseability rules changing in protocol
variants/derivatives. The "insurance"​

​ in the form of prepended nonces does not seem to be too much of a burden.
But as I said in my initial posting, if this is considered a burden from
implementation point of view (or for any other reason) then it is not a
tragedy to keep it as currently defined but a note on the necessity of
transmitting nonces, as well as their unique parsing, should be included.

Hugo

[0] You mention the possibility of nonces being redundant in some cases,
e.g. when you send fresh DH values in each session for forward secrecy and
use these values in lieu of nonces (or as part of the naming of your
session). To me this is a good example of things people should NOT be
doing. For example, even if you specify that DH values MUST not be used
twice, there is no way to enforce that and someone (or a new
protocol/application) can decide that re-using a DH value for one minute
gives good enough forward secrecy. In many cases I would agree with that.
But then, if you also built on the DH values as nonces, then that decision
just broke your security.
Conclusion: Always use dedicated nonces for ensuring uniquenes of session
identifiers and session binding for authentication.
​

>
> Cheers,
> — Mike
>
>