On Wed, Jun 14, 2017 at 7:31 PM David Benjamin <david...@chromium.org> wrote:
> 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. > 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
