On Wed, May 11, 2016 at 9:25 PM Martin Thomson <[email protected]> wrote:
> I think that this is a fine way to simplify, but I have a wrinkle to add. > > I would rather this be formulated as: a client cannot authenticate > using Certificate[+Verify] unless the server does so first. > > The reason that I want that is this issue > https://github.com/tlswg/tls13-spec/issues/443 I want to be able to > do 0-RTT but have the server continue to prove that it has the private > key (maybe some clients will do that occasionally). For those, I > think that reciprocating is reasonable. It doesn't significantly > change the state machine in that case. > > I hope to write a draft explaining this soon, so that folks can see > what it costs/looks like. > Sure, if we end up doing something on the server, mirroring sounds reasonable enough. (This would just be for re-asserting the private key and not switching certificates, right?) > On 12 May 2016 at 06:44, David Benjamin <[email protected]> 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.) > > > 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. > > I totally agree about the post-handshake stuff. I'm somewhat inclined > to ask that it be made an extension so that you can cleanly opt out. > For HTTP, doing it in an extension the obvious way doesn't quite work. Whether Chrome is willing to do renego depends on how ALPN resolves (we leave it at its default off state and, after the initial handshake but before we could consume a HelloRequest, toggle it off). Supposing post-handshake auth is still used for HTTP/1.1 + TLS 1.3 (am I right that this is the plan?), we'd be in a similar situation. The ClientHello would say post-handshake auth is allowed, but we may end up in a state where it isn't anyway. (I think implicitness is fine, though an extension seem fine too. The application already gets to impose other restrictions on the use of TLS like "the first application data record should begin with G, E, T, space".) > > 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. > > We're doubling down on that idea and considering allowing the server > to authenticate too. See > https://mikebishop.github.io/http2-client-certs/ (you might recognize > some similarity to the SPDY CREDENTIAL frame if you squint hard > enough). >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
