Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients)

Jeffrey Walton <> Thu, 21 May 2015 19:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C87B81A8912 for <>; Thu, 21 May 2015 12:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q_kNL6GBADQc for <>; Thu, 21 May 2015 12:22:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A6D41A8903 for <>; Thu, 21 May 2015 12:22:57 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so18360575igb.1 for <>; Thu, 21 May 2015 12:22:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=dB+dxpnxzJfzsUHhygWOt7nOH2Bp39uE7jLSaEPnz0o=; b=M2WSvmu4Ox3wTR7pV0Jr5K2C/rNKHYJ+4oD2sQ2+JMHosC0btI2oNeh+YtIF+srXAZ f2LWCk04iPlCEjei3mLFw2DkROVHQ2BsNHg0aJ1uOBKvh6m2y3jQReyM+ELg9o4+9qdm INr+Kke6NQ89l9J/i2iGE1VSAAU8Vqc11d7ALgMDKSpqZddaXn2X6JKwVzJzcNCFutFv QhZFcK4l4XKSjKqF9OjirFeYPSHINBhMtGGDTEp0Uarq61DeR1QR3V7/QCgD4YLH4XOL R4D7Up9KCOS387dBHL1dWo/fkYuUaTy6rdzH2E1Rx+/d0QhphLvsvehZ4WWbV8F7ke2Z qa/Q==
MIME-Version: 1.0
X-Received: by with SMTP id o138mr5602314ioo.66.1432236176689; Thu, 21 May 2015 12:22:56 -0700 (PDT)
Received: by with HTTP; Thu, 21 May 2015 12:22:56 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 21 May 2015 15:22:56 -0400
Message-ID: <>
From: Jeffrey Walton <>
To: Dave Garrett <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients)
X-Mailman-Version: 2.1.15
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 May 2015 19:22:58 -0000

On Thu, May 21, 2015 at 12:10 PM, Dave Garrett <> wrote:
> I was going to hold off on suggesting this due to other topics dominating the list, but we might be in a kill-the-old-junk mood due to the latest old-junk vulnerability, so...
> Old versions of TLS need to be phased out at some point (even the one we're designing now), however the current modus operandi is generally to wait until a catastrophic breakage forces everyone into a panic disable. I'd like to at least try to do better prior to the next time. I'd like to propose giving servers & clients different expectations as a transitional measure:
> 1) No general change to current TLS other than pointing to the UTA BCP from time to time.
> 2) For TLS 1.3, add a blurb to the effect of:
> "Server TLS implementations supporting TLS 1.3 or later MUST NOT negotiate TLS 1.0 or TLS 1.1 for any reason.
> Client TLS implementations are RECOMMENDED to not support old TLS versions, where possible."
Now might be a good time to add a (3) for TLS 1.3: have a client
specify both the least TLS version they are willing to use, and the
greatest TLS they desire to use. And MAC or derive from it it so it
can't be tampered or downgraded.

You can still provide the the TLS record layer version, and you can
keep it un-MAC'd so it can be tampered with to cause a disclosure or
crash :)

Effectively, that's how the versions in the record layer and client
protocol are being used. It stops those silly dances the browsers and
other user agents perform without the need for TLS Fallback SCSV.