Re: [TLS] Finished stuffing

Joseph Salowey <> Wed, 07 September 2016 04:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4654112B111 for <>; Tue, 6 Sep 2016 21:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vab1l8hID19C for <>; Tue, 6 Sep 2016 21:49:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 53FA512B00D for <>; Tue, 6 Sep 2016 21:49:34 -0700 (PDT)
Received: by with SMTP id 93so2163087qtg.2 for <>; Tue, 06 Sep 2016 21:49:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/u060tPZfHVBn8CqPWVt4rjrzh1GyeG/Am2wFzI+HVU=; b=oYvnjL3yUffnkBnjHXeeOeqbzHWR8buNWCTiqINwNdFbZ4EeaFg9JiFLg/M+pJ3GdE 2Rom4V2Dup0pgTVPOmlv3/iRIFg/iRzBMMIZdhr68ubiesGTlOuwmeHKN3Q7572SbAXF GXrS2B+FZca5kac3tZs63QaO+gvnOUKokGQZCL1nF+3jWE3o6m1xODkGrkEUWhdg95n6 dXV7JPYZJoSThlvOq2vzFUU1wgxKLtKA77GsnaIQ0KBY7R464FixOGvZ/fz9AEM+JsMB 0D2bRDOMWeqR6fPfc6qSW0Iu/bKN0Il0OaYBS2SZLLJZMtImuoLpEbX/vHTo9LuWXEl0 wJnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/u060tPZfHVBn8CqPWVt4rjrzh1GyeG/Am2wFzI+HVU=; b=JEaAzQITorweroEG9zPUtxFHVAyqotZu+9RqTumOe/+XlWJIp9WBBzq2JhkmwuP8/4 NlSclczAuBsYy1HfGitsedtcjSkJfAEcYbQJ/RDAqZZrM3PyR4nuHmeNv2cEuwCZ2UZC qNwXVHnJYTCNw4fW5ZiebHB9A1WX16+tIPdysvKiTpkgxzL5PG7PCLALBtM0R0Vsd3bO EgzG/9d5w2aCKqeO60lZnHhqx+6+HQElEkbTX5Guasvom/5xh+8U4xGa4rineKpCvyUB dvRK4JAHSbE1sTZQrlzA2tpp+v8ppCD3gJ7cbHgkueda1NXTb4SOwAcdV3PnKTemjHmI 624A==
X-Gm-Message-State: AE9vXwNm7NVU/JrSCZrc8RcP5JnTP41gWKwayn+eRp+QjU0XZdZTtNd/HxS30qJ3ycHUggeLNZSciXiHhuEVQQ==
X-Received: by with SMTP id 30mr33788078qtf.117.1473223773489; Tue, 06 Sep 2016 21:49:33 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 6 Sep 2016 21:49:13 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Joseph Salowey <>
Date: Tue, 06 Sep 2016 21:49:13 -0700
Message-ID: <>
To: David Benjamin <>
Content-Type: multipart/alternative; boundary="94eb2c0cb03ab1a1a4053be3a3ee"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Finished stuffing
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Sep 2016 04:49:37 -0000

Hi Folks,

The chairs want to make sure this gets some proper review.   Please respond
with comments by Friday so we can make some progress on this issue.



On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin <>

> I think this is a good idea. It's kind of weird, but it avoids giving the
> early Finished such a strange relationship with the handshake transcript.
> Also a fan of doing away with multiple PSK identities if we don't need it.
> As a bonus, this removes the need to route a "phase" parameter into the
> traffic key calculation since we'll never derive more than one epoch off of
> the same traffic secret. Combine that with the two-ladder KeyUpdate and we
> no longer need any concatenation or other label-munging at all. Simply use
> labels "key" and "iv" and the record-layer just exposes a single
> UseTrafficSecret function which saves the traffic secret (for KeyUpdate),
> derives the traffic keys, and engages the new AEAD in one swoop without
> mucking about with phases, traffic directions, whether we are client or
> server, etc.
> David
> On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla <> wrote:
>> I should also mention that this makes the implementation a fair bit
>> simpler because:
>> 1. You can make all the decisions on the server side immediately upon
>> receiving the ClientHello
>> without waiting for Finished.
>> 2. You don't need to derive early handshake traffic keys.
>> From an implementor's perspective, this outweighs the messing around with
>> the ClientHello buffer.
>> -Ekr
>> On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla <> wrote:
>>> Folks,
>>> I have just posted a WIP PR for what I'm calling "Finished Stuffing"
>>> I would welcome comments on this direction and whether I am missing
>>> anything important.
>>> This PR follows on a bunch of discussions we've had about the redundancy
>>> of Finished and resumption_ctx. This PR makes the following changes:
>>> - Replace the 0-RTT Finished with an extension you send in the
>>>   ClientHello *whenever* you do PSK.
>>> - Get rid of resumption context (because it is now replaced by
>>>   the ClientHello.hello_finished.
>>> The reasoning for this change is:
>>> - With ordinary PSK you don't get any assurance that the other side
>>>   knows the PSK.
>>> - With 0-RTT you get some (subject to the usual anti-replay
>>>   guarantees) via the Finished message.
>>> - If we were to include the 0-RTT Finished message in the handshake
>>>   transcript, then we wouldn't need the resumption context because
>>>   the transcript would transitively include the PSK via the Finished.
>>> So the natural thing to do would be to always send 0-RTT Finished
>>> but unfortunately:
>>> 1. You can't just send the 0-RTT Finished whenever you do PSK because
>>>    that causes potential compat problems with mixed 1.3/1.2 networks
>>>    (the same ones we have with 0-RTT, but at least that's opt-in).
>>> 2. You also can't send the 0-RTT Finished with PSK because you can
>>>    currently offer multiple PSK identities.
>>> The on-list discussion has suggested we could relax condition #2 and
>>> only have one identity. And we can fix condition #1 by stuffing the
>>> Finished in an extension (with some hacks to make this easier). This
>>> PR enacts that.
>>> FAQS
>>> - What gets included in the handshake transcript?
>>>   The whole ClientHello including the computed hello_finished extension.
>>> - Isn't this a hassle to implement?
>>>   It turns out not to be. The basic reason is that at the point where
>>>   the client sends the ClientHello and the server processes, it doesn't
>>>   yet know which Hash will be chosen for HKDF and so NSS (and I believe
>>>   other stacks) buffers the ClientHello in plaintext, so hashing only
>>>   part of it is easy. I've done it in NSS and this part is quite easy.
>>> There are a number of possible variations we might want to look at:
>>> 1. Moving obfuscated_ticket_age to its own extension (out of
>>>    early_data_indication). This provides additional anti-replay
>>>    for the CH at the 0.5RTT sending point. I believe we should
>>>    make this change.
>>> 2. Tweaking the data to be hashed to just hash the ClientHello
>>>    prefix without the 0-filled verify_data. This is not significantly
>>>    harder or easier to implement and basically depends on whether
>>>    you prefer the invariant of "always hash complete messages" or
>>>    "always hash valid pieces of transcript". See above for notes
>>>    on buffering.
>>> 3. Allow multiple PSKs. Technically you could make this design
>>>    work with >1 PSK but stuffing multiple verify_data values in
>>>    the ClientHello. E.g,,
>>>       opaque FinishedValue<0..255>;
>>>       struct {
>>>          FinishedValue finisheds<0..2^16-1>;
>>>       } HelloFinished;
>>>    Based on the list discussion, it seems like nobody wants >1 PSK,
>>>    so I think one is simpler; I just wanted to note that these
>>>    changes weren't totally coupled.
>>> 4. External context values. Several people have pointed out that it
>>>    might be convenient to have an external context value hashed
>>>    into the transcript. One way to do this would be to include
>>>    it under the Finished. That's not difficult if people want to,
>>>    with the default being empty.
>>> 5. Hugo brought up on the list that we need to make very clear that
>>>    the "hello_finished" is being used to bind the handshakes and
>>>    that it depends on collision resistance. I have not forgotten this
>>>    and text on that point would be appreciated.
>>> Comments welcome.
>>> -Ekr
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list