On Wed, Jun 14, 2017 at 6:47 PM Colm MacCárthaigh <c...@allcosts.net> wrote:
> On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin <david...@chromium.org> > 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
