Re: [TLS] Separate APIs for 0-RTT

[Eric Rescorla <[e-mail]>]

On Tue, Jun 13, 2017 at 11:54 AM, Ilari Liusvaara <[e-mail]>
wrote:

> On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote:
> > The current text says:
> >
> >    0-RTT data has very different security properties from data
> >    transmitted after a completed handshake: it can be replayed.
> >    Implementations SHOULD provide different functions for reading and
> >    writing 0-RTT data and data transmitted after the handshake, and
> >    SHOULD NOT automatically resend 0-RTT data if it is rejected by the
> >    server.
> >
> > I think the second piece of guidance (about automatic re-send) is still
> > good but it seems like implementations are mostly converging on a single
> > API. Of the implementations I know, NSS, BoringSSL (I think), and Mint
> have
> > a single API and OpenSSL's use of two APIs is an outlier. I don't think
> > it's helpful to have a SHOULD that a lot of people violate, especially
> when
> > this also indicates we don't have consensus on this SHOULD.
> >
> > I propose we remove this recommendation in favor of one which simply says
> > that implementations should need applications to opt-in to 0-RTT. That
> > would allow implementations to have either API.
>
> I think it is VERY bad idea for TLS client library to do 0-RTT without
> application explicitly opting in to that (e.g., via setting a special
> setting, or using API call sequences that didn't work at all for
> n-RTT).
>

I agree with this. I am suggesting that a setting rather than a separate
API is a
reasonable approach.

-Ekr


>
> Consider for example that:
>
> - The application starts by sending a POST request.
> - The application starts by sending a GET to confidential URL.
>
> Both cases lead to things possibly going very badly wrong if TLS
> library silently does 0-RTT. And both are kind of requests that might
> be written before TLS connection is fuly up.
>
> And if ALPN is included, there is always a possibility that the
> initial guess on protocol was wrong, and the data can't just be
> autoretransmitted, but TLS stack has to ask the application to
> roll back the state.
>
>
> The server side does not have as obvious failure modes if 0-RTT is
> enabled without application knowledge, but that does not mean such
> failure modes are not out there.
>
>
>
> -Ilari
>