A question for TLS implementation owners: During the discussion of the TLS 1.2
portion of https://tools.ietf.org/html/draft-thomson-http2-client-certs-00, it
was pointed out that HTTP/2 breaks a simplification of the HTTP-TLS interface
that some implementations may have assumed.
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<https://www.imperialviolet.org/2015/10/17/boringssl.html>
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?
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
