Re: [TLS] Thoughts on Version Intolerance
Benjamin Kaduk <bkaduk@akamai.com> Wed, 20 July 2016 15:43 UTC
Return-Path: <bkaduk@akamai.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 8209512B013 for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 08:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.988
X-Spam-Level:
X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 B2N5b_XkakOh for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 08:43:39 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 63E29120727 for <tls@ietf.org>; Wed, 20 Jul 2016 08:43:39 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7C0244F09C; Wed, 20 Jul 2016 15:43:38 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 63DBA4F072; Wed, 20 Jul 2016 15:43:38 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1469029418; bh=wImDxMYirj5Ge4OxwUjspeXxhiYwW1uYu+CqT1zU+/Q=; l=2078; h=To:References:From:Date:In-Reply-To:From; b=VlEhZ+zw4RKYaU/EkIH4v3XX/YbDnN9Sl5sZwB2IvC48xnWBpqIFbuAs6r1YioURO v+9RgqMooBqOGKNUWX13/ma2hShbRJDneCaVqDUxT7HSwhukTpMyelbYwJ8V/jsIMw nVHZp1E/zUBJNrzlf3TcsqnzyQBcWlG0UNBYfugQ=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 3B5431FC8C; Wed, 20 Jul 2016 15:43:38 +0000 (GMT)
To: Hanno Böck <hanno@hboeck.de>, tls@ietf.org
References: <20160718130843.0320d43f@pc1> <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> <20160720120125.43f61155@pc1>
From: Benjamin Kaduk <bkaduk@akamai.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <98ba8be3-54ca-636b-bca4-4b83682708f5@akamai.com>
Date: Wed, 20 Jul 2016 10:43:37 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160720120125.43f61155@pc1>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qEXYmxThoX7xLSYSWgqiuSy4ACo>
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 15:43:41 -0000
On 07/20/2016 05:01 AM, Hanno Böck wrote: > On Wed, 20 Jul 2016 11:20:46 +0200 > Hubert Kario <hkario@redhat.com> wrote: > >> so it looks to me like while we may gain a bit of compatibility by >> using extension based mechanism to indicate TLSv1.3, > Just quick: This was discussed yesterday, David Benjamin had an > interesting proposal, but it was largely met with resistance. So from I had some follow-up discussion with David and a few others later in the day. One point that I think was not clear during the WG session was whether the check for whether a server's version negotiation is futureproof could be done in the hot path, so that it is impossible to implement a server that works in a major browser and is (e.g., 1.4) version-intolerant. Right now, if a browser wants to probe for (e.g., 1.3) version intolerance, it essentially has to treat it as a data-collection step, either doing the fallback dance on failure or just doing the probe in parallel with a 1.2 clienthello that is actually used for the connection, since we know that 1.3-intolerance exists. With David's proposal (and potentially variants of the other ones), browsers could implement a check that sends nonexistent versions in their clienthello, so that once a server implements 1.3, it would not be 1.4-intolerant. If we just keep with the current version negotiation scheme, we'll always be stuck in the "data-collecting" mode and won't be able to strictly enforce the future-proofing, since there are existing servers that are intolerant to the current scheme, and the browsers will be blamed for breaking sites on those servers if the browsers try to introduce strict enforcement of version negotiation future-proofing. -Ben > the WG discussion yesterday I had the impression that we will most > likely stay with the existing clienthello version mechanism. While that > will cause us more trouble, it's probably the cleaner option anyway. So > we definitely should continue investigating version intolerance and > tell people to fix their stuff. >
- [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