Re: [TLS] Application layer interactions and API guidance
Watson Ladd <watsonbladd@gmail.com> Mon, 10 October 2016 20:49 UTC
Return-Path: <watsonbladd@gmail.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 26EB812974E for <tls@ietfa.amsl.com>; Mon, 10 Oct 2016 13:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8sepjhXkmrv5 for <tls@ietfa.amsl.com>; Mon, 10 Oct 2016 13:49:13 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 EF79D1293FE for <tls@ietf.org>; Mon, 10 Oct 2016 13:49:12 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id o68so2396345qkf.3 for <tls@ietf.org>; Mon, 10 Oct 2016 13:49:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a0X3VVyXPuNXwfhFCHVWtax2H3B8ZvpuB9DIZHGiob4=; b=M8XeqlU+WITY3gFDJFDOIKN82JV1VaJ+jGqqRzkyNglsH8cijZ2Qg/Nw6ADeBHR++z llV4raH3ZsbqhbEai3i/rktD8MR6uZFjnB3i4k1ShHUT+nteLfzVvNYGNZCrEoPj/Dg/ H9qGQFT1n8lQMeGsJ/RSFK/OxB18je4ErDR9zQGNXP3ZYdj1VpLtmKTpzskMIZ2MfRxx V1Gtv+KdB3nEU/8WIvCRFAq1mZ94S8FfXOASwkKRHB4ZNfZHl+vCdCpoa1jPZgg3Sa/k SBqx1RklYHkhga4WkcPNfpDPJNRbYi+IYdTUFDAaCcQYWQc38+6CX0qDW7+c2Z98t9SB egew==
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=a0X3VVyXPuNXwfhFCHVWtax2H3B8ZvpuB9DIZHGiob4=; b=HngSSWa5duDSXztEOzZg8yjZEmMbO1Jtky5VJSklaNkMkAVd3cQTRCGkefTr7noeT/ pLUR/FWJgzIoH11yk2vmsWd2F72ojgnrsNfbynga69y/reo67se11iVF8fytWSXrZiRr w4LxlOkt+QF7FS7fYWLVissuCDx7oPqathLuYL4K4iO4B1fTTtHX66I0yvxmzpeJ47gH mk2ygzd1T51QHVVJu+Hkx7MCWGvv8zc6RTbkGKyBnCG6OywpIGA1lk78fRnwndUALi03 5KLr5PnjPr7t4eEf3Louo2P4OKqciqbO+RvXJJB2BBj0pEbjvw96tvsyfz3hdsT/S0Ad g90w==
X-Gm-Message-State: AA6/9RkKiJ3ZAC045w9M8N4M2h5qzHNKv4gU+L6S+lomwBPKknJ/tnQN/W8x0h/j7+CgP5edFndqYoheqNVsVA==
X-Received: by 10.55.138.66 with SMTP id m63mr142814qkd.159.1476132551942; Mon, 10 Oct 2016 13:49:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.171.87 with HTTP; Mon, 10 Oct 2016 13:49:11 -0700 (PDT)
In-Reply-To: <CAF8qwaDQqceewkg5XoN+8iiHtNO=J9YHH_aRS5+k_4fKTJvfeA@mail.gmail.com>
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> <CAF8qwaDQqceewkg5XoN+8iiHtNO=J9YHH_aRS5+k_4fKTJvfeA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 10 Oct 2016 13:49:11 -0700
Message-ID: <CACsn0ckz72rhSCQTYRvmWB6n_tdvB5E-V7ssV6qjGO6=qsXY+w@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Bt0qrzCfEBRgKhBXtYxxlZoPZMM>
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: Mon, 10 Oct 2016 20:49:16 -0000
On Sat, Oct 8, 2016 at 10:32 AM, David Benjamin <davidben@chromium.org> wrote: > 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. The problem is with poorly-behaved senders and attackers resending 0-RTT data. Receivers should be able to ensure side-effectfull operations are not carried out by 0-RTT data. Making 0-RTT silent in APIs transforms an interoperability issue into a silent security issue. This is not a good idea. > > 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 mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau.
- [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