It looks like we have enough consensus to move to an extension based
version negotiation mechanism so we're asking the author to merge in this
pull request. We can have further refinement of the details, but its
important for us to get a complete view of the spec at this point.
Cheers,
J
On
Another concern here is that in order to reduce memory footprint, some
implementations will probably introduce bugs by trying to optimize and infer
the version by observing the cipher-suits in client hello instead waiting for
the extension.
Cheers,
Vlad
> On 19 Sep 2016, at 03:42, Hubert
do it properly.
David
Cheers,
Andrei
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Vlad Krasnov
Sent: Friday, September 16, 2016 1:21 PM
To: Hubert Kario <hka...@redhat.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Version negotiation, take two
I am oppo
inal Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Vlad Krasnov
Sent: Friday, September 16, 2016 1:21 PM
To: Hubert Kario <hka...@redhat.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Version negotiation, take two
I am opposed to this change.
I don’t think that version selecti
Ø Is it just that doing an additional "negotiation" within the extension body
constitutes another extension point that we would have to actively defend…
Yes, the proposed negotiation mechanism is based on the premise that one shall
“have one joint and keep it well
> > The server
> > will make a choice based on the server's preferences. In a way, the
> > proposed version negotiation mechanism makes it slightly easier to
> > implement servers that support country X-TLS alongside IETF TLS versions.
>
> and a list with opaque version identifiers (just int16
On Thursday, 15 September 2016 11:51:31 CEST Benjamin Kaduk wrote:
> On 09/14/2016 02:02 PM, Andrei Popov wrote:
> > Basically, I don't feel strongly about the switch to the proposed version
> > negotiation mechanism. But if we are going to make this change based on
> > the theory of having only
On 09/14/2016 02:02 PM, Andrei Popov wrote:
> Basically, I don't feel strongly about the switch to the proposed version
> negotiation mechanism. But if we are going to make this change based on the
> theory of having only one extension point and actively defending it, then we
> should probably
On Thursday, 15 September 2016 12:22:03 CEST Hubert Kario wrote:
> On Wednesday, 14 September 2016 19:02:14 CEST Andrei Popov wrote:
> > > I don't think we should depart from the "highest mutually supported
> > > version" negotiation algorithm...
> >
> > Correct, but it's not clear what
ednesday, September 14, 2016 11:03 AM
> To: Andrei Popov <andrei.po...@microsoft.com>
> Cc: David Benjamin <david...@chromium.org>; tls@ietf.org
> Subject: Re: [TLS] Version negotiation, take two
>
> On Wednesday, 14 September 2016 17:39:59 CEST Andrei Popov wrote:
>
&
-
From: Salz, Rich [mailto:rs...@akamai.com]
Sent: Wednesday, September 14, 2016 12:09 PM
To: Andrei Popov <andrei.po...@microsoft.com>; Hubert Kario <hka...@redhat.com>
Cc: tls@ietf.org
Subject: RE: [TLS] Version negotiation, take two
Are there national TLS standards, or just nat
Are there national TLS standards, or just national crypto-suites?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
ons.
Cheers,
Andrei
-Original Message-
From: Hubert Kario [mailto:hka...@redhat.com]
Sent: Wednesday, September 14, 2016 11:03 AM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: David Benjamin <david...@chromium.org>; tls@ietf.org
Subject: Re: [TLS] Version negotiation, take tw
16 9:40 AM
> To: David Benjamin <david...@chromium.org>
> Cc: tls@ietf.org
> Subject: Re: [TLS] Version negotiation, take two
>
> On Wednesday, 14 September 2016 16:17:50 CEST David Benjamin wrote:
>
> > Yes, we find list intolerance too---servers which only look at
...@ietf.org] On Behalf Of Hubert Kario
Sent: Wednesday, September 14, 2016 9:40 AM
To: David Benjamin <david...@chromium.org>
Cc: tls@ietf.org
Subject: Re: [TLS] Version negotiation, take two
On Wednesday, 14 September 2016 16:17:50 CEST David Benjamin wrote:
> Yes, we find list intolerance too-
On Wednesday, 14 September 2016 16:17:50 CEST David Benjamin wrote:
> Yes, we find list intolerance too---servers which only look at the second
> byte in a cipher suite, servers which forgot a default in their NamedGroup
> switch-case, servers which get confused on unknown HashAlgorithms, servers
On Wed, Sep 14, 2016 at 11:46 AM Benjamin Kaduk wrote:
> On 09/14/2016 04:56 AM, Hubert Kario wrote:
>
> First, I don't think that the argument that the current version scheme doesn't
> lend itself to future-proofing is correct. Just as with GREASE, browsers can
> send much
On 09/14/2016 04:56 AM, Hubert Kario wrote:
> First, I don't think that the argument that the current version scheme
> doesn't
> lend itself to future-proofing is correct. Just as with GREASE, browsers can
> send much higher version than they really support if they do that on a time
> limited
First, I don't think that the argument that the current version scheme doesn't
lend itself to future-proofing is correct. Just as with GREASE, browsers can
send much higher version than they really support if they do that on a time
limited basis.
Second, while the "joint" which handles new
All,
There appears to be an emerging consensus here to adopt the change proposed by
this PR. Please indicate whether you are unwilling (and why) to accept this
change by September 16th.
J
> On Sep 08, 2016, at 12:04, David Benjamin wrote:
>
> Hi folks,
>
> I’d like
On Thu, Sep 8, 2016 at 12:04 PM, David Benjamin
wrote:
> The major arguments against this change seem to be:
>
> 1. It’s inelegant to have two mechanisms.
> 2. We should fix broken servers
>
There's also:
3. Implementors will find a way to screw this up, too.
But if you
This is the best proposal I've seen given the deployment constraints
imposed by reality. Perhaps it could be tweaked to improve it slightly,
but I support merging this version.
-Ben
On 09/08/2016 11:04 AM, David Benjamin wrote:
> Hi folks,
>
> I’d like to revisit the question of version
I like this approach.
On 09/08/2016 06:04 PM, David Benjamin wrote:
Hi folks,
I’d like to revisit the question of version negotiation.
EKR wrote up some text for moving version negotiation to an extension:
https://github.com/tlswg/tls13-spec/pull/632
I would like us to adopt this proposal.
I support this proposal.
Xiaoyin
From: David Benjamin<mailto:david...@chromium.org>
Sent: Thursday, September 8, 2016 12:09 PM
To: tls@ietf.org<mailto:tls@ietf.org>
Subject: [TLS] Version negotiation, take two
Hi folks,
I'd like to revisit the question of version negotiation.
We already have a useless field in the record header; the record_version is
fixed to { 3, 1 }; and this is not a coincidence.
I think it would be better to maintain a 1.2-compatible version negotiation for
backwards compatibility, and have a more robust and expressive version
negotiation
Hi folks,
I’d like to revisit the question of version negotiation.
EKR wrote up some text for moving version negotiation to an extension:
https://github.com/tlswg/tls13-spec/pull/632
I would like us to adopt this proposal.
In Berlin, this really got framed as a pragmatic question: the current
26 matches
Mail list logo