Re: [TLS] In-handshake CertificateRequest and 0-RTT

12:41 PM To: Eric Rescorla <e...@rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] In-handshake CertificateRequest and 0-RTT Right, I want to forbid it precisely because I don't want to allow post-handshake client auth. :-) Or rather, I expect most TLS applications will not want post-han

Re: [TLS] In-handshake CertificateRequest and 0-RTT

Right, I want to forbid it precisely because I don't want to allow post-handshake client auth. :-) Or rather, I expect most TLS applications will not want post-handshake client auth enabled as it significantly changes the authentication picture (TLS-level auth can change mid-stream) and would

Re: [TLS] In-handshake CertificateRequest and 0-RTT

I agree that the current draft is ambiguous on this point but I think the question is what the right thing is. My intuition here is that we should try to make the client's side and the server's side more independent so that you can have client auth in either case. Given that we're going to allow

Re: [TLS] In-handshake CertificateRequest and 0-RTT

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

Re: [TLS] In-handshake CertificateRequest and 0-RTT

On 12 May 2016 at 12:41, David Benjamin wrote: > 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?) Not planning to allow it :) >[re: post

Re: [TLS] In-handshake CertificateRequest and 0-RTT

On Wed, May 11, 2016 at 9:25 PM Martin Thomson 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. > >