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

2017-05-09 Thread Salz, Rich
To me, the argument against this comes down to this: The 0RTT data has different security properties than the post-handshake data, and TLS implementations should not hide that difference from applications. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at

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

2017-05-09 Thread Viktor Dukhovni
> On May 9, 2017, at 12:00 PM, Salz, Rich wrote: > > To me, the argument against this comes down to this: The 0RTT data has > different security properties than the post-handshake data, and TLS > implementations should not hide that difference from applications. What would a receiver API then

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

2017-05-09 Thread Colm MacCárthaigh
On Tue, May 9, 2017 at 9:00 AM, Salz, Rich wrote: > To me, the argument against this comes down to this: The 0RTT data has > different security properties than the post-handshake data, and TLS > implementations should not hide that difference from applications. > I absolutely agree with sentime

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

2017-05-09 Thread Salz, Rich
> What would a receiver API then look like? Would it be something like: ... > Or did you have something else in mind? What are your thoughts on the > sender side? Just enable 0-RTT and have the toolkit send as much 0-RTT data > as "fits" and the rest 1-RTT, or an explicit request for a specific

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

2017-05-09 Thread Salz, Rich
> It's actually impossible because a 0RTT request may be retried as a 1RTT > request and there's no way to correlate the two. So when the 1RTT request > shows up, we can't go "This might be a repeat" - for example the X- header > trick doesn't work in this case. It's subtle, which makes it even

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

2017-05-09 Thread Andrei Popov
> To me, the argument against this comes down to this: The 0RTT data has > different security properties than the post-handshake data, and TLS > implementations should not hide that difference from applications. This is true, and early on there seemed to be general agreement that 0-RTT data wou

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

2017-05-09 Thread Roland Zink
Am 09.05.2017 um 18:41 schrieb Salz, Rich: The second problem is that middle-boxes can break any signaling. For example a CDN or TLS accelerator may enable 0-RTT towards the back-end origin without enabling it to the original client. In this model, the client has *no* way to reason about ret

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

2017-05-09 Thread Colm MacCárthaigh
On Tue, May 9, 2017 at 9:41 AM, Salz, Rich wrote: > > It's actually impossible because a 0RTT request may be retried as a 1RTT > request and there's no way to correlate the two. So when the 1RTT request > shows up, we can't go "This might be a repeat" - for example the X- header > trick doesn't w

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

2017-05-09 Thread Ilari Liusvaara
On Tue, May 09, 2017 at 10:35:37AM -0700, Colm MacCárthaigh wrote: > On Tue, May 9, 2017 at 9:41 AM, Salz, Rich wrote: > >The second problem is that middle-boxes can break any signaling. For > > example a CDN or TLS accelerator may enable 0-RTT towards the back-end > > origin without enabling it

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

2017-05-09 Thread Colm MacCárthaigh
On Tue, May 9, 2017 at 11:12 AM, Ilari Liusvaara wrote: > > Doesn't this imply that clients or CDN are using unsafe HTTP methods in > 0-RTT data? Which is of course _seriously_ broken. > It doesn't really. First; the CDN may be acting as a Layer 4 TLS proxy. Some CDNs sell these as SSL accelerato