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