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

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

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

> 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

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

Re: [TLS] ECDH_anon

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

Re: [TLS] ECDH_anon

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

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

Ø 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

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

> 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

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

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

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

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

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

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 > >

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

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

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

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.

Re: [TLS] ECDH_anon

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