Re: [TLS] Thoughts on Version Intolerance
Hubert Kario <hkario@redhat.com> Fri, 22 July 2016 10:16 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 712FF12DF93 for <tls@ietfa.amsl.com>; Fri, 22 Jul 2016 03:16:44 -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 3olQqVPvKWRq for <tls@ietfa.amsl.com>; Fri, 22 Jul 2016 03:16:41 -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 7D6EA12DF84 for <tls@ietf.org>; Fri, 22 Jul 2016 03:16:40 -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 434257733E; Fri, 22 Jul 2016 10:08:08 +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 u6MA86Rm023068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2016 06:08:07 -0400
From: Hubert Kario <hkario@redhat.com>
To: Dave Garrett <davemgarrett@gmail.com>
Date: Fri, 22 Jul 2016 12:08:00 +0200
Message-ID: <2581885.dP5x8nd4GP@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.23.0; x86_64; ; )
In-Reply-To: <201607211604.25745.davemgarrett@gmail.com>
References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <4902846.OLd9Rrk6Df@pintsize.usersys.redhat.com> <201607211604.25745.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2282174.zjMWq0J3KQ"; 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.27]); Fri, 22 Jul 2016 10:08:08 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ScWkfdmrahgBYEjPmlRsC9hhJso>
Cc: 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: Fri, 22 Jul 2016 10:16:45 -0000
On Thursday, 21 July 2016 16:04:25 CEST Dave Garrett wrote: > On Thursday, July 21, 2016 06:42:52 am Hubert Kario wrote: > > On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote: > > > 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 > > behaviour? > > On this specific type of issue, I agree with Martin here that sanity checks > for over-the-top configurations are reasonable, however we should be > standardizing this, not having every implementation do this ad hoc. We > really should go through a list of these sort of implementation break > points and start picking arbitrary lines to add to the spec. They don't > have to be ideal numbers; just something better than an upper limit of > 2^15-2 suites (2 bytes each; 2^16-2 max sized vector) would be nice, for > this example. Yes, certain fields have to stay open-ended, namely > extensions, but reasonable limits should be added where appropriate. I don't think that limiting the client hello by just under 2^16 bytes will help much. For memory-limited applications, simply not noting the presence of unrecognised/unsupported ciphers is an easy and robust way of handling huge cipher lists. So limiting it doesn't help much. As you've pointed out, extension list needs to stay unlimited. There's nothing else - session_id already is tiny and compression_methods is just a drop, everything else has static sizes. I'm quite sure that if I were sending a huge extension or many big extensions, the percentage of servers that are incompatible to them would be similar, if not worse. A relatively small 3KiB client hello already causes issues and this is not exactly something impossible to achieve with just TLSv1.2 and session tickets. (I'll try to have more concrete numbers on Monday) -- 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