Re: [TLS] Finished stuffing
Eric Rescorla <ekr@rtfm.com> Wed, 07 September 2016 23:19 UTC
Return-Path: <ekr@rtfm.com>
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 ABDBD12B095 for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 16:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 OaVXDl0M_zCV for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 16:19:38 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 92D2912B010 for <tls@ietf.org>; Wed, 7 Sep 2016 16:19:38 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id g192so18721170ywh.1 for <tls@ietf.org>; Wed, 07 Sep 2016 16:19:38 -0700 (PDT)
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; bh=W6BVOblMjS7tSHc7ywlV959+byiHbJkwIJ0hp5+zwMQ=; b=rbNhmUL8qkc/O30DIxlagJacIFNee3Yqhv0B/HqRQtT4y0fXAOU72ft38JBbIC3wVE nlC5WqmN9szH1xwRxQmNF1GB5OGGpAmPgRbl7KJunSK43ggTzekMUuxL6W+SHVgwCQe6 ZTm3bQBRR57q2cI7Zl6SsFZ+xvc7+lNFBugh5GpzxZFGGyJ4efibwEtrZfWY8wWVwKHV 7ITgjFwxN8o7LGMOysHJoz7wUAVeLCj0VmcoQl94q0Um0u298fp8qCo0lC75O7180Xy3 qIBC+1SqbZr8KOd/Ry8TgZwJZASodngoXw4FpE65EwhpQvvtb+5SeoAFfN3/g75Cc/Go KxrA==
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=W6BVOblMjS7tSHc7ywlV959+byiHbJkwIJ0hp5+zwMQ=; b=HTBq0ahgdYH1wHc6Htvgiaw4BYqO+S4VfhtJPHizmrxtrMRdLNDK8hisyPRPV9/En9 pqUSXwWhUx5GVvYP3R/Yx6D+cb0YOQAH0NAXyHkg1PieYPuxIqtTyvinn8rM5fFq6K+l ss07peIa0Ns3YaiXYEz0UqR9Fd+xAaVzncDIf0hEDK+N63+Y9tB+vFagyLSJHccE1Poa 4Xn4cgE2doOMFvH43AR+5fDhK0BG6bcB+eODKY/lGmqt274veoA2f7Pcr3dlwrK8MO46 bItK3QTEQ3UzLbn0k5juSRwAKPi041elG15cAz1erfJ2a3kqvfoMbGpn4x6BMgQN80ty WBYw==
X-Gm-Message-State: AE9vXwOq+qoNfjncvz2fPgGzPxrQxzuwwazhdOaqEtz1NJc5pu9UsA0ymCfg82FADn4TnpiK/bLbASAwuwhgEQ==
X-Received: by 10.13.220.1 with SMTP id f1mr41940256ywe.289.1473290377654; Wed, 07 Sep 2016 16:19:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.32.70 with HTTP; Wed, 7 Sep 2016 16:18:56 -0700 (PDT)
In-Reply-To: <CADi0yUNs1+j73seG653epbSk52OnTAxnw6sLCK8kJkZqS902nw@mail.gmail.com>
References: <CABcZeBNqs+6SYsA9SnED8nWkUXifSPuF4gBdRG-gJamtWmxWNw@mail.gmail.com> <CABcZeBP890QrcbpGR9Ht2RkfHShavkkDmvvKPP+81x8Bz+SeDA@mail.gmail.com> <CAF8qwaCVyRrSm-XtL6Jd_VKD9qGmCJNFJW1GZVjmidsr3DnW_Q@mail.gmail.com> <CAOgPGoD8YEr=+c8eG+YZ=6nSvFB2uk7MiKNgN7Z=wg7ihAUhzg@mail.gmail.com> <e7729a05efe1d204bc6ee2ab2f59ae9d@maxg.info> <CABcZeBM2wqgxdsLonLzTtPChyZ14KSMwzy1HQukTL_5gXXWLmw@mail.gmail.com> <CAF8qwaB=JJ_5V9RuJNdqSmj1c=yNMANzKBksM-6TLtfnf6j57g@mail.gmail.com> <CABcZeBMhthzSWbJa_Gkt6MB-RfrAOq=VT6GU9i7GTefq0Gj2Fw@mail.gmail.com> <CADi0yUNs1+j73seG653epbSk52OnTAxnw6sLCK8kJkZqS902nw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 07 Sep 2016 16:18:56 -0700
Message-ID: <CABcZeBP1hNEbxbxwxQN===CT7XdBXwQ87MG5ibsOJDS7i4gBqw@mail.gmail.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Content-Type: multipart/alternative; boundary="94eb2c0809f09ca236053bf3255f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ip-k1CNgBbK7MGQp7dCfvB8fzH8>
Cc: Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>, "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 23:19:42 -0000
On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote: > I don't understand the proposal. > Are you proposing to eliminate resumption_context (RC) from All its > current uses and replace it with the hello_finished extension? > Yes. > Or is this to affect only certain uses of RC? Which ones? > One important property of RC is that it serves as a binding with the > original context that generated a resumption PSK, in particular a binding > with the server's identity (certificate). This is not achieved by the > hello_finished extension, is it? > It is supposed to do so. The reasoning is: - RMS is unchanged and therefore derived from the server certificate - The HelloFinished computation is HKDF(F(RMS), <ClientHello>) and therefore also is derived from the server certificate. Is that insufficient. I also have a problem with names. "Resumption context" is very explicit > about providing, well, resumption context. > "Hello_Finished", in turn, means nothing. > Also, RC may better match the notion of "binder" hence more naturally > requiring collision resistance, while all Finished uses in TLS (1.3 and > before) have a MAC functionality (for which, say, 128 bits are good enough) > and it would be better not to abuse them for other uses. > Two points about this: 1. The Finished in TLS 1.3 is always Hash.length, and our minimum hash is SHA-256, so I believe we have enough strength here. We could of course require a minimum size. 2. I wouldn't object to changing names here, of course. Best, -Ekr > Anyways, maybe this is just the result of my misunderstanding of the > proposal. > > Hugo > > > On Wed, Sep 7, 2016 at 11:26 AM, Eric Rescorla <ekr@rtfm.com> wrote: > >> >> >> On Wed, Sep 7, 2016 at 8:25 AM, David Benjamin <davidben@chromium.org> >> wrote: >> >>> On Wed, Sep 7, 2016 at 11:11 AM Eric Rescorla <ekr@rtfm.com> wrote: >>> >>>> On Wed, Sep 7, 2016 at 6:54 AM, Antoine Delignat-Lavaud < >>>> antoine@delignat-lavaud.fr> wrote: >>>> >>>>> Regarding whether the placeholder zeros should be part of the >>>>> transcript for the stuffed finished, an argument against it is that it >>>>> violates the incremental nature of the session hash. If the hash stops >>>>> before the placeholder, it can be resumed with the computed finished; >>>>> otherwise, it must be rolled back. >>>>> >>>> >>>> This isn't a big deal for me (or I think any other implementor) either >>>> way, because of the actual way we compute the hash. >>>> >>> >>> To expand on that, because the final PRF hash is not known at the time >>> we send ClientHello, most implementations I've seen just buffer the full >>> transcript before this point. >>> >>> But one could also keep a rolling hash of all the supported PRFs >>> (there's all of two of them if you lose TLS 1.1 and below), so I think >>> that's a good argument for using the prefix rather than zeros. For >>> implementations keeping a buffer, I don't think it matters, so let's keep >>> both strategies happy. >>> >> >> This is certainly fine with me. >> >> -Ekr >> >> >>> >>> David >>> >>> >>> >>>> -Ekr >>>> >>>> >>>>> >>>>> Best, >>>>> >>>>> Antoine >>>>> >>>>> >>>>> Le 2016-09-07 05:49, Joseph Salowey a écrit : >>>>> >>>>>> 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 [1] >>>>>>> >>>>>>> >>>>>>> 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 [2] >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> TLS mailing list >>>>>> TLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tls [2] >>>>>> >>>>>> >>>>>> >>>>>> Links: >>>>>> ------ >>>>>> [1] https://github.com/tlswg/tls13-spec/pull/615 >>>>>> [2] https://www.ietf.org/mailman/listinfo/tls >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >> >> >
- [TLS] Finished stuffing Eric Rescorla
- Re: [TLS] Finished stuffing Eric Rescorla
- Re: [TLS] Finished stuffing David Benjamin
- Re: [TLS] Finished stuffing Joseph Salowey
- Re: [TLS] Finished stuffing Antoine Delignat-Lavaud
- Re: [TLS] Finished stuffing Eric Rescorla
- Re: [TLS] Finished stuffing David Benjamin
- Re: [TLS] Finished stuffing Eric Rescorla
- Re: [TLS] Finished stuffing Hugo Krawczyk
- Re: [TLS] Finished stuffing Eric Rescorla
- Re: [TLS] Finished stuffing Hugo Krawczyk
- Re: [TLS] Finished stuffing Ilari Liusvaara
- Re: [TLS] Finished stuffing Salz, Rich
- Re: [TLS] Finished stuffing Hannes Tschofenig
- Re: [TLS] Finished stuffing Hugo Krawczyk
- Re: [TLS] Finished stuffing Ilari Liusvaara
- Re: [TLS] Finished stuffing Martin Thomson
- Re: [TLS] Finished stuffing Benjamin Kaduk
- Re: [TLS] Finished stuffing Ilari Liusvaara
- Re: [TLS] Finished stuffing Hugo Krawczyk
- Re: [TLS] Finished stuffing Ilari Liusvaara
- Re: [TLS] Finished stuffing Benjamin Kaduk
- Re: [TLS] Finished stuffing Ilari Liusvaara
- Re: [TLS] Finished stuffing Eric Rescorla
- Re: [TLS] Finished stuffing Ilari Liusvaara