Re: [TLS] Application layer interactions and API guidance
David Benjamin <davidben@chromium.org> Sat, 08 October 2016 17:32 UTC
Return-Path: <davidben@google.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 9AE4A129543 for <tls@ietfa.amsl.com>; Sat, 8 Oct 2016 10:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.695
X-Spam-Level:
X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 0SWVm5H40UeP for <tls@ietfa.amsl.com>; Sat, 8 Oct 2016 10:32:21 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 CA821129466 for <tls@ietf.org>; Sat, 8 Oct 2016 10:32:21 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id r30so75278431ioi.1 for <tls@ietf.org>; Sat, 08 Oct 2016 10:32:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H4ZKlHT3NY1aHnTJvxySXTekaY+fn6d49yNDuHoQsrI=; b=KIjo8REtYYvvCyhcjyHhnBLcK9B8nM5SXtrWX8Bp3EdPeVoUi8tzvZPV6/l2XP04wQ DMM2NwzUWa26eH7iVDD/ZPzU+CscuDIFoOqCxg4neezX361uYRsJkvqOHzMt09WNSVH/ d3vSBFkFC0l04kF3URG9d70WNs1OvJalO7XTc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H4ZKlHT3NY1aHnTJvxySXTekaY+fn6d49yNDuHoQsrI=; b=PHn+IJ1i2yBgkfyvgsNdYk9YwKNDuwLEjvmTFI/b1FkVEOIKhXHnndhZ68971070r0 MGzZSKjCh4OwEpBIAr/igxG+FDP7kUMmzp0gNtOKX4wK8dGD2Z62Mh2NozILt1UKlhbI b4zP0d9MLc9XZ4fq141AFNUKFeyj3aZF82e/ZY6ld57lWS8N8PJQnO3lr3IELdPMEphX TzqYmF0165uV0iyBhoxr6fxxv3nvVNeRdagCNXIhpItjRMTI4xa643VQl5QzYTV1N+Ew eDfGr4bQJAoc1iNXhvulNVQzImmPa0GC8E97m6/NWVVb7KgNukIKTBLe/QO6H3QRZaz5 VIiw==
X-Gm-Message-State: AA6/9RkEuqwmVaFlq7xzgcpVyCjUlulRsBhk+blXUInl3Jhz9kRDo8iaC+P7DRPzOnWYwtsYNypTPyLVdAewbqM1
X-Received: by 10.107.136.232 with SMTP id s101mr25265030ioi.171.1475947940887; Sat, 08 Oct 2016 10:32:20 -0700 (PDT)
MIME-Version: 1.0
References: <CACsn0c=B0dVGaXKawW5DJCUfJfqFFHkk_cZCzjzKs53n4UKLpg@mail.gmail.com> <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <CACsn0cnpEq_00R37WZOm39dg9dXKSkpNjGt3FWg0uLgTEkwtRw@mail.gmail.com> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBNU0HVqkZm6zb63xZzf4+ZQjXb8CacuYH77Fe_=dfFPhw@mail.gmail.com> <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> <CACdeXiK1Wdnd2UaUdPJ6sL-LSW8oQbWyetUJ+3bUQEZY45ax5w@mail.gmail.com>
In-Reply-To: <CACdeXiK1Wdnd2UaUdPJ6sL-LSW8oQbWyetUJ+3bUQEZY45ax5w@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Sat, 08 Oct 2016 17:32:09 +0000
Message-ID: <CAF8qwaDQqceewkg5XoN+8iiHtNO=J9YHH_aRS5+k_4fKTJvfeA@mail.gmail.com>
To: Nick Harper <nharper@google.com>, Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="001a113ec3b4b98aba053e5de8a8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8fdaz0XxVDyzewxCp2B3Ss0G-1Y>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Application layer interactions and API guidance
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: Sat, 08 Oct 2016 17:32:24 -0000
To add to that, in out-of-order transports, whether a message was sent over 0-RTT or not may not even be very well-defined. If QUIC originally sent data over 0-RTT but had to retransmit it after the full connection parameters are available, I believe it will use those. Even in an in-order transport, imagine if I have a very long replayable request in HTTP/2 (maybe it's a PUT and comes with a request body, or maybe it has too many headers). I start sending that one over 0-RTT. While I'm in the middle of sending that, I get back a ServerHello (w/ early_data) through Finished. I either need to complete the handshake and switch to 1-RTT mid-request or wait for the long request to complete before finishing the handshake or sending any non-replayable ones, though they may be higher priority. (They probably are if they don't come with as giant of response bodies...) The former is by far the more attractive option. Or perhaps I hit max_early_data_size ( https://github.com/tlswg/tls13-spec/pull/674) and thus can't send more 0-RTT data anyway. In HTTP/2 you have the additional amusement that, due to HPACK, your 0-RTT data probably has an effect on the 1-RTT data even if requests are all or nothing. I don't think we can make the receiver aware of the 0-RTT / 1-RTT boundary sanely. In my mind, the decision whether to send something 0-RTT or wait until 1-RTT is primarily the sender's business. If the sender wanted to, it could make the data replayable anyway by just replaying it. On the receiver's side, yeah, you concatenate the streams. That's why the server must decline 0-RTT if any negotiated parameter (ALPN, etc.) changes. David On Sat, Oct 8, 2016 at 1:14 PM Nick Harper <nharper@google.com> wrote: In my proposed 0-RTT Token Binding draft ( https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-01), the signature is the same in 0-RTT data as in 1-RTT data, assuming the server didn't reject early data. The thought here is that a client's write API might look like "please send this data, and I'm fine with it being sent 0-RTT", so the Token Binding code doesn't have to know if its message was sent before or after handshake completion. If early data is rejected, then the application data has to change, but this isn't something limited to Token Binding. A server cold reject early data and also change ALPN from what the client expected, requiring the client to send different data. I think it's fine from an API perspective for data sent 0-RTT to also be sent 1-RTT so long as early data is accepted. On Saturday, October 8, 2016, Ilari Liusvaara <ilariliusvaara@welho.com> wrote: On Fri, Oct 07, 2016 at 03:04:14PM -0700, Eric Rescorla wrote: > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara <ilariliusvaara@welho.com> > wrote: > > > On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: > > > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara > > > <ilariliusvaara@welho.com> wrote: > > > > > > > > Also, it is very likely that 0-RTT would need its own read API, because > > > > it is pretty unlikely that existing API could be safely retrofitted > > > > or even purpose-built unified API be designed that isn't just asking > > > > for security problems via mixing 0-RTT and 1-RTT data. > > > > > > Yes. In particular I think the TLS state machine transitions need to > > > be ordered with respect to the arrival and sending of data. The > > > challenge for a multithreaded program (yes, some programs have > > > multiple threads sending and receiving at once) is making this make > > > sense, or even a single-threaded program where the TLS stack can > > > change state at times not visible to the sending thread. Maybe there > > > is some slop here, like 0-RTT can become 1-RTT on send, but this > > > raises all sorts of problems for receiving. I think we need to require > > > separation in the API. > > > > 0-RTT can't be allowed to become 1-RTT on send (unless it is auto- > > retransmit, which needs to be disableable, as sometimes that just plain > > won't work). > > Can you explain why that is? E.g. what they are planning to do with 0-RTT Token Binding in HTTP. The client puts in a signature into 0-RTT data. If the server rejects the 0-RTT and the client retransmits, the signature will still be there but is different. Also, if 0-RTT data can silently shift to 1-RTT, it would mean the server-side model would be to concatenate 0-RTT and 1-RTT data, which I thought we already established is quite dangerous. -Ilari _______________________________________________ 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] Application layer interactions and API guid… Watson Ladd
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Watson Ladd
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Eric Rescorla
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Watson Ladd
- Re: [TLS] Application layer interactions and API … Eric Rescorla
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Eric Rescorla
- Re: [TLS] Application layer interactions and API … Nick Harper
- Re: [TLS] Application layer interactions and API … David Benjamin
- Re: [TLS] Application layer interactions and API … Watson Ladd
- Re: [TLS] Application layer interactions and API … Kyle Rose
- Re: [TLS] Application layer interactions and API … Martin Thomson
- Re: [TLS] Application layer interactions and API … Kyle Rose
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Kyle Rose
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Kyle Rose
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Kyle Rose
- Re: [TLS] Application layer interactions and API … Eric Rescorla
- Re: [TLS] Application layer interactions and API … Kyle Rose
- Re: [TLS] Application layer interactions and API … Watson Ladd