Another concern here is that in order to reduce memory footprint, some implementations will probably introduce bugs by trying to optimize and infer the version by observing the cipher-suits in client hello instead waiting for the extension.
Cheers, Vlad > On 19 Sep 2016, at 03:42, Hubert Kario <hka...@redhat.com> wrote: > > On Saturday, 17 September 2016 01:04:07 CEST David Benjamin wrote: >> On Fri, Sep 16, 2016 at 4:29 PM Andrei Popov <andrei.po...@microsoft.com >> <mailto: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. > > I don't see how that prevents streaming implementation - warning alerts is > something you can handle in the dispatcher (though I'm not sure why it's > something you should worry /before/ the first client hello received), then to > the specific implementation you pass the buffer with current record and the > socket, the first of which may be empty if the record boundary landed right > after the client_version > >> 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 >> <https://github.com/tlswg/tls13-spec/wiki/Implementations#version-negotiation> > > for experimental implementations memory usage is not such a big problem, it's > not the case for everybody > >> 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. > > hmm, what if we did define both mechanisms? so that clients that worry about > compatibility with the broken servers can advertise TLSv1.3 through extension > while ones that don't, advertise through client_version? > > similar to how secure renegotiation indication works > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com <http://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
