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