Re: [TLS] The case for a single stream of data

On Sat, May 6, 2017 at 4:54 PM, Kyle Rose wrote: > On Sat, May 6, 2017 at 11:12 AM, Ilari Liusvaara > wrote: > >> On Sat, May 06, 2017 at 09:43:55AM -0400, Kyle Rose wrote: >> > I asked this question a while back, and didn't get a satisfying answer:

Re: [TLS] Security review of TLS1.3 0-RTT

On Sat, May 6, 2017 at 5:35 PM, Christian Huitema wrote: > > > On 5/4/2017 10:12 PM, Eric Rescorla wrote: > > > > Obligatory note that if clients are forbidden from reusing a single > > PSK for multiple 0-RTT, they can still use it for 1-RTT. > > Yes, they can. But doing so

Re: [TLS] Security review of TLS1.3 0-RTT

On 5/4/2017 10:12 PM, Eric Rescorla wrote: > > Obligatory note that if clients are forbidden from reusing a single > PSK for multiple 0-RTT, they can still use it for 1-RTT. Yes, they can. But doing so leaks a unique identifier, which can be used to link sessions. When I look at the privacy

Re: [TLS] The case for a single stream of data

On Sat, May 6, 2017 at 11:12 AM, Ilari Liusvaara wrote: > On Sat, May 06, 2017 at 09:43:55AM -0400, Kyle Rose wrote: > > I asked this question a while back, and didn't get a satisfying answer: > if > > an on-path attacker replaces the early data with a replay from an

Re: [TLS] The case for a single stream of data

On Sat, May 6, 2017 at 8:22 AM, Salz, Rich wrote: > > What about when **part** of a request is in the 0RTT part, and the rest > of it isn’t? I believe this will happen often for H2 initial setup. > Imagine the “fun” when initial connection data, such as login cookies, is >

Re: [TLS] The case for a single stream of data

What about when *part* of a request is in the 0RTT part, and the rest of it isn’t? I believe this will happen often for H2 initial setup. Imagine the “fun” when initial connection data, such as login cookies, is replayed in other contexts and eventually decrypted? -- Senior Architect, Akamai

Re: [TLS] The case for a single stream of data

On Fri, May 05, 2017 at 09:28:07AM -0700, Colm MacCárthaigh wrote: > I wanted to start a separate thread on this, just to make some small > aspects of replay mitigating clear, because I'd like to make a case for TLS > providing a single-stream, which is what people seem to be doing anyway.

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

Hi. Draft-17 submitted. Yoav > On 4 May 2017, at 23:09, Kathleen Moriarty > wrote: > > Yoav, > > On Thu, May 4, 2017 at 1:59 PM, Yoav Nir > wrote: >> >> On 4 May 2017, at 16:09, Kathleen Moriarty >>

[TLS] I-D Action: draft-ietf-tls-rfc4492bis-17.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

Thanks! That would have been an embarrassing erratum. > On 5 May 2017, at 14:31, Hubert Kario wrote: > > On Thursday, 4 May 2017 19:59:29 CEST Yoav Nir wrote: >>> 2) In Section 6: >>> Server implementations SHOULD support all of the following cipher >>> suites, and