Re: [TLS] Thoughts on Version Intolerance

Hubert Kario <hkario@redhat.com> Wed, 20 July 2016 12:36 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 33E9C12D187 for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 05:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.209
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmtd1gP4bNTa for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 05:36:09 -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 429AE12D552 for <tls@ietf.org>; Wed, 20 Jul 2016 05:36:09 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 AA75963321; Wed, 20 Jul 2016 12:36:08 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6KCa7Jk031321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2016 08:36:08 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org, mrex@sap.com
Date: Wed, 20 Jul 2016 14:36:06 +0200
Message-ID: <7776970.MmWSFEWlvc@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.3-300.fc24.x86_64; KDE/5.23.0; x86_64; ; )
In-Reply-To: <20160720101402.09EC41A504@ld9781.wdf.sap.corp>
References: <20160720101402.09EC41A504@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2058958.CnHea5GNph"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 20 Jul 2016 12:36:08 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qne9M4gAqc5ufh6UB0wXhkIJoO0>
Subject: Re: [TLS] Thoughts on Version Intolerance
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: Wed, 20 Jul 2016 12:36:12 -0000

On Wednesday, 20 July 2016 12:14:01 CEST Martin Rex wrote:
> Hanno Böck wrote:
> 
> Checking application/pgp-signature: FAILURE
> 
> > Hubert Kario <hkario@redhat.com> wrote:
> >> so it looks to me like while we may gain a bit of compatibility by
> >> using extension based mechanism to indicate TLSv1.3,
> 
> 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)

> > 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).
> 
> 
> 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

-- 
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