Re: [TLS] Finished stuffing
Benjamin Kaduk <bkaduk@akamai.com> Fri, 09 September 2016 19:51 UTC
Return-Path: <bkaduk@akamai.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 787E712B31E for <tls@ietfa.amsl.com>; Fri, 9 Sep 2016 12:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.219
X-Spam-Level:
X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 OSaks9_mr4mZ for <tls@ietfa.amsl.com>; Fri, 9 Sep 2016 12:51:01 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0301112B139 for <tls@ietf.org>; Fri, 9 Sep 2016 12:51:00 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4135343346E; Fri, 9 Sep 2016 19:51:00 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 21415433421; Fri, 9 Sep 2016 19:51:00 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1473450660; bh=bmXorXJMztTkvV1AopUeOFE9yG8rFk2r8GawFO77zyU=; l=19669; h=References:Cc:To:From:Date:In-Reply-To:From; b=dijhMLKAzYGHGzZrkJUVcGl8xUZvkL1bqZ/mZ4ZdlH5HIBZO6HiXFTgTnmyziWH+2 BkXbZLg/xqd6TjLRc+bZLorx6vt8K+WBXHome+2Ihgof73XUpXAMx28vPJojCvdmhn fU94jTRti4ALJikNfNZWZxj446X1ujf3hCS3h+YM=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id C0CEF1FC8C; Fri, 9 Sep 2016 19:50:59 +0000 (GMT)
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>
To: "tls@ietf.org" <tls@ietf.org>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <e1048616-22f9-4f37-ee1c-712f97213e31@akamai.com>
Date: Fri, 09 Sep 2016 14:50:59 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAOgPGoD8YEr=+c8eG+YZ=6nSvFB2uk7MiKNgN7Z=wg7ihAUhzg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------6921E47A2487414D48393740"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/QkhQQFApYKMol8nmELqGTbgp1LA>
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: Fri, 09 Sep 2016 19:51:03 -0000
I made a few notes on the pull request. Generally, I support the change, but I get the sense that it may aid the cryptographic properties if we keep the resumption_context and do not overload the resumption_psk as much. I have a slight (i.e., unjustified) preference for doing ClientHello-with-block-of-zeros rather than prefix-of-ClientHello. (Is there a reason to require this extension to be the last one with block-of-zeros? Clearly there is for prefix-of-ClientHello.) -Ben On 09/06/2016 11:49 PM, Joseph Salowey wrote: > 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 > <mailto: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 > <mailto: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 > <mailto: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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_pull_615&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=IwfxQnHf5o1ACITZiQQEOKnbhWK40rJ7uWbCfhm0pSE&s=ukqGqua3EOfqImRb0EFPRRxMv7Hgom3t_5Ki4OvDG8M&e=> > > 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 <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=IwfxQnHf5o1ACITZiQQEOKnbhWK40rJ7uWbCfhm0pSE&s=wIZYtT4TzI4oljhi8_PX1pf95lodfWq4WmQBUXX5Q7g&e=> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=IwfxQnHf5o1ACITZiQQEOKnbhWK40rJ7uWbCfhm0pSE&s=wIZYtT4TzI4oljhi8_PX1pf95lodfWq4WmQBUXX5Q7g&e=> > > > > > _______________________________________________ > 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