Re: [TLS] Separate APIs for 0-RTT

[David Benjamin <[e-mail]>]

On Wed, Jun 14, 2017 at 7:31 PM David Benjamin <[e-mail]>
wrote:

> 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.
>

I should probably add the two scenarios aren't quite analogous. The 0-RTT
boundary is a problem even in HTTP/1.1-like protocols because there is a
send limit. If you're trying to fit the HTTP/1.1 request before the
boundary, you can't stream it (request body?). The size needs to be known
ahead of time.

David