Re: [TLS] Separate APIs for 0-RTT

[David Benjamin <[e-mail]>]

On Wed, Jun 14, 2017 at 6:47 PM Colm MacCárthaigh <[e-mail]> wrote:

> On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin <[e-mail]>
> wrote:
>
>> That is, it is not the identity of the bytes that matters much. It's
>> whether the connection has been confirmed when you perform an unsafe
>> action. I believe this still satisfies the properties we want, but without
>> breaking standard interfaces. Very near the TLS stack, at the point where
>> the record boundary abstraction starts leaking (it's common to only give
>> you back a single record on read), either API is equally easy to provide.
>> The looser phrasing is needed for composition once you start going up a
>> layer or to.
>>
>
> Suppose a request, or a frame, spans two different client certificate
> authentication contexts (or unauthenticated, and authenticated); how is
> that handled today? or is it just forbidden?
>

In TLS 1.2, that would require renegotiation, which is not allowed in
HTTP/2. Our client and server implementations enforce this, for this and
other reasons.
http://httpwg.org/specs/rfc7540.html#rfc.section.9.2.1

Sadly, in Chrome as an HTTP/1.1 client, we are stuck with supporting this
mess, so we allow it at HTTP/1.1, but we will only accept client
certificate requests between request and response and further forbid all
handshake/application interleave. HTTP/1.1 without pipelining is just
barely simple enough that one can get away with all this. (In all other
cases, BoringSSL does not support renegotiation at all.)

The mess around trying to make byte boundaries semantically meaningful is
why I'd previously advocated leaving TLS 1.3 post-handshake auth to the
application profile, and why I advocated that it never be allowed in
HTTP/2. HTTP/2 should use something at its layer, possibly leaning on
exported authenticators. We have no plans to implement TLS 1.3
post-handshake auth in BoringSSL, but if we were ever to implement it, it
would likely be under the same constraints as renegotiation (off by
default, client-only, HTTP/1.1-only, and only at that one point in the
protocol with no interleave).

I assume what you're getting at here is that my 0-RTT and post-handshake
auth preferences are the opposite? :-) That's true. In the post-handshake
auth case, making the boundary insignificant to the higher-level protocol
isn't really feasible. Conversely, forbidding 0-RTT with HTTP/2 would be
rather unfortunate. But it seems the tight synchronization is not needed
here, so we don't need to go that route.