On Mon, Aug 10, 2015 at 07:33:53PM +0000, David Benjamin wrote: > > Why not do this using HTTP's own auth framework? Have the client sign > something which includes a channel binding, placing it and the certificate > chain in an Authorization header. You could even transition to it in TLS > 1.2 deployments, provided EMS is negotiated. When TLS 1.3 and EMS are not > negotiated, fall back to the legacy thing.
Yeah, that would be much cleaner (and indeed was one[1] of the two ways I think HTTP/2 client auth can be done without gross hacks). Except that because for clean operation HTTP needs request-level authentication, one would have to transmit the authentication on each request (fortunately, on subsequent retransmits, it can be compressed very well[2]). [1] The other would be signaling via HTTP 401 and using that to trigger new connection with client-driven client auth. [2] Unless the payload needs internal nonces (and I don't think it does), one can assume the same certificate on the same connection always generates the same cert+signature block (if using deterministic signatures, that happens even if one tries to sign again). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
