> On 12 Nov 2015, at 3:32 AM, Adam Langley <a...@imperialviolet.org> wrote: > > The TLS 1.3 post-handshake client-auth was intended, as I recall, to > support HTTP/1.1 over TLS 1.3.
No, it was (and is) presented as a way to do client certificate authentication with HTTP/2 not at the initial handshake. > With HTTP/2 isn't it cleaner to do client-auth at the HTTP layer (i.e. > by signing exporter values)? It is. I thought that an HTTP authentication method based on certificates could be a drop-in replacement for TLS layer authentication, but someone (I think it was Mike) pointed out that with TLS-layer certificate authentication the stream continues after the authentication, while with HTTP-layer authentication, the stream ends with a 401 status code, and the client has to start a new stream with the Authorization header. So applications would need to be changed for this to work. > 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. I agree that is a good idea. We have to be mindful of how this interacts with multiple concurrent streams requiring authentication, and whether we can avoid race conditions where the server sends a different response for the same resource depending on authentication without actually requiring it (“Hello, guest” vs “Hello, Adam”) Yoav _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
