Re: [TLS] Version negotiation, take two

David Benjamin <> Wed, 14 September 2016 16:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CED812B24E for <>; Wed, 14 Sep 2016 09:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Status: No, score=-4.207 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.508, 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 yqhEodamuaaP for <>; Wed, 14 Sep 2016 09:20:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 020D512B204 for <>; Wed, 14 Sep 2016 09:18:43 -0700 (PDT)
Received: by with SMTP id o3so52049984ita.1 for <>; Wed, 14 Sep 2016 09:18:43 -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=Bv7VphmYxnZDw66V0OAdn+WPIPiKMfBTABESwSZS2U4=; b=jXUFDWgGfNANlpDnFHFejfX9LENhnhfyBtVldjH7EqNm8GlAZdZ3Ue9pkNO+YPnhZt EdtPV0vtRyx+qlhWisY7u313gWnTjSQA+D4Iz+yL/yqGOlEq+xEx/ierUJasj7rzD3I1 /S4AsHT0wFCzz/SMSbqWNH0ShvrEmYWe8EF5E=
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=Bv7VphmYxnZDw66V0OAdn+WPIPiKMfBTABESwSZS2U4=; b=b6bj/CszAlKKoyN0CR6MFeOGriZ459pSmudvriqtWFoJM1Hj7pzuGr6puXcl6DIsUK gyY95zu8ERWn2CO0RsbOLxcgU6N9dYvbJ674a5Whz+a4fAl8ypBB51FJRg9UcQm7PsiA Dm4b9ATM+totD8RSCXj5dQ+QbrgQ+bG1YaiBh/yt+BawZV66OshujB8cKcBnv/uO6g/F qxDRmtRjuLa9Qx4DuldENQYuh8sSVP6tenm63xgYpAXw6KLjBNbp+U02eJ09+P9lPoEc laegOhnyppRa3cq8dmFYQjzDvKDh2yt1sbiPKNhyjKRRGatQDrOrxhbIovP+JhT6oSCh JTgA==
X-Gm-Message-State: AE9vXwNqSzbK6qzwG3xbfeXsOHPyuQ1eTKTsW3PrdrUK895OvFbXcJTw5kHcuTWwyUjikCvyAik0TfgX98ghLIM2
X-Received: by with SMTP id w204mr2729742iow.187.1473869880577; Wed, 14 Sep 2016 09:18:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 14 Sep 2016 16:17:50 +0000
Message-ID: <>
To: Benjamin Kaduk <>, Hubert Kario <>,
Content-Type: multipart/alternative; boundary=001a11443b3abd2e05053c7a125d
Archived-At: <>
Subject: Re: [TLS] Version negotiation, take two
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: Wed, 14 Sep 2016 16:20:59 -0000

On Wed, Sep 14, 2016 at 11:46 AM Benjamin Kaduk <> wrote:

> On 09/14/2016 04:56 AM, Hubert Kario wrote:
> First, I don't think that the argument that the current version scheme doesn't
> lend itself to future-proofing is correct. Just as with GREASE, browsers can
> send much higher version than they really support if they do that on a time
> limited basis.
> David had previously convinced me that it doesn't actually work very well,
> but I forget the reasoning he used to do so. :(

Right, this was suggested at Berlin but is not very realistic.

First it requires that clients do so with very careful precautions
(time-limited, server-side field trials, etc.). There cannot be
fake-TLS-1.4 clients by the time real-TLS-1.4 is to exist. If enough
implementations mess up, we lose. With a list, any library can freely
implement this without depending on extra infrastructure.

Second, even if we were to advertise TLS 1.4 when we really mean TLS 1.3,
we still cannot deploy TLS 1.3 as-is without a TLS 1.2 fallback.
Version-intolerant servers will continue to get deployed unnoticed. We need
to get to a quiet point where the extension point works before we can start
meaningfully applying GREASE. All GREASE does is try to exercise
rarely-exercised extension point.

Because I am unreasonably amused by this metaphor, if the joint has
completely rusted shut already, we won't be able to get the GREASE in
there. It needs to have some mobility left.

Second, while the "joint" which handles new extensions IDs doesn't seem to be
> rusting, it's not the case with lists in particular extensions. SNI being the
> prime example where sending anything but a single host name value will most
> likely lead to your client hello being either misinterpreted or rejected.
> But people will ~always be sending multiple elements in the list in the
> version-negotiation extension -- you can't just send TLS 1.3; you also send
> 1.2 for the near future.  And if browsers are grease-ing from the
> beginning, I don't really see this one rusting.

Right, SNI should just never have been an extension point. We have
multi-valued lists elsewhere and they've worked fine. I can only speak to
Chrome's experience, but we add cipher suites without worry. We
successfully deployed X25519. RSA-PSS is going through the release process
now. (We expect breakage from an old NSS bug, but probes of top sites
suggest it will be tolerable.) TLS 1.3 adds even more lists. We're already
assuming lists work.

Yes, we find list intolerance too---servers which only look at the second
byte in a cipher suite, servers which forgot a default in their NamedGroup
switch-case, servers which get confused on unknown HashAlgorithms, servers
which require the final extension non-empty---but this is dramatically less
than version intolerance. It's usually within tolerable levels that we
needn't resort to fallbacks.

The proposal switches from something which we know does not work to
something new. Perhaps this new one will break too, but it is very similar
to things that have worked before, and I am hopeful that GREASE will help.