Re: [TLS] Version negotiation, take two

Vlad Krasnov <vlad@cloudflare.com> Tue, 20 September 2016 18:31 UTC

Return-Path: <vlad@cloudflare.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 868CE12B440 for <tls@ietfa.amsl.com>; Tue, 20 Sep 2016 11:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (1024-bit key) header.d=cloudflare.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 IJRMOZS4xHiO for <tls@ietfa.amsl.com>; Tue, 20 Sep 2016 11:31:18 -0700 (PDT)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 630E912B43E for <tls@ietf.org>; Tue, 20 Sep 2016 11:31:18 -0700 (PDT)
Received: by mail-pf0-x22b.google.com with SMTP id 21so9997690pfy.0 for <tls@ietf.org>; Tue, 20 Sep 2016 11:31:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=wRNLuoTTLP9MEVTX47SXnM8hzJ4fvIDdSAiU2Ydsdhw=; b=gOBM6VA5oPj9IfSwBE4j2cDD8kA/j0D0c7LDXiJ1X9jL35rWReRtPxQ6L1PX9vNAyF oP8+wwNn02i0X6PTAC20ydCbcPcEM26kJAQwlXmygwT2xAU7v+QXUyWI3cPJon2CpNeQ Un/ecnSRL8yHSi8HaH6HlypLFSqypXkATVQJ8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=wRNLuoTTLP9MEVTX47SXnM8hzJ4fvIDdSAiU2Ydsdhw=; b=aAWUzQlcfAesIsyY5TFnoOjXrk4rkLs2xzZz/6GCNIihqyKw53M/Pxy7e1ft0eSI2Z i/xJXXNLoz3MpOPQCk/XoivjN1/woPCCG34NDFIXHIAzpUrilrCzKt/IvJTBCl29V8yG nIJC++ei75UIPhdi8DZ1Kr4hxyqJCuhEBctSvhUbnriMlLEOY4hDR7o4huKqL1PIEViM FPpjev/Q4bn1Y06xJojJbpj16f+gNi28590JN49LD3SwTajTlwC65dEoXzc7a6DYIm1p 6YYEntu+xW8mlf/ZA8n/onabvvItGfkQd9rs/toNFoOs8JC/zLGJymLUSULilX4BNb7Z SXHg==
X-Gm-Message-State: AE9vXwNIcrKiMse5agA+KUg4Yl1+CbOjyv18JUixIjDL0Y8PycPP+98JLJSKJI5Ckum4KeGa
X-Received: by 10.98.50.2 with SMTP id y2mr57978434pfy.138.1474396277899; Tue, 20 Sep 2016 11:31:17 -0700 (PDT)
Received: from ?IPv6:2606:4700:1000:8200:b854:496c:a663:d2b9? ([2606:4700:1000:8200:b854:496c:a663:d2b9]) by smtp.gmail.com with ESMTPSA id tw2sm40891637pac.41.2016.09.20.11.31.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Sep 2016 11:31:17 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FF0E5C08-E53A-4451-B146-E64230A28D6F"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Vlad Krasnov <vlad@cloudflare.com>
In-Reply-To: <3497887.mHMmENVDT3@pintsize.usersys.redhat.com>
Date: Tue, 20 Sep 2016 11:31:15 -0700
Message-Id: <255CB90E-A832-4F20-93B5-F146CEFDBBEF@cloudflare.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>
To: Hubert Kario <hkario@redhat.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MRttiFflNqhc19wmSqDHzADf4dk>
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: Tue, 20 Sep 2016 18:31:20 -0000

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.

Cheers,
Vlad

> On 19 Sep 2016, at 03:42, 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 <mailto: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 <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 <http://www.cz.redhat.com/>
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic