Re: [TLS] Separate APIs for 0-RTT

2017-06-13 Thread Petr Špaček
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

2017-06-13 Thread Ilari Liusvaara
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] Closing on 0-RTT

2017-06-13 Thread Ilari Liusvaara
On Tue, Jun 13, 2017 at 12:06:26PM -0700, Bill Cox wrote: > On Tue, Jun 13, 2017 at 4:32 AM, Ilari Liusvaara > wrote: > > > Also: > > > > - Note that 0-RTT exporters are not safe for authentication unless > > the server does global anti-replay on 0-RTT. > > > I do not think this is the case.

Re: [TLS] Closing on 0-RTT

2017-06-13 Thread Bill Cox
On Tue, Jun 13, 2017 at 4:32 AM, Ilari Liusvaara wrote: > Also: > > - Note that 0-RTT exporters are not safe for authentication unless > the server does global anti-replay on 0-RTT. I do not think this is the case. Nick Harper has proposed an RFC for token binding over 0-RTT: https://to

Re: [TLS] Separate APIs for 0-RTT

2017-06-13 Thread Benjamin Kaduk
+1 (with my vote for MUST). -Ben On 06/13/2017 01:57 PM, 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 SHOU

Re: [TLS] Separate APIs for 0-RTT

2017-06-13 Thread Andrei Popov
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 accept 0-RTT application data if the application has explicitly opted in; 3. Wh

Re: [TLS] Separate APIs for 0-RTT

2017-06-13 Thread Benjamin Kaduk
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

2017-06-13 Thread Ilari Liusvaara
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] Exported Authenticators proposed updates

2017-06-13 Thread Nick Sullivan
Thanks for the comments. I've updated the PRs appropriately. On Tue, Jun 13, 2017 at 12:56 AM Ilari Liusvaara wrote: > On Tue, Jun 13, 2017 at 12:32:12AM +, Nick Sullivan wrote: > > All, > > > > I've collected a few changes that help clarify some ambiguities brought > up > > on the list and

Re: [TLS] Separate APIs for 0-RTT

2017-06-13 Thread Colm MacCárthaigh
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

2017-06-13 Thread Benjamin Kaduk
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

2017-06-13 Thread Colm MacCárthaigh
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

2017-06-13 Thread Ilari Liusvaara
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

2017-06-13 Thread Benjamin Kaduk
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. -Ben On 06/13/2017 11:29 AM, Eric Rescorla wrote: > This would be fine with me. > > -Ekr > > > On Tue, Jun 13, 2017 at 5

Re: [TLS] Separate APIs for 0-RTT

2017-06-13 Thread Andrei Popov
* 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 work for me. There are two reasons I suggested SHOULD: 1. A MUST w

Re: [TLS] Separate APIs for 0-RTT

2017-06-13 Thread Benjamin Beurdouche
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

2017-06-13 Thread Loganaden Velvindron
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

2017-06-13 Thread Eric Rescorla
This would be fine with me. -Ekr On Tue, Jun 13, 2017 at 5:12 PM, Andrei Popov wrote: > Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL did. > > > > WRT RFC language, perhaps a reasonable compromise would be to say that a > TLS implementation SHOULD only enable 0-RTT applica

Re: [TLS] Separate APIs for 0-RTT

2017-06-13 Thread Andrei Popov
Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL did. WRT RFC language, perhaps a reasonable compromise would be to say that a TLS implementation SHOULD only enable 0-RTT application data upon explicit opt-in by the application? This is more flexible and may involve separate A

Re: [TLS] Separate APIs for 0-RTT

2017-06-13 Thread Eric Rescorla
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

2017-06-13 Thread Salz, Rich
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] Closing on 0-RTT

2017-06-13 Thread Ilari Liusvaara
On Sun, Jun 11, 2017 at 04:18:03PM +0100, Eric Rescorla wrote: > Hi folks, > > We've had a phenomenal amount of discussion around 0-RTT anti-replay, > and based on my recent summary e-mails I think we generally agree > about the technical facts, so it's time to finalize the PR and land it > in the

Re: [TLS] Separate APIs for 0-RTT

2017-06-13 Thread Eric Rescorla
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

2017-06-13 Thread Ilari Liusvaara
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 >

[TLS] Separate APIs for 0-RTT

2017-06-13 Thread Eric Rescorla
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 writing 0-RTT data and data transmitted after the handshake, and SHOULD

Re: [TLS] Exported Authenticators proposed updates

2017-06-13 Thread Ilari Liusvaara
On Tue, Jun 13, 2017 at 12:32:12AM +, Nick Sullivan wrote: > All, > > I've collected a few changes that help clarify some ambiguities brought up > on the list and during implementation of the draft. These changes are laid > out as the following PRs in Github: > > Restrict the Certificate type