Re: [TLS] Thoughts on Version Intolerance
Hubert Kario <hkario@redhat.com> Wed, 20 July 2016 13:14 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 D180C12B019 for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 06:14:03 -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 yKb40GjHLSTs for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 06:14:00 -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 CC3D312D62E for <tls@ietf.org>; Wed, 20 Jul 2016 06:14:00 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 94DEA6540B; Wed, 20 Jul 2016 13:13:59 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx10.intmail.prod.int.phx2.redhat.com (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 <hkario@redhat.com>
To: Kyle Rose <krose@krose.org>
Date: Wed, 20 Jul 2016 15:13:57 +0200
Message-ID: <1577215.bshq0AhCfG@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: <CAJU8_nV9bcvTBL=x0Q2Q7QNDm+BXswXPZZ75tZ3g=Uw_yO_o8w@mail.gmail.com>
References: <20160720101402.09EC41A504@ld9781.wdf.sap.corp> <7776970.MmWSFEWlvc@pintsize.usersys.redhat.com> <CAJU8_nV9bcvTBL=x0Q2Q7QNDm+BXswXPZZ75tZ3g=Uw_yO_o8w@mail.gmail.com>
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 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 20 Jul 2016 13:13:59 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/eUrMbbRDAWYv8a-SJ4hFZoM7juk>
Cc: "<tls@ietf.org>" <tls@ietf.org>
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 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 hard. 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 google.com, 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! -- 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
- [TLS] Client Hello size intolerance Was: Re: Thou… Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Yuhong Bao
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Ivan Ristić
- Re: [TLS] Thoughts on Version Intolerance Yuhong Bao
- Re: [TLS] Thoughts on Version Intolerance Yuhong Bao
- Re: [TLS] Thoughts on Version Intolerance David Benjamin
- Re: [TLS] Thoughts on Version Intolerance Brian Smith
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Peter Gutmann
- Re: [TLS] Thoughts on Version Intolerance Ilari Liusvaara
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance David Benjamin
- Re: [TLS] Thoughts on Version Intolerance Watson Ladd
- Re: [TLS] Thoughts on Version Intolerance Martin Rex
- Re: [TLS] Thoughts on Version Intolerance Benjamin Kaduk
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Watson Ladd
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Kyle Rose
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Martin Rex
- Re: [TLS] Thoughts on Version Intolerance Hanno Böck
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance David Benjamin
- Re: [TLS] Thoughts on Version Intolerance Ilari Liusvaara
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- [TLS] Thoughts on Version Intolerance Hanno Böck
- Re: [TLS] Client Hello size intolerance Was: Re: … David Benjamin
- Re: [TLS] Client Hello size intolerance Was: Re: … Hubert Kario
- Re: [TLS] Client Hello size intolerance Was: Re: … Brian Smith
- Re: [TLS] Thoughts on Version Intolerance Dave Garrett
- Re: [TLS] Thoughts on Version Intolerance Ilari Liusvaara