It looks like we have enough consensus to move to an extension based
version negotiation mechanism so we're asking the author to merge in this
pull request. We can have further refinement of the details, but its
important for us to get a complete view of the spec at this point.
On Mon, Sep 19, 2016 at 3:42 AM, 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
> > 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
> > 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
> > 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
> > A handshake message may be fragmented pathologically or even interspersed
> > with warning alerts. It's doable if you reject such fragmentations (no
> > 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
> > 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
> 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
> > 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-
> for experimental implementations memory usage is not such a big problem,
> 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
> > 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
> compatibility with the broken servers can advertise TLSv1.3 through
> while ones that don't, advertise through client_version?
> similar to how secure renegotiation indication works
> 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 mailing list