Interesting suggestion. I see what you mean about symmetry with the server The symmetry I was optimizing for is that the PSK and non-PSK handshake, and I think from that perspective the current design is simpler, so I see it both ways.
WRT to the 0.5RTT data, Hugo Krawczyk has done some nice work on analyzing this case and I think we're starting to get more comfort with that. So, not sure what I think... -Ekr On Wed, May 11, 2016 at 10:44 PM, David Benjamin <david...@chromium.org> wrote: > The 0-RTT handshake originally had two places with a client Certificate + > CertificateVerify: in the 0-RTT flow and in the second Finished block in > response to a server CertificateRequest. We've dropped the first now. I > propose we drop the second too. Client auth with 0-RTT is solely carried > over via resumption. (I mentioned this previously, but with 0-RTT looking > closer to resumption and the IETF 95 decision on 0.5-RTT data, I think the > case is clearer.) > > This makes 6.2.3 more consistent with 6.2.2 where neither side > authenticates in a resumption handshake. 0-RTT is much more similar to > resumption with most parameters carrying over anyway. > > 1-RTT client auth in a 0-RTT handshake also invites more of the > retroactive auth confusion as with post-handshake auth. The client stream > switches from unauthenticated to authenticated. I believe this was one of > the reasons we agreed at IETF 95 to discourage/forbid (not sure which) > sending 0.5-RTT data following a CertificateRequest. In-handshake > CertificateRequest either requires this discouraged situation or accepting > 0-RTT data without sending 0.5-RTT data, which is largely pointless. > > We accepted the retroactive auth issue in post-handshake auth, but I think > we should limit it to that. For implementations, BoringSSL made accepting > renego an opt-in feature. I expect we'd do the same for post-handshake > auth. For specs, one might specify that post-handshake authentication is > forbidden. HTTP/2 did this for renegotiation. I haven't been following > the HTTP/2 client cert saga as closely, but > draft-thomson-http2-client-certs-02 is the current plan, right? If so, > HTTP/2 should forbid TLS-level post-handshake auth too. > > In both cases, excluding post-handshake auth should exclude any transition > from unauthenticated to authenticated in the stream. Instead, if you want > to change authentication state, send a post-handshake CertificateRequest, > as you would have normally. > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
