On Fri, Sep 16, 2016 at 4:29 PM Andrei Popov <andrei.po...@microsoft.com> 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 ordering requirements. Agreed. If we're concerned with the order, I suppose are other options like smuggling them in the front of the cipher list or hacky things like that. :-) But using extensions is cleaner, and still perfectly deployable. > 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. Yes, these implementations (Windows TLS stack included) will need to do more elaborate/slightly slower pre-parsing if we use TLS version negotiation via TLS extension(s). Not something I like, but can be done. TLS already does not strictly permit sniff-based implementations like this. A handshake message may be fragmented pathologically or even interspersed with warning alerts. It's doable if you reject such fragmentations (no one would send a ClientHello this way...), but you need to be careful because this fragmentation does not figure into the handshake transcript. In particular, you cannot have an else clause in your dispatch. The dispatcher must reject anything it can't definitively resolve rather than blindly forward to your pre-TLS-1.3 implementation. CVE-2014-3511 is an example of OpenSSL's 1.0.x sniff-based implementation going wrong (OpenSSL 1.1.x is no longer sniff-based). It is a particularly silly instance, but it's the sort of failure mode you can get. Further, with the current trajectory, TLS 1.3 servers will need to do version-negotiation based on extensions anyway. All the various implementors have been using this "draft_version" extension to experiment with TLS 1.3. (draft_version is really just a worse version of this proposal.) https://github.com/tlswg/tls13-spec/wiki/Implementations#version-negotiation I don't think anyone has actually enabled client code by default yet, but once anyone does, servers will need to process extensions for versioning until draft TLS 1.3 clients are out of the ecosystem. This seems the worst of both worlds. We'll have extensions in versioning and an undeployable protocol. I think we should go for the latter and, if we must have 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 <hka...@redhat.com> 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 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 _______________________________________________ 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