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
>> 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.
>
>
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
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
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
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
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
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
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
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:
>
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,
> 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:
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
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,
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
>
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
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
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:>
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
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
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
21 matches
Mail list logo