Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

Ø 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

Re: [TLS] Version negotiation, take two

> > 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

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

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: > &

Re: [TLS] Version negotiation, take two

- 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

Re: [TLS] Version negotiation, take two

Are there national TLS standards, or just national crypto-suites? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

...@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-

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 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

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

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

Re: [TLS] Version negotiation, take two

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.

Re: [TLS] Version negotiation, take two

I support this proposal. Xiaoyin From: David Benjamin Sent: Thursday, September 8, 2016 12:09 PM To: tls@ietf.org Subject: [TLS] Version negotiation, take two Hi folks, I'd like to revisit the question of version negotiation. EKR wrote up

Re: [TLS] Version negotiation, take two

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