Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-25 Thread Ryan Sleevi
On Tue, Apr 25, 2017 at 5:50 AM, Nikos Mavrogiannopoulos wrote: > > So you point is that as long as you don't use OCSP responses there is > no interoperability issue. That's very interesting point. More > interestingly you delegate that definition to an application profile. >

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-25 Thread Nikos Mavrogiannopoulos
On Mon, 2017-04-24 at 09:26 -0400, Ryan Sleevi wrote: > > > On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos .com> wrote: > > That's intentional.  > > And misguided. It violates the layering. That's a respectable opinion. I disagree. > > The reason they > > cannot be

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-24 Thread Eric Rescorla
I'm reading there as being no consensus to make this change, so I plan not to absent chair directive. -Ekr On Mon, Apr 24, 2017 at 6:26 AM, Ryan Sleevi wrote: > > > On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos > wrote: > >> >> That's

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-24 Thread Ryan Sleevi
On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos wrote: > > That's intentional. And misguided. It violates the layering. > Not every application is firefox or chrome and thus > application writers cannot be expected to set sane defaults for OCSP > validity time _when

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-24 Thread Salz, Rich
> The TLS 1.3 specification isn't the right place to specify what to do with > OCSP responses that do not have a nextUpdate field. When phrased like this, it seems completely obvious to me that this correct. ___ TLS mailing list TLS@ietf.org

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-24 Thread Brian Smith
Ryan Sleevi wrote: > On Sat, Apr 22, 2017 at 5:42 PM, Kurt Roeckx wrote: >> >> So for OCSP of a subordinate CAs there doesn't seem to be any >> requirement for a nextUpdate. >> > > Correct. This is part of the many asynchronicities related to CRLs and >

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-24 Thread Nikos Mavrogiannopoulos
On Sun, 2017-04-23 at 12:01 -0400, Ryan Sleevi wrote: > > > > As for what the TLS library I have written does if OCSP staple > > lacks > > NextUpdate, it outright causes handshake failure and fatal alert. > > So far, the preference on our end has been for a TLS library that > doesn't have to

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-23 Thread Geoffrey Keating
Ilari Liusvaara writes: > > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos > > wrote: > > > > > My issue with OCSP when used under TLS was how to determine the > > > validity of the response when the nextUpdate field is missing. I've > > >

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-23 Thread Kurt Roeckx
On Sun, Apr 23, 2017 at 12:01:08PM -0400, Ryan Sleevi wrote: > > And the 12 month update interval for intermediates is IMO just crazy, > > and won't work properly in TLS 1.3, now that multistaple is pretty much > > a baseline feature. > > > > I have no desire to support multistaple within Chrome.

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-23 Thread Ilari Liusvaara
On Sun, Apr 23, 2017 at 12:01:08PM -0400, Ryan Sleevi wrote: > On Sun, Apr 23, 2017 at 6:34 AM, Ilari Liusvaara > wrote: > > > And the 12 month update interval for intermediates is IMO just crazy, > > and won't work properly in TLS 1.3, now that multistaple is pretty

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-23 Thread Ryan Sleevi
On Sun, Apr 23, 2017 at 6:34 AM, Ilari Liusvaara wrote: > > I meant if anyone has seen a OCSP response from "public" CA lately that > lacks NextUpdate. > Why would it matter? Are you suggesting we determine what should be part of TLS based on what CAs are doing? That's

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-23 Thread Ilari Liusvaara
On Sat, Apr 22, 2017 at 11:42:06PM +0200, Kurt Roeckx wrote: > On Sat, Apr 22, 2017 at 03:00:17PM +0300, Ilari Liusvaara wrote: > > On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote: > > > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos > > > > > > wrote: >

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-22 Thread Ryan Sleevi
On Sat, Apr 22, 2017 at 5:42 PM, Kurt Roeckx wrote: > > So for OCSP of a subordinate CAs there doesn't seem to be any > requirement for a nextUpdate. > Correct. This is part of the many asynchronicities related to CRLs and OCSP in the BRs (another example:

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-22 Thread Kurt Roeckx
On Sat, Apr 22, 2017 at 03:00:17PM +0300, Ilari Liusvaara wrote: > On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote: > > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos > > wrote: > > > > > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > > > >

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-22 Thread Ilari Liusvaara
On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote: > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos > wrote: > > > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > > > > Do you have any thoughts on what text we should insert here? I admit > > >

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-22 Thread Nikos Mavrogiannopoulos
On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > 4.1.1. HelloRetryRequest how many times can it be re-sent by the > > server? I assume only a single one, but it maybe good to make it > > explicit. > > This is forbidden in S 4.1.4. >

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-11 Thread Eric Rescorla
On Tue, Apr 11, 2017 at 2:25 PM, Ilari Liusvaara wrote: > On Tue, Apr 11, 2017 at 01:47:08PM -0700, Eric Rescorla wrote: > > Thanks for your comments. > > > > > 4.1.2. It is not defined what a server should do if encountered with a > > > ProtocolVersion of TLS 1.3. > >

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-11 Thread Ilari Liusvaara
On Tue, Apr 11, 2017 at 01:47:08PM -0700, Eric Rescorla wrote: > Thanks for your comments. > > > 4.1.2. It is not defined what a server should do if encountered with a > > ProtocolVersion of TLS 1.3. > > https://tlswg.github.io/tls13-spec/#supported-versions says: > >If this extension is

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-04-11 Thread Eric Rescorla
Thanks for your comments. > 1.2. Major Differences from TLS 1.2 > It is very hard to make use of this section as is. It is organized on > per-draft, while it would be expected to have the changes of the > document since TLS 1.2. It contains phrases like "Remove spurious > requirement to

Re: [TLS] comments on draft-ietf-tls-tls13-19

2017-03-29 Thread Nikos Mavrogiannopoulos
On Wed, 2017-03-29 at 16:28 +0200, Nikos Mavrogiannopoulos wrote: > A more general note on the section/document, is that although the > PKIX > identity (certificate) is protected from passive adversaries, the PSK > identity is not. This is a discrepancy in terms of protecting the > user's

[TLS] comments on draft-ietf-tls-tls13-19

2017-03-29 Thread Nikos Mavrogiannopoulos
Hi, In this mail I summarize my comments for draft-ietf-tls-tls13-19 (which I have read but not implemented). They include both editorial comments and content comments. Overall this is a very good document, congratulations to everyone involved. On the following text, I use the format Section