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

2016-05-12 Thread Eric Rescorla
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] Updated TLS Cached Info Document

2016-05-12 Thread Sean Turner
On May 12, 2016, at 10:40, Stephen Farrell wrote: > > > Thanks Hannes. > > This document was already approved by the IESG and we were > just waiting on this particular change to be made. AFAIK, > this change, while affecting the bits on the wire, is ok > with those

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

2016-05-12 Thread Eric Rescorla
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

[TLS] QUIC BoF for Berlin

2016-05-12 Thread Ted Hardie
Howdy, I wanted to let folks know that we (the cc'ed folks) have proposed a BoF on QUIC for Berlin. The BoF proposal is here: https://tools.ietf.org/bof/trac/ . This effort, if

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

2016-05-12 Thread David Benjamin
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

2016-05-12 Thread Martin Thomson
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

2016-05-12 Thread Andrei Popov
Ø Is the client still authenticated as the previous one too, or just the new one? I think the client that has authenticated as A and then B in the same TLS session, can’t claim to not be A anymore. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Benjamin Sent: Thursday, May 12, 2016

Re: [TLS] removing 128-bit ciphers in TLS 1.3

2016-05-12 Thread Scott Fluhrer (sfluhrer)
> -Original Message- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Fedor Brunner > Sent: Thursday, May 12, 2016 4:10 AM > To: tls@ietf.org > Subject: [TLS] removing 128-bit ciphers in TLS 1.3 > > Because of this attacks: > > https://blog.cr.yp.to/20151120-batchattacks.html > >

Re: [TLS] QUIC BoF for Berlin

2016-05-12 Thread Sean Turner
On May 12, 2016, at 15:05, Ted Hardie wrote: > > The IETF mailing list for discussion of this proposal has been set up at > q...@ietf.org. To subscribe via the web: https://www.ietf.org/mailman/listinfo/quic spt ___ TLS mailing