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 award to F5
>> 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 Monday, June 06, 2016 06:48:20 am Hubert Kario wrote:
> What makes you think that a new version negotiation that works more or
> less in the same way will _not_ be implemented incorrectly?
The list-based extension doesn't work in quite the same way. The current
mechanism compares two values a
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 generalized
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 ho
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 old)
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 ra
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
:* Dave Garrett
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] no fallbacks please [was: Downgrade protection,
> fallbacks, and server time]
>
>
>
> My opinion on this hasn't really changed since the last time. This seems
> like it's more complicated and it&#x
[mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Friday, June 3, 2016 6:40 AM
To: Dave Garrett
Cc: tls@ietf.org
Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks,
and server time]
My opinion on this hasn't really changed since the last time. This seems like
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:
> Allrighty then; time to dust off
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]>
> > O
> 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:
>
&
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 introduced
On Fri, Jun 03, 2016 at 08:37:34AM +0200, 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.
Well, AFAIK, in current editor's draft, key_share or pre_shared_key
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, bu
I strongly support this proposal.
Best,
Xiaoyin
From: Dave Garrett<mailto:davemgarr...@gmail.com>
Sent: Friday, June 3, 2016 12:17
To: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks,
and server time]
Allrighty then;
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/058ff1518508b094b8c9f1bd4096be9393f20076
(I cleaned up a bit when rebasing, but it probably needs some work; was just a
WIP branch, never a PR
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
> chance I can break all
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 10:31 AM, Nikos Mavrogiannopoulos
> >> > > w
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 Wed, 2016-06-01 at 15:43 -0700, Eric R
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 Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wro
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 pretty good, but I agree that we're g
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 not. Lets let thes
> 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 not. Lets let these fallbacks die. Not every client is a
> browser. TLS 1.3 must b
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 d
26 matches
Mail list logo
