Re: [TLS] Thoughts on Version Intolerance

Yuhong Bao <YuhongBao_386@hotmail.com> Sat, 23 July 2016 07:10 UTC

Return-Path: <YuhongBao_386@hotmail.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 CF12112D145 for <tls@ietfa.amsl.com>; Sat, 23 Jul 2016 00:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.756
X-Spam-Level:
X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 xtEkfJ0Kyadh for <tls@ietfa.amsl.com>; Sat, 23 Jul 2016 00:10:30 -0700 (PDT)
Received: from BAY004-OMC4S24.hotmail.com (bay004-omc4s24.hotmail.com [65.54.190.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2B412D5E8 for <tls@ietf.org>; Sat, 23 Jul 2016 00:10:30 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com ([65.54.190.201]) by BAY004-OMC4S24.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 23 Jul 2016 00:10:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5uhWzBiGZUtA7Cdnkkmlo21kAglna1gkqcWxdywulnk=; b=DCkAfs9Vwhcbuf4H4dzUpLVFRj80fcwagq4AyJ10ogXafPyD65/LRfybtstt51YB6piJ42cpwUgcWTcPk4wN4d8jOd/DmahXM+xrRZtuE4ZzcbGtXw5J5cb/h6wU0ip4TLZbHf5djY6dVI/7JGP8HU+19sGKhXI72vH/HTzK8XyQzwh/lI00yybvAhs5ma778lfvaqUEqa9K5JssJKSPogdlByC3n6UHEc2O7TbnlbejHBf3j4Xk3MCGbcDdbpRxj+aD305DN7+/7EgdTddwzX6GbFr0s65bxin/oQ1cSTMqyO/dnWPkZ4hjpWNE/9fiGaHLcrSRyFL09SFuUtYEWw==
Received: from CO1NAM03FT036.eop-NAM03.prod.protection.outlook.com (10.152.80.59) by CO1NAM03HT202.eop-NAM03.prod.protection.outlook.com (10.152.81.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5; Sat, 23 Jul 2016 07:10:29 +0000
Received: from DM2PR07MB287.namprd07.prod.outlook.com (10.152.80.53) by CO1NAM03FT036.mail.protection.outlook.com (10.152.80.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5 via Frontend Transport; Sat, 23 Jul 2016 07:10:30 +0000
Received: from DM2PR07MB287.namprd07.prod.outlook.com ([169.254.14.188]) by DM2PR07MB287.namprd07.prod.outlook.com ([169.254.14.188]) with mapi id 15.01.0528.027; Sat, 23 Jul 2016 07:10:27 +0000
From: Yuhong Bao <YuhongBao_386@hotmail.com>
To: David Benjamin <davidben@chromium.org>, Benjamin Kaduk <bkaduk@akamai.com>, Hanno Böck <hanno@hboeck.de>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Thoughts on Version Intolerance
Thread-Index: AQHR4OTJ0GaEVOOFWEy8xwOWQyWt9KAeKQuAgALlKQCAAAtcgIAAX5yAgAE3ywCAAu/Leg==
Date: Sat, 23 Jul 2016 07:10:27 +0000
Message-ID: <DM2PR07MB2874C3335F378B3B53185ECC30B0@DM2PR07MB287.namprd07.prod.outlook.com>
References: <20160718130843.0320d43f@pc1> <1735315.hXCMA8agXV@pintsize.usersys.redhat.com> <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> <20160720120125.43f61155@pc1> <98ba8be3-54ca-636b-bca4-4b83682708f5@akamai.com>, <CAF8qwaAZ+c0th_n_MZtnBXUg64eaf58DPhoFaPcntST1kcPFZA@mail.gmail.com>
In-Reply-To: <CAF8qwaAZ+c0th_n_MZtnBXUg64eaf58DPhoFaPcntST1kcPFZA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=softfail (sender IP is 10.152.80.53) smtp.mailfrom=hotmail.com; chromium.org; dkim=none (message not signed) header.d=none;chromium.org; dmarc=fail action=none header.from=hotmail.com;
received-spf: SoftFail (protection.outlook.com: domain of transitioning hotmail.com discourages use of 10.152.80.53 as permitted sender)
x-tmn: [5g2vigHRBsGedvUvfvefkL3HsxVdL4xQ]
x-eopattributedmessage: 0
x-forefront-antispam-report: CIP:10.152.80.53; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1NAM03HT202; H:DM2PR07MB287.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:;
x-ms-office365-filtering-correlation-id: c2b968e6-533a-446c-8efa-08d3b2c86c8c
x-microsoft-antispam: UriScan:; BCL:1; PCL:0; RULEID:(1601124038)(1601125047); SRVR:CO1NAM03HT202;
x-exchange-antispam-report-cfa-test: BCL:1; PCL:0; RULEID:(432015012)(82015046); SRVR:CO1NAM03HT202; BCL:1; PCL:0; RULEID:; SRVR:CO1NAM03HT202;
x-forefront-prvs: 0012E6D357
Content-Type: multipart/alternative; boundary="_000_DM2PR07MB2874C3335F378B3B53185ECC30B0DM2PR07MB287namprd_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2016 07:10:27.2496 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM03HT202
X-OriginalArrivalTime: 23 Jul 2016 07:10:30.0520 (UTC) FILETIME=[4BF5CF80:01D1E4B1]
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Lbgc5wm-EwiCtItUVwXtZZr-stM>
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: Sat, 23 Jul 2016 07:10:34 -0000

I was the one who found out about how they "fixed" TLS 1.1 version intolerance in Cisco CSS11503 equipment:

https://bugzilla.mozilla.org/show_bug.cgi?id=1143035

________________________________
From: TLS <tls-bounces@ietf.org> on behalf of David Benjamin <davidben@chromium.org>
Sent: Thursday, July 21, 2016 3:19:34 AM
To: Benjamin Kaduk; Hanno Böck; tls@ietf.org
Subject: Re: [TLS] Thoughts on Version Intolerance

On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk <bkaduk@akamai.com<mailto:bkaduk@akamai.com>> wrote:
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<mailto: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.

[Credit where credit is due, I was not the first to propose the version list. I don't know who was first, but Dave Garrett had proposed the same thing. The TLS 1.3 implementors effectively did so too with the draft version extension. Though I think the fake versions idea is new?]

I should also add that, even if we ever got to our prerequisite quiet point, this scheme is still problematic. If we had a list, all clients could participate in this fuzzing and we have a shot at vaccinating the ecosystem. This one violates the specification, so only clients which can rapidly deploy changes can safely do it. (Some sort of field trial mechanism, for instance.) And it requires manual work to sustain: I would probably only do it for, say, 3 months at a time and manually extend so long as TLS 1.4 does not exist. I would not want to cause problems by forgetting to turn it off.

And as Hubert notes, there may well be other intolerance triggers to clear through. 1.3 has a larger ClientHello. We have also never added a new signature algorithm before. But I think that just means we have more rusted protocol joints fix rather than just the one.

Fortunately, most of our other joints admit this kind of fuzzing. It's just the versioning scheme (fixable with a list), and large ClientHellos. I don't have a good answer to the second one, but I would be very happy if it were our only problem. It's much easier to understand. The version one is surprisingly difficult. The conversations usually go like this:

"Hi, your server software appears to have a bug where you reject TLS 1.2 ClientHellos rather than implementing the version negotiation right."
"Okay, we will deploy TLS 1.2."
"No, please don't fix this with 1.2. That's a different problem."
"You don't want us to add 1.2?"
"No no no. Please do switch to 1.2. I mean... oh, nevermind. I'll just email you later for 1.3."

I am obviously exaggerating for humor, but it's a very common confusion and I think is part of why version intolerance keeps on existing.

If you implement the latest version of TLS but are intolerant to N+1, even if no clients did fallbacks, your bug will not be noticed and you'll thrive in the ecosystem. Then when we go to deploy N+1, we have problems. We want, as much as possible, turn tomorrow's interop failures into today's interop failures so the bugs are caught before software ships.

David

-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 mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls