Hi, folks - Martin and I had come previously to the TLS WG to discuss our work with handling client certificates at the HTTP layer. Based on that discussion, we revised our model to cover signatures of an exporter value and carry the proof in an HTTP/2 frame. During BA, the HTTP WG expressed interest in flipping the model in the opposite direction - carrying additional server identities as well. That means we now have a proposal for carrying both client and server certificates above TLS, found at https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs.
We have also discussed that it might be preferable to pull part of this capability back into TLS, expanding post-handshake authentication to allow providing multiple certificates in either direction. Since that would necessarily require additional work on that part of the TLS 1.3 spec, we discussed the possibility of splitting post-handshake authentication into a separate spec so that the core TLS 1.3 spec could proceed to WGLC as scheduled and take a little longer on the second draft. Having spoken to some other TLS WG members, some people would prefer to move post-handshake authentication entirely to our layer. While that's probably not feasible (HTTP/1.1 still needs post-handshake auth from TLS, regardless of what HTTP/2 does), we can retain our application-layer authentication. This has the advantage of leaving TLS 1.3 unchanged, but keeps a security draft in a non-security working group. We are concerned that, by doing this at the HTTP layer, we'll be missing necessary security expert review as this moves forward. (EKR already suggested some necessary improvements to our signature model to prevent some pretty trivial attacks; these aren't reflected in the current draft.) If that's the route we go, I would greatly appreciate some TLS folks visiting the HTTP WG and helping us review this draft. I was on the "time permitting" list to present in the TLS meeting on Tuesday, and we didn't get a chance to. We'll be discussing the actual draft tomorrow morning in HTTP; I'd be happy to have some TLS folks there to discuss the draft, and I'd like to get a sense from the TLS WG whether there's a preference for us to do this at the application layer or pass additional requirements to post-handshake auth. Thanks! -Mike Bishop
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
