Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-10 Thread Tony Arcieri
On Friday, June 10, 2016, Nikos Mavrogiannopoulos wrote: > I'm actually surprised you mention the microsoft servers as being > version negotiation tolerant. They were the most prominent examples > of terminating the handshake if TLS 1.2 was offered to them > Personally I'd give

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-06 Thread Jeffrey Walton
>> That being said, I would prefer the solution to be a compliance test suite >> that checks if servers do handle correctly future versions, future >> extensions and future ciphersuites correctly. > > I agree with Hubert. The big question is how you get the bug report to the > server operator. > >

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-06 Thread Hubert Kario
On Friday 03 June 2016 16:16:13 Dave Garrett wrote: > The idea of using an empty extension as an indicator really isn't > fundamentally different from what I'm suggesting here. We'd just have > an arbitrary set of new version indicators mixed in with extensions > instead of inside a new

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-04 Thread Bill Frantz
On 6/3/16 at 2:28 AM, hka...@redhat.com (Hubert Kario) wrote: That being said, I would prefer the solution to be a compliance test suite that checks if servers do handle correctly future versions, future extensions and future ciphersuites correctly. I agree with Hubert. The big question is

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-03 Thread Dave Garrett
The idea of using an empty extension as an indicator really isn't fundamentally different from what I'm suggesting here. We'd just have an arbitrary set of new version indicators mixed in with extensions instead of inside a new generalized basket. My replacement was (again, it's over a year

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-03 Thread David Benjamin
I think I could be convinced in either direction right now. It is definitely ugly and more of a nuisance to implement. The alternative is a fallback and then painfully driving it out later. We've done that before and we have FALLBACK_SCSV and the server_random trick now. At the same time, I am

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-03 Thread Viktor Dukhovni
On Fri, Jun 03, 2016 at 06:39:58AM -0700, Eric Rescorla wrote: > My opinion on this hasn't really changed since the last time. This seems > like it's more complicated and it's not clear to me why it won't lead to > exactly the same version intolerance problem in future. Doing version negotiation

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-03 Thread Eric Rescorla
That's a clearer version of what I was trying to say. -Ekr On Fri, Jun 3, 2016 at 10:28 AM, Andrei Popov wrote: > It’s not that the existing version negotiation mechanism doesn’t work; the > problem is that implementers got it wrong. Similarly, implementers can

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-03 Thread Andrei Popov
It’s not that the existing version negotiation mechanism doesn’t work; the problem is that implementers got it wrong. Similarly, implementers can mess up the new negotiation mechanism. Especially since we have to support it at the same time as the old one. Cheers, Andrei From: TLS

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-03 Thread Eric Rescorla
My opinion on this hasn't really changed since the last time. This seems like it's more complicated and it's not clear to me why it won't lead to exactly the same version intolerance problem in future. -Ekr On Thu, Jun 2, 2016 at 9:17 PM, Dave Garrett wrote: >

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-03 Thread Hubert Kario
On Friday 03 June 2016 07:39:06 Xiaoyin Liu wrote: > > Date: Fri, 3 Jun 2016 11:33:54 +0300 > > From: ilariliusva...@welho.com > > To: tls@ietf.org > > Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, > > fallbacks, and server time]> > > On Fri, Jun 03, 2016 at 08:37:34AM +0200,

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-03 Thread Xiaoyin Liu
> Date: Fri, 3 Jun 2016 11:33:54 +0300 > From: ilariliusva...@welho.com > To: tls@ietf.org > Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, > and server time] > > On Fri, Jun 03, 2016 at 08:37:34AM +0200, Nikos Mavrogiannopoulos wrote: > > > A simpler proposal is:

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-03 Thread Hubert Kario
On Friday 03 June 2016 08:37:34 Nikos Mavrogiannopoulos wrote: > A simpler proposal is: > Consider TLS 1.3 as a feature, and negotiate it using an empty > extension. If the extension is present a server assumes TLS 1.3. If anything, it should be this. Extension with version negotiation

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-03 Thread Nikos Mavrogiannopoulos
On Fri, 2016-06-03 at 00:17 -0400, Dave Garrett wrote: > Allrighty then; time to dust off and rebase an old changeset I was > fiddling with last year on this topic: > https://github.com/davegarrett/tls13-spec/commit/058ff1518508b094b8c9 > f1bd4096be9393f20076 > (I cleaned up a bit when rebasing,

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-02 Thread Martin Thomson
On 3 June 2016 at 01:07, David Benjamin wrote: > But reality is what it is. The Law of the Internet is the last thing that > changed is blamed. We have a limited "budget" we can spend breaking things > (otherwise I'd have removed almost everything by now!) and there is no >

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-02 Thread Hubert Kario
On Thursday 02 June 2016 15:22:03 David Benjamin wrote: > On Thu, Jun 2, 2016 at 11:07 AM David Benjamin > wrote: > > On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario wrote: > >> On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: > >> > > On 2 Jun 2016, at

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-02 Thread Hubert Kario
On Thursday 02 June 2016 15:07:53 David Benjamin wrote: > On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario wrote: > > On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: > > > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos > > > > wrote:> > > > > > > > > On

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-02 Thread David Benjamin
On Thu, Jun 2, 2016 at 11:07 AM David Benjamin wrote: > On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario wrote: > >> On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: >> > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos >> > > wrote:>

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-02 Thread David Benjamin
On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario wrote: > On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: > > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos > > > wrote:> > > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: > > >> 2% is actually

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-02 Thread Hubert Kario
On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos > > wrote:> > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: > >> 2% is actually pretty good, but I agree that we're going to need > >> fallback. > > > > Please

[TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

2016-06-02 Thread Nikos Mavrogiannopoulos
On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: > 2% is actually pretty good, but I agree that we're going to need > fallback. Please not. Lets let these fallbacks die. Not every client is a browser. TLS 1.3 must be a protocol which doesn't require hacks to operate. CBC was removed, lets