Re: [TLS] Version negotiation, take two

[Hubert Kario <[e-mail]>]

On Saturday, 17 September 2016 01:04:07 CEST David Benjamin wrote:
> On Fri, Sep 16, 2016 at 4:29 PM Andrei Popov <[e-mail]>
> 
> 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

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
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic