Re: [TLS] Separate APIs for 0-RTT

On 06/14/2017 02:55 PM, David Benjamin wrote: > On Wed, Jun 14, 2017 at 2:17 AM Petr Špaček > wrote: > > > > On 13.6.2017 22:55, Ilari Liusvaara wrote: > > On Tue, Jun 13, 2017 at 06:57:05PM +, Andrei Popov wrote: > >> Regarding RFC

Re: [TLS] Separate APIs for 0-RTT

On Wed, Jun 14, 2017 at 7:31 PM David Benjamin wrote: > On Wed, Jun 14, 2017 at 6:47 PM Colm MacCárthaigh > wrote: > >> On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin >> wrote: >> >>> That is, it is not the identity of the bytes

Re: [TLS] Separate APIs for 0-RTT

On Wed, Jun 14, 2017 at 6:47 PM Colm MacCárthaigh wrote: > On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin > wrote: > >> That is, it is not the identity of the bytes that matters much. It's >> whether the connection has been confirmed when you perform

Re: [TLS] Separate APIs for 0-RTT

On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin wrote: > That is, it is not the identity of the bytes that matters much. It's > whether the connection has been confirmed when you perform an unsafe > action. I believe this still satisfies the properties we want, but without

Re: [TLS] Separate APIs for 0-RTT

On Wed, Jun 14, 2017 at 5:01 PM Andrei Popov wrote: > >- What if the server receives data with the 0-RTT boundary spanning an >HTTP/2 frame? Is that a 0-RTT request? 1-RTT? Invalid? > > It appears safe to treat such data as 0-RTT; only the application can make

Re: [TLS] Separate APIs for 0-RTT

Steven Valdez writes: > Confirming that BoringSSL is using a single API for early/regular data, > since we ran into issues/complications with our implementation of dual APIs > with our use cases. I predict that those are exactly the places you're going to have later security

Re: [TLS] Separate APIs for 0-RTT

* What if the server receives data with the 0-RTT boundary spanning an HTTP/2 frame? Is that a 0-RTT request? 1-RTT? Invalid? It appears safe to treat such data as 0-RTT; only the application can make this call, and it needs info from the TLS stack to make this call. * We could say

Re: [TLS] Separate APIs for 0-RTT

On Wed, Jun 14, 2017 at 2:17 AM Petr Špaček wrote: > > > On 13.6.2017 22:55, Ilari Liusvaara wrote: > > On Tue, Jun 13, 2017 at 06:57:05PM +, Andrei Popov wrote: > >> Regarding RFC language, I think we could be more specific: > >> > >> > >> > >> 1. A TLS implementation

Re: [TLS] TLS 1.3 (-18) at Apple

> On Jun 14, 2017, at 8:02 PM, Benjamin Kaduk wrote: > >> On 06/14/2017 01:00 PM, Chris Wood wrote: >> Hi folks, >> >> Last week at WWDC 2017, we (Apple) announced support for TLS 1.3 (-18) in >> our platforms. It is not turned on by default. If you’re a member of the >>

Re: [TLS] TLS 1.3 (-18) at Apple

On 06/14/2017 01:00 PM, Chris Wood wrote: > Hi folks, > > Last week at WWDC 2017, we (Apple) announced support for TLS 1.3 (-18) in our > platforms. It is not turned on by default. If you’re a member of the > developer seed, you may enable it on iOS by downloading and installing the > following

[TLS] TLS 1.3 (-18) at Apple

Hi folks, Last week at WWDC 2017, we (Apple) announced support for TLS 1.3 (-18) in our platforms. It is not turned on by default. If you’re a member of the developer seed, you may enable it on iOS by downloading and installing the following profile:

Re: [TLS] Closing on 0-RTT

On Tue, Jun 13, 2017 at 03:24:24PM -0700, Bill Cox wrote: > On Tue, Jun 13, 2017 at 1:51 PM, Ilari Liusvaara > wrote: > > > > - Note that 0-RTT exporters are not safe for authentication on servers > > > that do not enforce single-use tickets, or for clients that do

Re: [TLS] Separate APIs for 0-RTT

On 13.6.2017 22:55, Ilari Liusvaara wrote: > On Tue, Jun 13, 2017 at 06:57:05PM +, Andrei Popov wrote: >> Regarding RFC language, I think we could be more specific: >> >> >> >> 1. A TLS implementation SHOULD/MUST only send 0-RTT application data if the >> application has explicitly opted