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.