Re: [TLS] Thoughts on Version Intolerance

Hubert Kario <> Wed, 20 July 2016 13:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D180C12B019 for <>; Wed, 20 Jul 2016 06:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.209
X-Spam-Status: No, score=-8.209 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=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yKb40GjHLSTs for <>; Wed, 20 Jul 2016 06:14:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC3D312D62E for <>; Wed, 20 Jul 2016 06:14:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94DEA6540B; Wed, 20 Jul 2016 13:13:59 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id u6KDDw8V018488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2016 09:13:59 -0400
From: Hubert Kario <>
To: Kyle Rose <>
Date: Wed, 20 Jul 2016 15:13:57 +0200
Message-ID: <>
User-Agent: KMail/5.2.3 (Linux/4.6.3-300.fc24.x86_64; KDE/5.23.0; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart10422972.cX2HCJ7cja"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Wed, 20 Jul 2016 13:13:59 +0000 (UTC)
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] Thoughts on Version Intolerance
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: Wed, 20 Jul 2016 13:14:04 -0000

On Wednesday, 20 July 2016 14:49:03 CEST Kyle Rose wrote:
> > it's not IETF's fault that the implementers add unspecified by IETF
> > restrictions and limitations to parsers of Client Hello messages or that
> > they can't handle handshake messages split over multiple record layer
> > messages, despite the standard being very explicit in that they MUST
> > support this
> When the failures are limited to obscure implementations, and/or popular
> ones with a hope of being updated, I'm in the "fix your shit" camp.
> When a substantial fraction of the internet breaks, this approach is less
> clearly the right one because it can result in the never-ending downgrade
> dance, or in limited deployment of new versions/ossification. I hope (with
> no real evidence) that given the strong level of involvement of the major
> browsers in 1.3 development that advantage goes to the client.

I think that implementing complex binary cryptographic protocols is simply 

At the same time many corner cases are not encountered in day to day use, many 
failures are completely silent (TLS POODLE).

Which means that many implementers stop working on their TLS stack as soon as 
they can connect to default OpenSSL instance or to, or can process 
hello message from Internet Explorer/Chrome.

While I think that the standard should be more strict, and the section D.4. we 
know from RFC 5246 should be much longer in the TLSv1.3 document, it won't 
matter if the implementers won't read the thing.

And from what I can see, people that implemented the servers that 90% of Alexa 
top 1 million sites use, simply haven't recognized that section D is 
important. Let alone tested that their implementation actually follows it!
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic