Re: [TLS] Separate APIs for 0-RTT

e is finished. > > Cheers, > > Tim > -- > Tim Jackson > > Senior Product Security Architect, MobileIron Inc. > > > From: "Martin Thomson" <mailto:martin.thom...@gmail.com>> > Date: Thursday, June 15, 2017 at 5:16:29 PM > To: "Da

Re: [TLS] Separate APIs for 0-RTT

On 06/22/2017 09:10 PM, Timothy Jackson wrote: > +1 and a preference for MUST, just so people understand the importance. > > Since we're agreed that 0-RTT data and 1-RTT data have (almost) the > same security properties once the handshake completes, it seems to me, > unless I've missed something, t

Re: [TLS] Separate APIs for 0-RTT

roduct Security Architect, MobileIron Inc. From: "Martin Thomson" mailto:martin.thom...@gmail.com>> Date: Thursday, June 15, 2017 at 5:16:29 PM To: "David Benjamin" mailto:david...@chromium.org>> Cc: "tls@ietf.org" mailto:tls@iet

Re: [TLS] Separate APIs for 0-RTT

On 15 June 2017 at 08:23, David Benjamin wrote: > When accepting 0-RTT as a server, a TLS implementation SHOULD/MUST provide a > way for the application to determine if the client Finished has been > processed. I'm going to throw my support behind this distinction. Though I would phrase this mo

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 language, I think we c

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 that matters much. It's >>> whether the connection has been confi

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 an unsafe >> action. I believe this still sa

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 > breaking standard int

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 > this call, and it needs in

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 incidents. In parti

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 that

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 SHOULD/MUST only send 0

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

Re: [TLS] Separate APIs for 0-RTT

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 in; > > 2. A TLS implementation SHOULD/MUST only acc

Re: [TLS] Separate APIs for 0-RTT

11:48 AM > *To:* Ilari Liusvaara ; Colm MacCárthaigh > > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Separate APIs for 0-RTT > > > > On 06/13/2017 01:35 PM, Ilari Liusvaara wrote: > > On Tue, Jun 13, 2017 at 11:07:35AM -0700, Colm MacCárthaigh wrote: > >

Re: [TLS] Separate APIs for 0-RTT

...@ietf.org] On Behalf Of Benjamin Kaduk Sent: Tuesday, June 13, 2017 11:48 AM To: Ilari Liusvaara ; Colm MacCárthaigh Cc: tls@ietf.org Subject: Re: [TLS] Separate APIs for 0-RTT On 06/13/2017 01:35 PM, Ilari Liusvaara wrote: On Tue, Jun 13, 2017 at 11:07:35AM -0700, Colm MacCárthaigh wrote: On

Re: [TLS] Separate APIs for 0-RTT

On 06/13/2017 01:35 PM, Ilari Liusvaara wrote: > On Tue, Jun 13, 2017 at 11:07:35AM -0700, Colm MacCárthaigh wrote: >> On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk wrote: >> >>> I have been operating under the impression that at least some application >>> profiles for early data will require t

Re: [TLS] Separate APIs for 0-RTT

On Tue, Jun 13, 2017 at 11:07:35AM -0700, Colm MacCárthaigh wrote: > On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk wrote: > > > I have been operating under the impression that at least some application > > profiles for early data will require that certain application protocol > > requests (e.g

Re: [TLS] Separate APIs for 0-RTT

On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk wrote: > I have been operating under the impression that at least some application > profiles for early data will require that certain application protocol > requests (e.g., something like HTTP POST) must be rejected at the > application layer as "

Re: [TLS] Separate APIs for 0-RTT

On 06/13/2017 12:46 PM, Colm MacCárthaigh wrote: > > > On Tue, Jun 13, 2017 at 10:36 AM, Benjamin Kaduk > wrote: > > That's fine with me as well, though I am now considering the > question of having an API for the server application to know > whether a given r

Re: [TLS] Separate APIs for 0-RTT

On Tue, Jun 13, 2017 at 10:36 AM, Benjamin Kaduk wrote: > That's fine with me as well, though I am now considering the question of > having an API for the server application to know whether a given request > was received over 0- or 1-RTT. > For s2n, I'm leaning towards recommending the opposite

Re: [TLS] Separate APIs for 0-RTT

On Tue, Jun 13, 2017 at 05:10:39PM +, Andrei Popov wrote: > * My fear is that, even with RFC 2119 terminology, 0RTT will likely be > the cause of many problems in the future > * and that being extra careful here is important… :) > > I agree with this assessment. A MUST would certainly

Re: [TLS] Separate APIs for 0-RTT

AM > *To:* Salz, Rich mailto:rs...@akamai.com>> > *Cc:* tls@ietf.org <mailto:tls@ietf.org> > *Subject:* Re: [TLS] Separate APIs for 0-RTT > > > > On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich <mailto:rs...@akamai.com>> wrote: > >

Re: [TLS] Separate APIs for 0-RTT

, June 13, 2017 9:50 AM To: Eric Rescorla Cc: Rich Salz ; ML IETF TLS ; Andrei Popov Subject: Re: [TLS] Separate APIs for 0-RTT Please forgive me for this naive question, but is there a specific incentive for using “SHOULD” instead of “MUST" only enable 0-RTT application data upon explicit o

Re: [TLS] Separate APIs for 0-RTT

Please forgive me for this naive question, but is there a specific incentive for using “SHOULD” instead of “MUST" only enable 0-RTT application data upon explicit opt-in by the application... My fear is that, even with RFC 2119 terminology, 0RTT will likely be the cause of many problems in the f

Re: [TLS] Separate APIs for 0-RTT

On Tue, Jun 13, 2017 at 2:54 PM, Ilari Liusvaara wrote: > On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote: >> The current text says: >> >>0-RTT data has very different security properties from data >>transmitted after a completed handshake: it can be replayed. >>Implement

Re: [TLS] Separate APIs for 0-RTT

> > > > Andrei > > > > *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Tuesday, June 13, 2017 5:27 AM > *To:* Salz, Rich > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Separate APIs for 0-RTT > > > > On Tue, Jun 13

Re: [TLS] Separate APIs for 0-RTT

APIs for 0-RTT On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich mailto:rs...@akamai.com>> wrote: Microsoft also has a separate API for 0RTT data. I would characterize things as the two most popular browsers have stated their intention to have a single API, and the two most popular system lib

Re: [TLS] Separate APIs for 0-RTT

On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich wrote: > Microsoft also has a separate API for 0RTT data. I would characterize > things as the two most popular browsers have stated their intention to have > a single API, and the two most popular system libraries have two. Outlier > is clearly wrong

Re: [TLS] Separate APIs for 0-RTT

Microsoft also has a separate API for 0RTT data. I would characterize things as the two most popular browsers have stated their intention to have a single API, and the two most popular system libraries have two. Outlier is clearly wrong. I agree we don’t have consensus, but do make sure that

Re: [TLS] Separate APIs for 0-RTT

On Tue, Jun 13, 2017 at 11:54 AM, Ilari Liusvaara wrote: > On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote: > > The current text says: > > > >0-RTT data has very different security properties from data > >transmitted after a completed handshake: it can be replayed. > >Im

Re: [TLS] Separate APIs for 0-RTT

On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote: > The current text says: > >0-RTT data has very different security properties from data >transmitted after a completed handshake: it can be replayed. >Implementations SHOULD provide different functions for reading and >