Re: [TLS] Thoughts on Version Intolerance

Hubert Kario <> Thu, 21 July 2016 10:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A986412DCC3 for <>; Thu, 21 Jul 2016 03:47:30 -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 bZcGapAsuBcv for <>; Thu, 21 Jul 2016 03:47:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00F4112DAE3 for <>; Thu, 21 Jul 2016 03:43:02 -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 90D5B7F6A8; Thu, 21 Jul 2016 10:43:01 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id u6LAgxHY027135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2016 06:43:01 -0400
From: Hubert Kario <>
Date: Thu, 21 Jul 2016 12:42:52 +0200
Message-ID: <>
User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.23.0; x86_64; ; )
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart8183777.xUpXZBdEHM"; 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 ( []); Thu, 21 Jul 2016 10:43:01 +0000 (UTC)
Archived-At: <>
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: Thu, 21 Jul 2016 10:47:31 -0000

On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote:
> Hubert Kario wrote:
> > Martin Rex wrote:
> >> Forget TLS extensions, forget ClientHello.client_version.
> >> Both in fundamentally broken, and led to Web Browsers coming up
> >> with the "downgrade dance" that is target&victim of the POODLE attack.
> >> 
> >> We know fairly reliably what kind of negotiation works just fine:
> >> TLS cipher suite codepoints.
> > 
> > please re-read my mail, they don't:
> > 
> > 49% (6240) are intolerant to a Client Hello with no extensions but
> > big number of ciphers that bring its size to 16388 bytes)
> > 91.5% (11539) are intolerant to a Client Hello with no extensions
> > but a number of ciphers that bring it well above single record layer limit
> > (16.5KiB)
> You're seriously confusing things here.
> Any ClientHello with > 200 Cipher suite code points indicates fairly insane
> Client behaviour, so rejecting it is _perfectly_sane_ server behaviour.

and which part of the standard says that it is "_perfectly_sane_" server 
> Trying to support theoretical encoding size limits is a stupid idea,
> because it leads to endless security problems.  Imposing sane sizes
> plus a safety margin is solid implementation advice.

unlike the endless incompatibility problems?

> Large stuff that doesn't need to be exchanged in abbreviated handshakes
> should *NEVER* be included in ClientHello, because of the performance
> penalties this creates (Network bandwidth for TLS handshake,
> and TCP slow start).

I suggest you take a look at the key_share extension and what are the size 
requirements for PQcrypto key exchanges

> >>> I'm now also collecting some data and have some preliminary
> >>> suspicion on affected devices. My numbers roughly match yours that we
> >>> are in the more or less 3% area of 1.3 intolerance.
> >> 
> >> The TLSv1.2 version intolerance is already a huge problem,
> >> and I'm not seeing it go away.  Acutally Microsoft created an
> >> awfully large installed base of TLSv1.2-intolerant servers
> >> (the entire installed base of Win7 through Win8.1 aka 2008R2, 2012,
> >> 2012R2).
> Please recheck with a vanilla (aka extension-free) ClientHello that
> has ClientHello.client_version = (3,3), to recognize all TLSv1.2-intolerant
> implementations in your counts.

and what about those servers that will abort connection if the RC4 ciphes are 
below the 64'th position in the list?

> >> I would really like to see the TLS WG improving the situation
> >> rather than keep sitting on its hands.  The problem has been well-known
> >> since 2005.  And the "downgrade dance" was a predictably lame approach
> >> to deal with the situation, because it completely subverts/evades the
> >> cryptographic protection of the TLS handshake.
> > 
> > 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.
> Nope, not really.  Limiting PDU sizes to reasonably sane sizes is
> perfectly valid behaviour.  X.509v3 certificates can theoretically include
> CAT MPEGs and amount to megabytes.  A TLS implementation that limits
> the certificate chain (i.e. the TLS Certificate Handshake message) to
> a reasonably sane size with safety margin, say 32 KBytes in total,
> is acting totally reasonable.  Anyone who creates an insane PKI deserves
> to loose, and deserves to loose quite badly.

if it's valid, please point me to the part of RFC that says that.

and we're not talking about Certificate message here, we're talking about 
Client Hello. The absolute upper size limit for it is 131396 bytes. Any 
implementation that can't process messages that big is simply RFC non 

Besides, so what that you can send megabyte sized certificates thought TLS?
even if you do consider it a DoS, pausing the ECDHE key exchange with
a large curve just before Client Key Exchange message is a far more effective 
use of attacker's resources.
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic