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.


> On 19 Sep 2016, at 03:42, Hubert Kario <> wrote:
> On Saturday, 17 September 2016 01:04:07 CEST David Benjamin wrote:
>> On Fri, Sep 16, 2016 at 4:29 PM Andrei Popov < 
>> <>>
>> 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.)
>> <>
> 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: <>
> Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic

TLS mailing list

Reply via email to