On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk <bka...@akamai.com> wrote:
> On 07/20/2016 05:01 AM, Hanno Böck wrote: > > On Wed, 20 Jul 2016 11:20:46 +0200 > > Hubert Kario <hka...@redhat.com> wrote: > > > >> so it looks to me like while we may gain a bit of compatibility by > >> using extension based mechanism to indicate TLSv1.3, > > Just quick: This was discussed yesterday, David Benjamin had an > > interesting proposal, but it was largely met with resistance. So from > > I had some follow-up discussion with David and a few others later in the > day. One point that I think was not clear during the WG session was > whether the check for whether a server's version negotiation is > futureproof could be done in the hot path, so that it is impossible to > implement a server that works in a major browser and is (e.g., 1.4) > version-intolerant. > > Right now, if a browser wants to probe for (e.g., 1.3) version > intolerance, it essentially has to treat it as a data-collection step, > either doing the fallback dance on failure or just doing the probe in > parallel with a 1.2 clienthello that is actually used for the > connection, since we know that 1.3-intolerance exists. With David's > proposal (and potentially variants of the other ones), browsers could > implement a check that sends nonexistent versions in their clienthello, > so that once a server implements 1.3, it would not be 1.4-intolerant. > > If we just keep with the current version negotiation scheme, we'll > always be stuck in the "data-collecting" mode and won't be able to > strictly enforce the future-proofing, since there are existing servers > that are intolerant to the current scheme, and the browsers will be > blamed for breaking sites on those servers if the browsers try to > introduce strict enforcement of version negotiation future-proofing. > [Credit where credit is due, I was not the first to propose the version list. I don't know who was first, but Dave Garrett had proposed the same thing. The TLS 1.3 implementors effectively did so too with the draft version extension. Though I think the fake versions idea is new?] I should also add that, even if we ever got to our prerequisite quiet point, this scheme is still problematic. If we had a list, all clients could participate in this fuzzing and we have a shot at vaccinating the ecosystem. This one violates the specification, so only clients which can rapidly deploy changes can safely do it. (Some sort of field trial mechanism, for instance.) And it requires manual work to sustain: I would probably only do it for, say, 3 months at a time and manually extend so long as TLS 1.4 does not exist. I would not want to cause problems by forgetting to turn it off. And as Hubert notes, there may well be other intolerance triggers to clear through. 1.3 has a larger ClientHello. We have also never added a new signature algorithm before. But I think that just means we have more rusted protocol joints fix rather than just the one. Fortunately, most of our other joints admit this kind of fuzzing. It's just the versioning scheme (fixable with a list), and large ClientHellos. I don't have a good answer to the second one, but I would be very happy if it were our only problem. It's much easier to understand. The version one is surprisingly difficult. The conversations usually go like this: "Hi, your server software appears to have a bug where you reject TLS 1.2 ClientHellos rather than implementing the version negotiation right." "Okay, we will deploy TLS 1.2." "No, please don't fix this with 1.2. That's a different problem." "You don't want us to add 1.2?" "No no no. Please do switch to 1.2. I mean... oh, nevermind. I'll just email you later for 1.3." I am obviously exaggerating for humor, but it's a very common confusion and I think is part of why version intolerance keeps on existing. If you implement the latest version of TLS but are intolerant to N+1, even if no clients did fallbacks, your bug will not be noticed and you'll thrive in the ecosystem. Then when we go to deploy N+1, we have problems. We want, as much as possible, turn tomorrow's interop failures into today's interop failures so the bugs are caught before software ships. David > -Ben > > > the WG discussion yesterday I had the impression that we will most > > likely stay with the existing clienthello version mechanism. While that > > will cause us more trouble, it's probably the cleaner option anyway. So > > we definitely should continue investigating version intolerance and > > tell people to fix their stuff. > > > > _______________________________________________ > 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
