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&S On M

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 Kario

Re: [TLS] Version negotiation, take two

On Saturday, 17 September 2016 01:04:07 CEST David Benjamin wrote: > On Fri, Sep 16, 2016 at 4:29 PM Andrei Popov > > wrote: > > At the very least, if version is negotiated as extension it must be the > > very first extension advertised. > I don't think it's a good idea to impose extension order

Re: [TLS] Version negotiation, take two

the former, at least 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 Cc: tls@ietf.org Subject: Re: [TLS] Version negotiation, take two I am opposed to this cha

Re: [TLS] Version negotiation, take two

-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 Cc: tls@ietf.org Subject: Re: [TLS] Version negotiation, take two I am opposed to this change. I don’t think that version selection as an extensi

Re: [TLS] Version negotiation, take two

I am opposed to this change. I don’t think that version selection as an extension is such a good idea. Some implementations out there rely on the fact that they can read the first two bytes of the client hello, and take the appropriate code path on the spot. That allows for a very simple and st

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 oiled

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 v

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 on

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 f

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 represents

Re: [TLS] Version negotiation, take two

to:hka...@redhat.com] > Sent: Wednesday, September 14, 2016 11:03 AM > To: Andrei Popov > Cc: David Benjamin ; tls@ietf.org > Subject: Re: [TLS] Version negotiation, take two > > On Wednesday, 14 September 2016 17:39:59 CEST Andrei Popov wrote: > > > Do you mean a TLS

Re: [TLS] Version negotiation, take two

- From: Salz, Rich [mailto:rs...@akamai.com] Sent: Wednesday, September 14, 2016 12:09 PM To: Andrei Popov ; Hubert Kario Cc: tls@ietf.org Subject: RE: [TLS] Version negotiation, take two Are there national TLS standards, or just national crypto-suites

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

gside IETF TLS versions. Cheers, Andrei -Original Message- From: Hubert Kario [mailto:hka...@redhat.com] Sent: Wednesday, September 14, 2016 11:03 AM To: Andrei Popov Cc: David Benjamin ; tls@ietf.org Subject: Re: [TLS] Version negotiation, take two On Wednesday, 14 September 2016 17:39:5

Re: [TLS] Version negotiation, take two

ber 14, 2016 9:40 AM > To: David Benjamin > 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 the > >

Re: [TLS] Version negotiation, take two

-boun...@ietf.org] On Behalf Of Hubert Kario Sent: Wednesday, September 14, 2016 9:40 AM To: David Benjamin 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 loo

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 higher version than th

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 b

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 exte

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&S > On Sep 08, 2016, at 12:04, David Benjamin wrote: > > Hi folks, > > I’d like to revisit the questio

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 follow through with 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 negotiat

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

Re: [TLS] Version negotiation, take two

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 negotiati

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

[TLS] Version negotiation, take two

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 v