On Wed, Nov 11, 2015 at 10:39 AM, Mike Bishop <michael.bis...@microsoft.com> wrote: > Since HTTP/1.1 only has one request per connection and that request is > waiting on the client certificate to be retrieved via renegotiation, you can > assume that the client will not send any application data between the new > ClientHello and sending the Finished message. (“…it is expected that the > negotiation will begin before no more than a few records are received from > the client.”) Likewise, the server will not emit any application data > between sending the HelloRequest and sending its own Finished message. > Since HTTP/2 will have other requests being generated and served in > parallel, this is no longer the case. Per the TLS 1.2 spec, that’s > permitted, but if it’s not been done before, I’m afraid we may be hitting > less-tested code paths. > > I know that BoringSSL explicitly requires that application data flow be > stopped during renegotiation. If the HTTP working group adopts this draft, > do the owners of other TLS implementations expect this to require changes in > their TLS 1.2 implementations?
Chrome, Android WebView etc treat a HelloRequest when HTTP/2 has been negotiated as a fatal error. We do not expect to change this. The TLS 1.3 post-handshake client-auth was intended, as I recall, to support HTTP/1.1 over TLS 1.3. With HTTP/2 isn't it cleaner to do client-auth at the HTTP layer (i.e. by signing exporter values)? SPDY, at one point of development, supported this via the CREDENTIAL frame. That also avoided a confused deputy problem: with connection pooling over HTTP/2, there seems to be a risk of confusion about which requests are authenticated with which client certificate. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
