Ø 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. I agree with this: client auth in 0-RTT is replayable, unless the server takes extraordinary steps (QUIC-like strike registers, database of client nonces, etc.) No plans to implement, at least for now.
Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Bill Cox Sent: Wednesday, January 27, 2016 6:13 AM To: Martin Thomson <martin.thom...@gmail.com> Cc: tls@ietf.org Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished On Tue, Jan 26, 2016 at 7:32 PM, Martin Thomson <martin.thom...@gmail.com<mailto: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. 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. Bill
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
