Re: [TLS] Keeping TLS extension points working
Hubert Kario <hkario@redhat.com> Tue, 26 July 2016 10:56 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 E460912D51D for <tls@ietfa.amsl.com>; Tue, 26 Jul 2016 03:56:25 -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 m23TsugYtkZj for <tls@ietfa.amsl.com>; Tue, 26 Jul 2016 03:56:24 -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 917DE12D1C8 for <tls@ietf.org>; Tue, 26 Jul 2016 03:56:24 -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 D2216461C1; Tue, 26 Jul 2016 10:56:23 +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 u6QAuMrX004521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2016 06:56:23 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Tue, 26 Jul 2016 12:56:12 +0200
Message-ID: <2695834.rtq9bPkfeJ@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: <CAF8qwaCaW2Q+z_JoDqzQZaGCWJ2aqUiyK8_J8_CO4Ck_cqtaSA@mail.gmail.com>
References: <CAF8qwaCaW2Q+z_JoDqzQZaGCWJ2aqUiyK8_J8_CO4Ck_cqtaSA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1992926.SEj5avrmM5"; 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.29]); Tue, 26 Jul 2016 10:56:24 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/33I4LWH8Tjn2BlKaYTwQ8cJNFps>
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 10:56:26 -0000
On Monday, 25 July 2016 22:32:29 CEST David Benjamin wrote: > I would like to fix this by reserving a few values in our registries so > that clients may advertise random ones and regularly exercise these > codepaths in servers. If enough of the client base does this, we can turn a > large class of tomorrow's interop failures into today's interop failures. > This is important because an bug will not thrive in the ecosystem if it > does not work against the current deployment. What prevents an implementation from ignoring values from just those reserved ranges and continuing to be intolerant to other values? After all, if they are reserved for this, they just need to ignore those values (as no "real" extension/value will ever use them) to "resolve the problem". -- 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