Re: [TLS] Application layer interactions and API guidance

Nick Harper <nharper@google.com> Sat, 08 October 2016 17:14 UTC

Return-Path: <nharper@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 329431295AD for <tls@ietfa.amsl.com>; Sat, 8 Oct 2016 10:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.696
X-Spam-Level:
X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (2048-bit key) header.d=google.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 RqHeZGjl3oO6 for <tls@ietfa.amsl.com>; Sat, 8 Oct 2016 10:13:57 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 2BBF41295D4 for <tls@ietf.org>; Sat, 8 Oct 2016 10:13:57 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id w3so21962058ywg.1 for <tls@ietf.org>; Sat, 08 Oct 2016 10:13:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3XfyMrydbidFjtOoO+Y2BD2C+Bl+Rw2qRYxLsrD0dT0=; b=ZOoGwlVVU0lTgI75pX8uGN5payCQ1Lgvgf+fIamRr4YrS7hmKOUBKDMjKHOhP2fDnB v9grfDIPHXvMifr8uPNCB1iDyBzJAA1Owh4WaWSTCFaRZ4PqD98rZvlUHlhYiLuA8bUP /auyl2Tg82RfWDJA9N0a9b9kRNd+UvMLY4tkOZoI2bIaxKyj1/UdNRR4V/AptVvL2k+g vWerqyEhHV4tdiOS3ZNwjPZJZA8HZZNdPm5myQ5irx1Jk2eIagXDKoGRj1N3PF35Y10o 8wdDSvXTr1PzeF5dU9XoZMw1XWeKoL1ieU14nYP2v8X7dAYRMjukQVixee5aPyInerlF ca8w==
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=3XfyMrydbidFjtOoO+Y2BD2C+Bl+Rw2qRYxLsrD0dT0=; b=fA/Dn/ImKHJdtLvqjXoTMzOyUWOO/mIJMpFKXtK2T8kuSqGsasD3QpgduMGK+9JXPI wo3pDkziXfU617i5g42KrMfSmfSZ5BOXDtLRzCJum+AxExN2bs0brudcIQlFeeqRo/q3 QLiScISbvbUL6Gk5XULcmzqgHMBduegY49IQgbHcvoZSefeN3MXu2HNFqs8visOBvF/B +D4n6ILTyLdj09q02ZQ5zzwWT60Qx27CymEWDb4La/O1oWJlT2iPIAj8kxHmlW498VtJ nzhvnmYBNsmWJDOu8t65cB4GEdDE3WJqaUDNM2uHh1KgmydctcthcNrkCatYa3u6+wJL bdCg==
X-Gm-Message-State: AA6/9RniI63iwTLPjCfrPvByHxlvz54qE1Wem3XeQtK4ogYUGZw5XAfNYYkeRpTbgFoloiNIosKSuKYmxcBpFNww
X-Received: by 10.13.253.134 with SMTP id n128mr22681763ywf.20.1475946836285; Sat, 08 Oct 2016 10:13:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.253.7 with HTTP; Sat, 8 Oct 2016 10:13:55 -0700 (PDT)
In-Reply-To: <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi>
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>
From: Nick Harper <nharper@google.com>
Date: Sat, 8 Oct 2016 10:13:55 -0700
Message-ID: <CACdeXiK1Wdnd2UaUdPJ6sL-LSW8oQbWyetUJ+3bUQEZY45ax5w@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary=94eb2c06a37ae2c15c053e5da621
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/P5B8xMpOzSn1naNmDF5osqNjvMg>
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:14:03 -0000

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 <javascript:;>>
> > 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 <javascript:;>> 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 <javascript:;>
> https://www.ietf.org/mailman/listinfo/tls
>