Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
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) designed to be a general purpose long-term solution that could handle 1.3, 1.4, draft versions, experiments, etc, without special-casing. I'm not fundamentally against just adding a TLS 1.3 version indicator extension and freezing the old version number to 1.2. It just feels a little more hacky to me, though in the short-term it's simpler. With respect to the concern of version numbers being moved to a non-fixed position, we could just require that the new version list extension be first or last in the extensions list. Being required to be last would also permanently mitigate the known issue of some buggy servers choking with an empty extension last. Conversely, with an empty extension indicator for each 1.3+ version, we'd probably want to require that to be first in the list to avoid that bug. (servers would of course still have to parse as an extension as not all clients will be sending 1.3+, so it's not reliably placed like the current hello version) Dave On Friday, June 03, 2016 02:19:52 pm David Benjamin wrote: > 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 rather bored of this fallback game. We can actually > avoid the intolerance problem with this mechanism. Suppose we used empty > indicator extensions, one for each new version. Then as long as servers > tolerate unknown extensions, we'll be fine. So far this has not rusted yet, > and we can defend it from rust by having clients send random fake > extensions out of a range of values we burn for this purpose[*] (or private > use area). If one extension with a list of values, we can do something > similar. > > (Strictly speaking, the version already does not appear at a fixed position > because a ClientHello may be pathologically fragmented. OpenSSL even had > CVE-2014-3511 here. I believe the master branch no longer has a sniff-based > version negotiation. BoringSSL hasn't for a while now. But rejecting such > pathologically fragmented ClientHellos is reasonable and OpenSSL 1.0.x does > it now.) > > David > > [*] I'm planning on writing something up here soon. > > On Fri, Jun 3, 2016 at 1:40 PM Viktor Dukhovni> wrote: > > > 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 through extensions would be a major > > implementation burden. At present the client version appears early > > in the ClientHello at a fixed position in the packet, and the server > > can quickly grab the version, compute the highest shared version > > and branch to the protocol implementation for that version to parse > > the rest of the ClientHello. > > > > Putting the client version in an extension dramatically complicates > > server-side processing. So my view is that this would not be > > progress. This is IMNSHO even less likely to interoperate than > > what we have now. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
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 rather bored of this fallback game. We can actually avoid the intolerance problem with this mechanism. Suppose we used empty indicator extensions, one for each new version. Then as long as servers tolerate unknown extensions, we'll be fine. So far this has not rusted yet, and we can defend it from rust by having clients send random fake extensions out of a range of values we burn for this purpose[*] (or private use area). If one extension with a list of values, we can do something similar. (Strictly speaking, the version already does not appear at a fixed position because a ClientHello may be pathologically fragmented. OpenSSL even had CVE-2014-3511 here. I believe the master branch no longer has a sniff-based version negotiation. BoringSSL hasn't for a while now. But rejecting such pathologically fragmented ClientHellos is reasonable and OpenSSL 1.0.x does it now.) David [*] I'm planning on writing something up here soon. On Fri, Jun 3, 2016 at 1:40 PM Viktor Dukhovniwrote: > 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 through extensions would be a major > implementation burden. At present the client version appears early > in the ClientHello at a fixed position in the packet, and the server > can quickly grab the version, compute the highest shared version > and branch to the protocol implementation for that version to parse > the rest of the ClientHello. > > Putting the client version in an extension dramatically complicates > server-side processing. So my view is that this would not be > progress. This is IMNSHO even less likely to interoperate than > what we have now. > > -- > Viktor. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
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 through extensions would be a major implementation burden. At present the client version appears early in the ClientHello at a fixed position in the packet, and the server can quickly grab the version, compute the highest shared version and branch to the protocol implementation for that version to parse the rest of the ClientHello. Putting the client version in an extension dramatically complicates server-side processing. So my view is that this would not be progress. This is IMNSHO even less likely to interoperate than what we have now. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
That's a clearer version of what I was trying to say. -Ekr On Fri, Jun 3, 2016 at 10:28 AM, Andrei Popovwrote: > 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 [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 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 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) > > This was the result of prior discussions on-list about TLS version > intolerance. The gist of the proposal: > 1) Freeze all the various version number fields. > 2) Send a list of all supported versions in an extension. (version IDs > converted to 16-bit ints instead of 8-bit pairs) > 3) Use short (1 or 2 value, based on hello version) predefined lists for > hellos from old clients not sending the extension. > 4) Compare lists to find highest overlap, avoiding guesswork or problems > with noncontinuous lists. > 5) Forget the old mess of version intolerance existed. > > Do we want to consider scrapping the old version negotiation method again? > > > Dave > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
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 [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, June 3, 2016 6:40 AM To: Dave GarrettCc: 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'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 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) This was the result of prior discussions on-list about TLS version intolerance. The gist of the proposal: 1) Freeze all the various version number fields. 2) Send a list of all supported versions in an extension. (version IDs converted to 16-bit ints instead of 8-bit pairs) 3) Use short (1 or 2 value, based on hello version) predefined lists for hellos from old clients not sending the extension. 4) Compare lists to find highest overlap, avoiding guesswork or problems with noncontinuous lists. 5) Forget the old mess of version intolerance existed. Do we want to consider scrapping the old version negotiation method again? Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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'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 Garrettwrote: > 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) > > This was the result of prior discussions on-list about TLS version > intolerance. The gist of the proposal: > 1) Freeze all the various version number fields. > 2) Send a list of all supported versions in an extension. (version IDs > converted to 16-bit ints instead of 8-bit pairs) > 3) Use short (1 or 2 value, based on hello version) predefined lists for > hellos from old clients not sending the extension. > 4) Compare lists to find highest overlap, avoiding guesswork or problems > with noncontinuous lists. > 5) Forget the old mess of version intolerance existed. > > Do we want to consider scrapping the old version negotiation method again? > > > Dave > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
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, 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 > > is always present and none are meaningful in TLS.1.2. > > But they cannot be used to distinguish TLS 1.3 with any future > versions, if these two extensions still exist in TLS 1.4, 1.5, ... . TLSv1.4 and TLSv1.5 can introduce their own extensions, empty ones in worst case -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
> 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: > > 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 > is always present and none are meaningful in TLS.1.2. But they cannot be used to distinguish TLS 1.3 with any future versions, if these two extensions still exist in TLS 1.4, 1.5, ... . Best,Xiaoyin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
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 because version negotiation is commonly gotten wrong doesn't look like a solution to me... 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. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
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, but it probably needs some work; > was just a WIP branch, never a PR) > This was the result of prior discussions on-list about TLS version > intolerance. The gist of the proposal: > 1) Freeze all the various version number fields. > 2) Send a list of all supported versions in an extension. (version > IDs converted to 16-bit ints instead of 8-bit pairs) > 3) Use short (1 or 2 value, based on hello version) predefined lists > for hellos from old clients not sending the extension. > 4) Compare lists to find highest overlap, avoiding guesswork or > problems with noncontinuous lists. > 5) Forget the old mess of version intolerance existed. I had originally similar thoughts, but doesn't that introduce a 4th version negotiation mechanism? We already have the current version negotiation mechanism(1), the extension mechanism(2), the ciphersuite negotiation(3), and we are getting a new version negotiation mechanism based on extensions(4). Note that (1),(2) and (3) aren't getting away if we introduce (4). The code will stay in implementations for more than a decade. 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. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls