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 stream-lined parsing of the hello, with minimal buffering. Also note that several fields *preceding* the extensions have special values for TLS 1.3. Delaying this decision until after all the extensions are parsed will make implementations that much more complex, memory consuming, and slower (HOL blocking), plus potentially leading to new bugs we want to avoid. At the very least, if version is negotiated as extension it must be the very first extension advertised. Cheers, Vlad > On 15 Sep 2016, at 11:03, Hubert Kario <hka...@redhat.com> wrote: > > 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 one extension point and actively defending it, >>> then we should probably follow the theory and send a separate TLS >>> extension per TLS version. >> To me, the (ordered) list of client supported versions in a single >> extension feels more intuitively natural, so I want to try harder to >> understand the reasoning that leads you to prefer a separate extension >> for each version. Is it just that doing an additional "negotiation" >> within the extension body constitutes another extension point that we >> would have to actively defend, or is there something else about what a >> TLS extension is philosophically supposed to indicate? > > the extensions joint is well greased and works > > the lists inside extensions are a hit and miss, they mostly work, but then we > have SNI in general, signature methods in past NSS versions, and if you dug > more I wouldn't be surprised if you found half a dozen other issues just like > it (in late October I may have actual numbers about it) > > -- > 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_______________________________________________ > 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
