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: =?UTF-8?Q?Hanno_B=c3=b6ck?= <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.
>