On Tue, Jan 26, 2016 at 9:11 PM Martin Thomson <martin.thom...@gmail.com> wrote:
> On 27 January 2016 at 12:58, David Benjamin <david...@chromium.org> wrote: > > If the server needs to send a CertificateRequest (i.e. the client > > mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise has a > > 0-RTT hit, have it reject 0-RTT altogether. The 0-RTT is already all but > > useless because the first authenticated byte of the response is delayed > to > > t=1.5. We should just say that 0-RTT accept + CertificateRequest is > > forbidden. > > > I believe that is a choice that an implementation could make, rather > than have a stipulation in a spec. You are free to simplify in your > implementation as much as you like. > > Refusing 0-RTT and delaying the "completion" of a handshake if you > find that you need to send a CertificateRequest (either because you > don't have 0-RTT client auth or the 0-RTT client auth is > bad/indecipherable) is a pretty good choice. I might even be happy to > recommend it to others. But do you have a security property you are > looking to preserve? Because otherwise, I think that I might take the > optimization. > Why do you say it's an optimization? They're exactly the same except the simplified one reduces to normal 0-RTT + mid-stream CertificateRequest (a combination that's possible with or without my restriction) and the other is a brand new handshake flow to worry about. Original: t = 0 Client sends ClientHello to server with 0-RTT data. t = 0.5 Server acks 0-RTT in ServerHello, adds a CertificateRequest in the middle, sends Finished (and messages in between). t = 0.5 Server sends unauthenticated application data. t = 1 Client receives CertificateRequest, sends Certificate, CertificateVerify, Finished t = 1 Client receives unauthenticated application data t = 1.5 Server receives Certificate, etc., sends authenticated application data. t = 2 Client receives authenticated application data. Simplified: t = 0 Client sends ClientHello to server with 0-RTT data. t = 0.5 Server acks 0-RTT ServerHello, sends Finished (and messages in between) t = 0.5 Server sends mid-stream CertificateRequest t = 0.5 Server sends unauthenticated application data t = 1 Client sends Finished t = 1 Client receives mid-stream CertificateRequest, sends mid-stream Certificate, CertificateVerify t = 1 Client receives unauthenticated application data t = 1.5 Server receives mid-stream Certificate, etc., sends authenticated application data. t = 2 Client receives authenticated application data. I believe all that changes is CertificateRequest now comes after Finished on the server and Finished comes before Certificate on the client. But this way we cut down on the state space. Even if servers are sensible enough to act this way, clients must still accept it if it's in the protocol. That's more cases that everyone must write tests for (BoringSSL has a pretty extensive battery of tests and I intend to continue this practice) and think about in analyzing the protocol. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
