Re: [Unbearable] 0-RTT Token Binding: When to switch exporters?
Eric Rescorla <ekr@rtfm.com> Mon, 20 March 2017 23:13 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB96129401 for <unbearable@ietfa.amsl.com>; Mon, 20 Mar 2017 16:13:19 -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 mQRVT4mOMycu for <unbearable@ietfa.amsl.com>; Mon, 20 Mar 2017 16:13:17 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 B9588126D85 for <unbearable@ietf.org>; Mon, 20 Mar 2017 16:13:16 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id v198so99965777ywc.2 for <unbearable@ietf.org>; Mon, 20 Mar 2017 16:13:16 -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=HDaBobmOGyjeQ8/O4AG8SKQebTe9B3K9nlaSLEcsbFs=; b=Vq6FEvC5O3ljcr3i7VgRsUg5TilzpZNn+OInGXlHC0Nj89E0o4CEe+teikee8Gba1Y kNsh1DEkB4TiwvYQsAhoEnXJHq4lhXjgxKIOImZw64KpDPpDrJjSDn9rWem3cIgkmhlw U6uSbrOguCpX95h9zibg8XA7mCa5/AhqsKOVg2g1nCcJiZbb/N8QnRqX++KlGzOdvjvE nCK/925O9K5EvKFmthCBwixrLnEuFst3mTRsYmRdNRM08zMTXCqka8s0llyjyR6mK/+T EckKjtbxA44yxGaX/+84EfrOK4FA0Q9+Twyrv02389e2mMvSfM8q5ChmQraPW/IKAfrj 02Sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HDaBobmOGyjeQ8/O4AG8SKQebTe9B3K9nlaSLEcsbFs=; b=mW1VbhQfhse8zkX5uSJVVWvmztl+UUaxlvAynlFyfgRGAAooGSHoQI+o8nak46egkU IfjMsUTLIMAtsf81PdiXOUK19uiPE5TJjogs07QkHXXKbGH5AV98ArNY66R1tRNLuiTy 6Mm10pK5dKlihDoqV9DVDJfNSesYFpXfG3MraiV+2ApHdkVwht3SOvzBfPMmNpvU2WAa KPYNGeL/iWAZSUMk+OPLBB8ImKftGllK9YjJnC2h8M6pBhyxk5tsT9Fp32fgIbvzj5kg Rj4EsfRN2v4cxsbxXv/OSV2iWW4+jQ6V1SIFRTajRouL3y3Kyn+0tXyMJUYkzPjhCQJS b8Mg==
X-Gm-Message-State: AFeK/H21/tMhruIffbKt3WSHxvLdcgLe28pqETjDRh2D/HY0moZJgqTMWCW/w5NZIyWTv5Sx+QUpYRTrsUOxJQ==
X-Received: by 10.129.92.84 with SMTP id q81mr17197897ywb.87.1490051595966; Mon, 20 Mar 2017 16:13:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Mon, 20 Mar 2017 16:12:35 -0700 (PDT)
In-Reply-To: <CACdeXiLZQSMxSqTPSHVqUwZomUpaMadUNYEEzF2to9Rx6nLMWQ@mail.gmail.com>
References: <CACdeXiK2Hs=Kz_5OFryWR+9_t6nDL_p7NKjw=CwRsua_E5S9Mw@mail.gmail.com> <DM2PR0301MB084793F58146F8574BF36EE18C780@DM2PR0301MB0847.namprd03.prod.outlook.com> <CACdeXiJGcsTxrSWmd5BZrfoWTHhFF3+RisQFD628iYNMzZakhQ@mail.gmail.com> <CACdeXiJFe7-jM9qEnNB+Wp3joGxF_X1z+-dPywb9SRZuSNmAzQ@mail.gmail.com> <DM2PR21MB0091E3F087E1AECA3A63A3788C560@DM2PR21MB0091.namprd21.prod.outlook.com> <CACdeXi+YjLaXtoX47LtVK4Ay2y-mCOOraV46gbbbuQPL40ngXg@mail.gmail.com> <DM2PR21MB00910C83983BEE885B0E04288C560@DM2PR21MB0091.namprd21.prod.outlook.com> <CACdeXiLON5OAjfFCNsenCeaGV3a_LDoi17VAk=fSzF0YA5=f7Q@mail.gmail.com> <CACdeXiLNCrPSz0_hZSpQ6tsoHB7ryJ2dCnHjUYwu5vu5fO4XBg@mail.gmail.com> <SN1PR21MB0096D7426A4E230E284F0D058C560@SN1PR21MB0096.namprd21.prod.outlook.com> <CACdeXiKuzNh0fP9b-jEF82m-6mX+i04To96GMa_tFNcuznGn+A@mail.gmail.com> <DM2PR21MB00914BA07BA984E931B88FEB8C290@DM2PR21MB0091.namprd21.prod.outlook.com> <CACdeXiKQjaoAArLBcjRj+kUJUqH+f1bA5yeCCiQ6GMXzWJURBw@mail.gmail.com> <CABkgnnV0+vumfkZAMRZ_8q5pTkwf_CqhZ+deeVWdbF9SFaHoJw@mail.gmail.com> <DM2PR21MB0091DE5B213D2363FAF353CF8C280@DM2PR21MB0091.namprd21.prod.outlook.com> <CACdeXiKweRaZEKi4kqmPfUc2JLyZLGbp8tFRpkTfmJisPCMWRg@mail.gmail.com> <CACdeXiL6riBRb1-UDhVK-R5CvopzisJnYTRjWsvpimWA2G3DhQ@mail.gmail.com> <CABcZeBN2RhBsyj8_1F6bBnw9j10qdABwdZVdgwVcUr4Tf6sLtA@mail.gmail.com> <CACdeXiLZQSMxSqTPSHVqUwZomUpaMadUNYEEzF2to9Rx6nLMWQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 20 Mar 2017 16:12:35 -0700
Message-ID: <CABcZeBPvxX-8PuoV1oV-k5BnH3sjbWuuHfeAfh7FRhgtuVPkCQ@mail.gmail.com>
To: Nick Harper <nharper@google.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>, IETF Tokbind WG <unbearable@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="001a114d85701332a1054b31acca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/WM3p4kB9bMHLypHCkLU2EHfdmj0>
Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters?
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Mar 2017 23:13:19 -0000
On Mon, Mar 20, 2017 at 12:18 PM, Nick Harper <nharper@google.com> wrote: > On Mon, Mar 20, 2017 at 9:56 AM, Eric Rescorla <ekr@rtfm.com> wrote: > > I'm not quite sure I understand the reasoning here, so let me try to walk > > through it. > > > > The HTTP stack tells the TLS stack to initiate a connection and starts > > streaming > > requests down to the TLS stack. At this point, it can only use the 0-RTT > > exporter, > > so it has to do that. At some point in this process, the client receives > the > > 1-RTT > > Finished and can then switch to the 1-RTT exporter, but the serves has no > > way > > of knowing at which point that is. > > As the client's HTTP stack is streaming requests down to the TLS stack > (expecting that they be sent as 0-RTT data), a few things could > happen: > - The TLS stack could have received the server's Finished, so the TLS > stack decides to finish the handshake and send all future data > streamed from the HTTP stack post-handshake. If the HTTP stack starts > preparing the request just before the TLS stack receives the server's > Finished, the HTTP stack will generate a Token-Binding header using > the 0-RTT exporter, and then stream it to the TLS stack which sends it > post-handshake. We could try to assume that the TLS stack will fail > any requests to stream data once the handshake is complete and require > the HTTP stack to call a different function to send non-0-RTT data. > However, this runs into another problem. > - The TLS stack can choose how to fragment messages. When the HTTP > stack streams a request (which contains a Token-Binding header) to be > sent over 0-RTT, the TLS stack could fragment the HTTP request in a > way that splits the Token-Binding header between TLS records, and puts > half of it in 0-RTT data and the other half in post-handshake > application data. (Or, if the "stream early data" function call > returns an error if the HTTP stack tries to send 0-RTT data after the > handshake is complete, the HTTP stack is now stuck with half of a > request sent and a field it needs to change but has already sent half > of.) > - This split of a Token-Binding header across 0-RTT and non-0-RTT data > could also be caused by the TLS stack hitting the max early data size > required by the server. > - In QUIC, even if the HTTP/QUIC/TLS stack provides some way to > guarantee that an HTTP request will end up entirely in 0-RTT data, a > packet containing part of the Token-Binding header could get lost > until after the TLS handshake is complete, at which point QUIC will > retransmit it under the new keys. Given this possibility of > retransmission, how is the server to know which exporter to enforce > use of? > I feel like this text argues for why you need to have a "which exporter was used" flag, right? > In the current rule, the client MUST switch when it sees app data from the > > server, > > I assume you're referring to paragraph two of section 2.1.1 of > draft-ietf-tokbind-tls13-0rtt-01? Now that I re-read that, it does not > convey what I meant it to mean. I think what I meant to say is that > after a client receives an application-layer response from the server, > it must use the exporter_secret for all future token bindings in > application messages that are in response to the received > application-layer message from the server. > Do we really want to allow inversions? E.g., I send request A with the 1-RTT token binding and request B afterwards w the 0-RTT token binding? Becase this text would allow this. Essentially, the problem I'm trying to work around is that there is a > non-zero amount of time between the HTTP stack building a request > (specifically, the part of that where it builds the Token-Binding > header) and the HTTP stack sending that request to the TLS stack. (If > the HTTP stack is streaming the request to the TLS stack as the > request is being generated, this end time is when the last byte of the > HTTP request hits the TLS stack.) During this time, the TLS handshake > could have completed. If a client starts building an HTTP request > after it has seen application data from the server, then we can > guarantee that the client will be able to use the 1-RTT exporter. > However, the client could start building an HTTP request before it has > seen application data (and before the TLS stack has seen a Finished > message from the server), but send that after the client's TLS stack > sends its Finished message. This is the case that I want to allow. This does seem reasonable. Note that it's not directly observable by the server when you do this one way or the other. Let me think if there's a way to write this that relies less on request/response semantics. Perhaps: Any HTTP requests which the client initiates after sending its Finished MUST...? -Ekr > so if the server receives a HTTP request from the client that is > > semantically > > dependent on some HTTP response from the server, then it knows that the > > client should have switched at this point. However, ISTM that SFIN must > > have appeared prior to the any such application layer message, so > requiring > > the client to switch on SFIN would make the switch happen slightly > earlier > > and give the server the same guarantees. What's the argument for not > > requiring > > that instead, given that it's tied to the state of the TLS stack rather > than > > the > > HTTP stack. > > > > -Ekr >
- [Unbearable] 0-RTT Token Binding: When to switch … Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Andrei Popov
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Andrei Popov
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Andrei Popov
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Andrei Popov
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Andrei Popov
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Martin Thomson
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Andrei Popov
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Eric Rescorla
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Eric Rescorla
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Eric Rescorla
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Martin Thomson
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Eric Rescorla
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Andrei Popov
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Andrei Popov
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Nick Harper
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Bill Cox
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Denis
- Re: [Unbearable] 0-RTT Token Binding: When to swi… Andrei Popov