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