Re: [TLS] Version negotiation, take two

Hubert Kario <hkario@redhat.com> Mon, 19 September 2016 10:43 UTC

Return-Path: <hkario@redhat.com>
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 D8AEB12B2EE for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 03:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.238
X-Spam-Level:
X-Spam-Status: No, score=-9.238 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 YI9CxgD4lIpS for <tls@ietfa.amsl.com>; Mon, 19 Sep 2016 03:43:06 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56C012B2FB for <tls@ietf.org>; Mon, 19 Sep 2016 03:42:35 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 25598A24F6; Mon, 19 Sep 2016 10:42:35 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8JAgXxe027604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Sep 2016 06:42:34 -0400
From: Hubert Kario <hkario@redhat.com>
To: David Benjamin <davidben@chromium.org>
Date: Mon, 19 Sep 2016 12:42:32 +0200
Message-ID: <3497887.mHMmENVDT3@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.7.3-200.fc24.x86_64; KDE/5.26.0; x86_64; ; )
In-Reply-To: <CAF8qwaDXr=d-H=MDqn8nv+An4jyYGT6H1vB8ZVMbfoGrR=Mn9A@mail.gmail.com>
References: <CAF8qwaA86yytg29QOD_N7ARimh9QcNGU_nnr_OrxqCrvrk2MBg@mail.gmail.com> <CY1PR0301MB084231932E761955373F39668CF30@CY1PR0301MB0842.namprd03.prod.outlook.com> <CAF8qwaDXr=d-H=MDqn8nv+An4jyYGT6H1vB8ZVMbfoGrR=Mn9A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1504106.5UzhfqcBr7"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 19 Sep 2016 10:42:35 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/h3LBkjno2LEZloLxFu9L2zEvKg8>
Cc: "tls@ietf.org" <tls@ietf.org>
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: Mon, 19 Sep 2016 10:43:09 -0000

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