Re: [TLS] Thoughts on Version Intolerance

David Benjamin <> Thu, 21 July 2016 10:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D458312DC9D for <>; Thu, 21 Jul 2016 03:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q72rYf1WQOQT for <>; Thu, 21 Jul 2016 03:19:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3327012DCB0 for <>; Thu, 21 Jul 2016 03:19:46 -0700 (PDT)
Received: by with SMTP id f93so57591355lfi.2 for <>; Thu, 21 Jul 2016 03:19:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8dSlcv5leiCsSEbVQhzbktZr7J/yNg2uW4j4wct2iQw=; b=c3GHQuwVUT+NKx3+g+vMOtmErhgFf0pi26BdiXjR8bHmSc+cDDwTyN0YUPsld3J/E7 BFJz2PoeX4ELO019zHypIpvtE5I4tNydIzVmAwREO/idi3TJhIcb0zmJnjl7vM4lXvwB ZstQH/RwL0FUKW3wCexOzVn2uXBBg6EY6lghg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8dSlcv5leiCsSEbVQhzbktZr7J/yNg2uW4j4wct2iQw=; b=Frs+W49PQETcl+CBCMRQIkSZoHvuhLuXItK1qJom092vxLDWbbztioqJjExSZuyoyo XTsij7TMwFgec2hca06+bPMTip7QXs+fba/lkD7m2dAjg4iyhoTO0ptBCZzdFcAy3Hd2 EJsq/FvMGD3F7FBt05HghKj1jmR4RFyhAEZ/3eQbiQWAh0bsd5bf/t/bYK1BnJsSFvtE pQn3b9PSthIKiW181ZH/VfaCEBJ0V3+29pwuMordymyOIH/93zbzyr6y+f+RXWhjOUoK Hidxif5UpMlRTisr5oCa5VY+maGwnHhTo8MlbzeWQH4/mJEfSzLfsFHn9zlPf7zlSQoN dxfg==
X-Gm-Message-State: ALyK8tKfOByomBXrJdb+Gwyx1AFQewf4cPT7oErySTHE98WfEP51HHCM4MQ6lgJi8qseLEyZjqhPCO9pR3j8FmnV
X-Received: by with SMTP id e39mr8990624lji.55.1469096384210; Thu, 21 Jul 2016 03:19:44 -0700 (PDT)
MIME-Version: 1.0
References: <20160718130843.0320d43f@pc1> <> <> <20160720120125.43f61155@pc1> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Thu, 21 Jul 2016 10:19:34 +0000
Message-ID: <>
To: Benjamin Kaduk <>, Hanno Böck <>,
Content-Type: multipart/alternative; boundary="001a1142c1301f7f60053822a816"
Archived-At: <>
Subject: Re: [TLS] Thoughts on Version Intolerance
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jul 2016 10:20:00 -0000

On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk <> wrote:

> On 07/20/2016 05:01 AM, Hanno Böck wrote:
> > On Wed, 20 Jul 2016 11:20:46 +0200
> > Hubert Kario <> 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.


> -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