Re: [TLS] Version negotiation, take two

Joseph Salowey <joe@salowey.net> Wed, 21 September 2016 00:09 UTC

Return-Path: <joe@salowey.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBFE12B153 for <tls@ietfa.amsl.com>; Tue, 20 Sep 2016 17:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bloi92_auye8 for <tls@ietfa.amsl.com>; Tue, 20 Sep 2016 17:09:02 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DA712B01A for <tls@ietf.org>; Tue, 20 Sep 2016 17:09:02 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id 11so15533802qtc.0 for <tls@ietf.org>; Tue, 20 Sep 2016 17:09:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=HiOGF1zlCER9qZzrZO8CTf6Tb8kvviDiPPeCq8g9N60=; b=JGNVaJe2kwnlpd0FLJutcggKBXUO8JT23xS7elDwnOHJRtBkeV2DCmU9BHW9tNYgyV pyz0vMhbpBDHx7DTtUnMHk8ctvgbVT0XOV9YbpKR9eZblNg03CYbkPI8wDiMo9itC6rX rJ6d62ExPaCvj+nzM2kEfoNM52TyYnwHKighHJ3Xe0PY81bDxAnOXVGvXJBf7wPZwJ41 slKjIl9x2WoSG6oVMNLMqZg2UlNaqAm/0Mo03hJp/dxcJlyLE4AGUzAlZK3ZyRqlRp+L WToItwgj/DllOVJkiGkMSlfVGEaj8WAV8hc1ccREx3MFUYjlYu9hIRb3mHfSUBEMUPjf qQ1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=HiOGF1zlCER9qZzrZO8CTf6Tb8kvviDiPPeCq8g9N60=; b=TeOcBWqceohSegaTHaZ2pNex9ne7UMEpYVBn2pmZs9B5ZGMBHjf8151r0yzcoHHeZO 1idHO0vUfZaDOgLM7DZ0ve3FATUvYNSc1pnFSGxfmArCWF/IU5QdlMTZxqEzp3+bGT5K iBIaLXdaSSerk+ah+7/52iH9VrJaWrPHdd+qXBgYuQ8hHbcpy81/RYhFANHnDkZ/zAqK bP23B1WGEclk3NaOnurtxHRXaxLKRhBIu8e6Fhf+daNIs0sihx2Xgz2aRyoKe51MAlG8 vftTCBt2UZbR21BiNLtBRer4KqkHYKNJi3g0h9au/Wod2OnxkW+IvMHqPbSci1dCTrgq GdTQ==
X-Gm-Message-State: AE9vXwPQqxzBAx25Ks5fPDfNsKl7CumaejMPJ33kB/Y1p4pVXzr98K9me29DDVmAsgs54fUpq+71Ln0vLOdLpA==
X-Received: by 10.200.46.59 with SMTP id r56mr30516304qta.145.1474416541097; Tue, 20 Sep 2016 17:09:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.162.131 with HTTP; Tue, 20 Sep 2016 17:08:40 -0700 (PDT)
In-Reply-To: <3497887.mHMmENVDT3@pintsize.usersys.redhat.com>
References: <CAF8qwaA86yytg29QOD_N7ARimh9QcNGU_nnr_OrxqCrvrk2MBg@mail.gmail.com> <CY1PR0301MB084231932E761955373F39668CF30@CY1PR0301MB0842.namprd03.prod.outlook.com> <CAF8qwaDXr=d-H=MDqn8nv+An4jyYGT6H1vB8ZVMbfoGrR=Mn9A@mail.gmail.com> <3497887.mHMmENVDT3@pintsize.usersys.redhat.com>
From: Joseph Salowey <joe@salowey.net>
Date: Tue, 20 Sep 2016 17:08:40 -0700
Message-ID: <CAOgPGoDqt_JmC_yvduCjUV=izVsaLaVobaxDzSgU83qDp+F=cg@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113beae22ef559053cf95a12"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xfCh7D7hISFs5x-eA0xHwksoLrc>
Subject: Re: [TLS] Version negotiation, take two
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2016 00:09:06 -0000

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.

Cheers,

J&S

On Mon, Sep 19, 2016 at 3:42 AM, Hubert Kario <hkario@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.Popov@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
>
> 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>