On Wed, Jan 27, 2016 at 6:12 AM, Bill Cox <waywardg...@google.com> wrote: > On Tue, Jan 26, 2016 at 7:32 PM, Martin Thomson <martin.thom...@gmail.com> > wrote: >> >> >> I get your point, but I don't see that as a simplification. In my >> mind, post-handshake client authentication doesn't happen. Or, I >> don't see it being commonplace. > > > The use case described to me was for a higher level of authentication, such > as when accessing a source-code repository at work, similar to proving that > you still possess a security key now and then. I am not sure why FIDO does > not fit this use case better, though. I have a feeling this is a legacy use > case of client certificates, and is being included to avoid having to > transition a lot of legacy client-cert based systems to FIDO.
All certificate based authentication over HTTP is currently done by renegotiation, when the client chooses to access a protected resource a Renegotiation Request is sent, leading to the client certificate being provided in the second handshake. It's true that FIDO will be a better solution (currently unfinished), but when changing TLS stacks to work with TLS 1.3 we need to support this case, without requiring changes to application code below this. > > The CertificateVerify message is still listed as an option in the 0-RTT > client's first flight at t = 0. Is this a mistake? I have not heard that > anyone wants to do this, as there is no possibility of a traditional > proof-of-possession in the first flight. However, with QUIC-like strike > registers, a reasonably accurate timestamp in the handshake, and a secure > clock on the client, you can approximate a proof-of-possession. This seems > like a lot of trouble for a first-flight CertificateVerify, but if someone > wants to do this, it could stay in the spec. If CertficateVerify is to > remain in the 0-RTT first flight, there needs to be some way to provide a > timestamp in the handshake hash. Is there a way to do this now? The TLS > 1.2 timestamp in the client random seems to have been removed. All 0-RTT data is replayable, but I don't see what replaying a authenticated replayable connection gets you. > > Bill > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
