Re: [TLS] 0-RTT, server Application Data, and client Finished

2016-01-27 Thread Andrei Popov
No plans to implement client auth in 0-th RTT. Cheers, Andrei From: Yoav Nir [mailto:ynir.i...@gmail.com] Sent: Wednesday, January 27, 2016 11:10 AM To: Andrei Popov Cc: Bill Cox ; Martin Thomson ; tls@ietf.org Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished On 27 Jan

Re: [TLS] 0-RTT, server Application Data, and client Finished

2016-01-27 Thread Ilari Liusvaara
On Wed, Jan 27, 2016 at 07:28:47PM +, David Benjamin wrote: > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson > wrote: > > > > I get your point, but I don't see that as a simplification. In my > > mind, post-handshake client authentication doesn't happen. Or, I > > don't see it being commonp

Re: [TLS] 0-RTT, server Application Data, and client Finished

2016-01-27 Thread David Benjamin
On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson wrote: > On 27 January 2016 at 14:11, David Benjamin wrote: > > 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 w

Re: [TLS] 0-RTT, server Application Data, and client Finished

2016-01-27 Thread Yoav Nir
> On 27 Jan 2016, at 8:38 PM, Andrei Popov wrote: > > Ø The CertificateVerify message is still listed as an option in the 0-RTT > client's first flight at t = 0. Is this a mistake? I have not heard that > anyone wants to do this, as there is no possibility of a traditional > proof-of-posse

Re: [TLS] 0-RTT, server Application Data, and client Finished

2016-01-27 Thread Andrei Popov
Ø The CertificateVerify message is still listed as an option in the 0-RTT client's first flight at t = 0. Is this a mistake? I have not heard that anyone wants to do this, as there is no possibility of a traditional proof-of-possession in the first flight. I agree with this: client auth in 0-

Re: [TLS] 0-RTT, server Application Data, and client Finished

2016-01-27 Thread Salz, Rich
> e.g., "please pay Watson $10, my certificate authenticates this request" We already know non-idempotent actions cannot be put into 0 RTT. s/cannot/should not/ This might help prevent problems. Might. I don't know if it's worth it. ___ TLS mailing

Re: [TLS] 0-RTT, server Application Data, and client Finished

2016-01-27 Thread Watson Ladd
On Jan 27, 2016 9:45 AM, "Martin Thomson" wrote: > > On 28 January 2016 at 02:09, Watson Ladd wrote: > > All 0-RTT data is replayable, but I don't see what replaying a > > authenticated replayable connection gets you. > > If the 0-RTT flight includes actions (especially non-idempotent ones) > tha

Re: [TLS] ECDH_anon

2016-01-27 Thread Blumenthal, Uri - 0553 - MITLL
On 1/27/16, 12:47 , "Martin Thomson" wrote: >On 28 January 2016 at 02:17, Blumenthal, Uri - 0553 - MITLL > wrote: >> Anon ‎!= Ephemeral, despite some similarities. > >From a protocol perspective, they are the same. If you mean that you cannot distinguish between the two on the wire - I agree.

Re: [TLS] ECDH_anon

2016-01-27 Thread Martin Thomson
On 28 January 2016 at 02:17, Blumenthal, Uri - 0553 - MITLL wrote: > Anon ‎!= Ephemeral, despite some similarities. >From a protocol perspective, they are the same. The distinction at the protocol level between ECDH_RSA (for example) and ECDH_anon is that ECDH_anon requires a ServerKeyShare mes

Re: [TLS] 0-RTT, server Application Data, and client Finished

2016-01-27 Thread Martin Thomson
On 28 January 2016 at 02:09, Watson Ladd wrote: > All 0-RTT data is replayable, but I don't see what replaying a > authenticated replayable connection gets you. If the 0-RTT flight includes actions (especially non-idempotent ones) that only apply if the authentication is correct, then you get aut

Re: [TLS] ECDH_anon

2016-01-27 Thread Blumenthal, Uri - 0553 - MITLL
IMHO it's not a good idea to re-purpose existing cipher-suites and alter their observed behavior. Likewise for the name overloading.  Anon  ‎!= Ephemeral, despite some similarities.  My apologies if I'm missing the point or the frame of a larger issue. Sent from my BlackBerry 10 smartphone on t

Re: [TLS] 0-RTT, server Application Data, and client Finished

2016-01-27 Thread Watson Ladd
On Wed, Jan 27, 2016 at 6:12 AM, Bill Cox wrote: > On Tue, Jan 26, 2016 at 7:32 PM, Martin Thomson > wrote: >> >> >> I get your point, but I don't see that as a simplification. In my >> mind, post-handshake client authentication doesn't happen. Or, I >> don't see it being commonplace. > > > The

[TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

2016-01-27 Thread Magnus Westerlund
AVTCORE and TLS, TLS WG, you are included in this WG last call, as this document affects the TLS ContentType IANA registry. This email starts a two week WG last call, that ends on the 10th of February. The intended status of this document is standards track (Proposed Standard). The documen

Re: [TLS] ECDH_anon

2016-01-27 Thread Nikos Mavrogiannopoulos
On Wed, 2016-01-27 at 14:51 +1100, Martin Thomson wrote: > 4472bis has a TBD regarding a missing "E" in the name of ECDHE_anon > cipher suites. > > I raised an issue: https://github.com/tlswg/rfc4492bis/issues/17 My understanding of DH_anon and ECDH_anon is that they were made to be used with sta