Re: [TLS] Keeping TLS extension points working
Hubert Kario <hkario@redhat.com> Tue, 26 July 2016 11:20 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 5FFB312D19B for <tls@ietfa.amsl.com>; Tue, 26 Jul 2016 04:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.189
X-Spam-Level:
X-Spam-Status: No, score=-8.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 YJHI0YJkqHhb for <tls@ietfa.amsl.com>; Tue, 26 Jul 2016 04:20:06 -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 6AE3A12B00B for <tls@ietf.org>; Tue, 26 Jul 2016 04:20:06 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 29D607F3ED; Tue, 26 Jul 2016 11:20:06 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6QBK4I0018874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2016 07:20:05 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Tue, 26 Jul 2016 13:20:04 +0200
Message-ID: <5978094.xVKia22VZX@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.24.0; x86_64; ; )
In-Reply-To: <CAF8qwaAOHox+dKMmKZYV2c35MWLyDn7W-_F6SOJ0WsChXCF_Yg@mail.gmail.com>
References: <CAF8qwaCaW2Q+z_JoDqzQZaGCWJ2aqUiyK8_J8_CO4Ck_cqtaSA@mail.gmail.com> <20160725232307.GJ4670@mournblade.imrryr.org> <CAF8qwaAOHox+dKMmKZYV2c35MWLyDn7W-_F6SOJ0WsChXCF_Yg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1792138.q83CGEY1Ds"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 26 Jul 2016 11:20:06 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4_f2qaRR6CqU1CWB-ZuLEEabcjQ>
Subject: Re: [TLS] Keeping TLS extension points working
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: Tue, 26 Jul 2016 11:20:08 -0000
On Monday, 25 July 2016 23:32:41 CEST David Benjamin wrote: > On Mon, Jul 25, 2016 at 7:23 PM Viktor Dukhovni <ietf-dane@dukhovni.org> > > wrote: > > On Mon, Jul 25, 2016 at 10:32:29PM +0000, David Benjamin wrote: > > > I'm not sure how this process usually works, but I would like to reserve > > > > a > > > > > bunch of values in the TLS registries to as part of an idea to keep our > > > extension points working. Here's an I-D: > > > > > > https://tools.ietf.org/html/draft-davidben-tls-grease-00 > > > > To really make this work, it would be necessary to expand the > > reserved pool gradually, rather than all at once, so that servers > > can't hard-code just the initially reserved pool, and still fail > > with new "real" extensions later. > > My hope is that, especially with the values allocated sparsely, after > getting interop failure once or twice from unknown values, the servers will > quickly figure it out. I'm assuming the implementations simply made > mistakes or weren't paying enough attention to the specification rather > than being actively malicious. > > But, you are right, one failure mode here is implementations may > "accidentally" hard-code the reserved pool... somehow. Then we have "pet-projects" of which the primary/only developer walks away/ changes jobs well after it was tightly integrated with already deployed systems, code that is passed over to interns as nobody either has time, inclination or knows much about <insert main subject matter here> anyway[1]... Thus I don't think it solves the problem even for non malicious programmers While the idea of code points that MUST NOT be negotiated by servers is not bad one from testing perspective, we already have few values like this (0x00,0x14 for cipher, 15 for supported groups, just of the top of my head). And for a test suite any value not defined by IANA already has this function (and you do need to test all those values to search for undocumented features, backdoors, etc. anyway). 1 - talking purely hypothetically here, even if I wanted, I wouldn't know where to point fingers in realm of TLS implementations -- 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
- Re: [TLS] Keeping TLS extension points working Hubert Kario
- [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working Viktor Dukhovni
- Re: [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working Hubert Kario
- Re: [TLS] Keeping TLS extension points working Geoffrey Keating
- Re: [TLS] Keeping TLS extension points working Raja ashok
- Re: [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working Raja ashok
- Re: [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working Steven Valdez
- Re: [TLS] Keeping TLS extension points working Hubert Kario
- Re: [TLS] Keeping TLS extension points working Watson Ladd
- Re: [TLS] Keeping TLS extension points working Sean Turner
- Re: [TLS] Keeping TLS extension points working Adam Langley
- Re: [TLS] Keeping TLS extension points working Wan-Teh Chang
- Re: [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working Sean Turner
- Re: [TLS] Keeping TLS extension points working Hubert Kario
- Re: [TLS] Keeping TLS extension points working David Benjamin
- [TLS] draft-davidben-tls-grease-01 Hubert Kario
- Re: [TLS] draft-davidben-tls-grease-01 David Benjamin
- Re: [TLS] draft-davidben-tls-grease-01 Hubert Kario
- Re: [TLS] draft-davidben-tls-grease-01 David Benjamin
- Re: [TLS] draft-davidben-tls-grease-01 Hubert Kario