Re: [TLS] RFC8446 backward compatibility question

Toerless Eckert <> Thu, 05 August 2021 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D55833A0C80 for <>; Thu, 5 Aug 2021 14:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iqCwhcHJ9N2q for <>; Thu, 5 Aug 2021 14:36:01 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E1C9D3A0BC0 for <>; Thu, 5 Aug 2021 14:35:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1A890548049; Thu, 5 Aug 2021 23:35:24 +0200 (CEST)
Received: by (Postfix, from userid 10463) id 141794E7C52; Thu, 5 Aug 2021 23:35:24 +0200 (CEST)
Date: Thu, 5 Aug 2021 23:35:24 +0200
From: Toerless Eckert <>
To: "Salz, Rich" <>
Cc: "" <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [TLS] RFC8446 backward compatibility question
X-Mailman-Version: 2.1.29
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, 05 Aug 2021 21:36:14 -0000

Thanks for the explanation.

My main concern was just to understand clearly what requirements
have to be written into RFC when one wants to ensure that TLS 1.2 needs
to be supported as the fallback in a particular solution.

 With TLS 1.3 not mandating support for TLS 1.2, in such cases one
still needs to write MUST support TLS 1.2 when one thought
a MUST TLS 1.3 might have sufficed (assuming it included TLS 1.2
support). A bit more explanatory text in 8446 might have helped.

Also, the immediate status change of "obsoleted by 8446" may
make readers think that TLS 1.3 can take care of migration 
from TLS 1.2 all by itself, when indeed it can not unless you
still also mandate implementing TLS 1.2. Of course we do not
have a better keyword vocabulary. Something like "Sunset by: 8446".


On Thu, Aug 05, 2021 at 09:16:37PM +0000, Salz, Rich wrote:
> >    I am trying to figure out if every implementation compliant with
>     RFC8446 is also necessarily interoperable with an RFC5246 peer, or if this
>     is just a likely common, but still completely optional implementation choice.
> It is possible to have a single stack that implements TLS.[123].  OpenSSL, among many others does this.  Some have implemented ONLY TLS 1.3; that code tends to be cleaner (in a nerd esthetic sense) than code that implements multiple protocols. Some servers even "hand off" pre-1.3 protocols to separate implementations (libraries); FB and Amazon used to do that.
> The wire protocol for TLS 1.3 uses some deliberately-reserved extension fields so that a server which doesn't do 1.3 can fail cleanly, and a server that DOES will work. And also the other way, a 1.3 client can work fine with both a 1.3 server and a 1.[12] server.
> It's easy to rationale 1.3-only for clients. It is harder to rationalize 1.3-only for servers if you are intending those servers to be generally accessible on the public Internet.