Re: [TLS] Version negotiation, take two

Vlad Krasnov <> Tue, 20 September 2016 18:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 868CE12B440 for <>; Tue, 20 Sep 2016 11:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IJRMOZS4xHiO for <>; Tue, 20 Sep 2016 11:31:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 630E912B43E for <>; Tue, 20 Sep 2016 11:31:18 -0700 (PDT)
Received: by with SMTP id 21so9997690pfy.0 for <>; Tue, 20 Sep 2016 11:31:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 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 with ESMTPSA id tw2sm40891637pac.41.2016. (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 <>
In-Reply-To: <>
Date: Tue, 20 Sep 2016 11:31:15 -0700
Message-Id: <>
References: <> <> <> <>
To: Hubert Kario <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Version negotiation, take two
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


> 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