Re: [TLS] Finished stuffing

Joseph Salowey <joe@salowey.net> Wed, 07 September 2016 04:49 UTC

Return-Path: <joe@salowey.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4654112B111 for <tls@ietfa.amsl.com>; Tue, 6 Sep 2016 21:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com
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 vab1l8hID19C for <tls@ietfa.amsl.com>; Tue, 6 Sep 2016 21:49:34 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 53FA512B00D for <tls@ietf.org>; Tue, 6 Sep 2016 21:49:34 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id 93so2163087qtg.2 for <tls@ietf.org>; Tue, 06 Sep 2016 21:49:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.237.48.161 with SMTP id 30mr33788078qtf.117.1473223773489; Tue, 06 Sep 2016 21:49:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.162.131 with HTTP; Tue, 6 Sep 2016 21:49:13 -0700 (PDT)
In-Reply-To: <CAF8qwaCVyRrSm-XtL6Jd_VKD9qGmCJNFJW1GZVjmidsr3DnW_Q@mail.gmail.com>
References: <CABcZeBNqs+6SYsA9SnED8nWkUXifSPuF4gBdRG-gJamtWmxWNw@mail.gmail.com> <CABcZeBP890QrcbpGR9Ht2RkfHShavkkDmvvKPP+81x8Bz+SeDA@mail.gmail.com> <CAF8qwaCVyRrSm-XtL6Jd_VKD9qGmCJNFJW1GZVjmidsr3DnW_Q@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
Date: Tue, 06 Sep 2016 21:49:13 -0700
Message-ID: <CAOgPGoD8YEr=+c8eG+YZ=6nSvFB2uk7MiKNgN7Z=wg7ihAUhzg@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Content-Type: multipart/alternative; boundary="94eb2c0cb03ab1a1a4053be3a3ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PAT6DMv3DdKngSrcAIXico-dxPk>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Finished stuffing
X-BeenThere: tls@ietf.org
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." <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: 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.

Thanks,

J&S

On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin <davidben@chromium.org>
wrote:

> 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 <ekr@rtfm.com> 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 <ekr@rtfm.com> wrote:
>>
>>> Folks,
>>>
>>> I have just posted a WIP PR for what I'm calling "Finished Stuffing"
>>>
>>>   https://github.com/tlswg/tls13-spec/pull/615
>>>
>>> I would welcome comments on this direction and whether I am missing
>>> anything important.
>>>
>>>
>>> OVERVIEW
>>> 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.
>>>
>>>
>>> RATIONALE
>>> 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.
>>>
>>>
>>> POTENTIAL VARIATIONS/TODOs
>>> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>