Re: [TLS] RFC8446 backward compatibility question

Toerless Eckert <tte@cs.fau.de> Fri, 06 August 2021 00:14 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 3D27D3A12C6 for <tls@ietfa.amsl.com>; Thu, 5 Aug 2021 17:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 kvRk0oTjsuR1 for <tls@ietfa.amsl.com>; Thu, 5 Aug 2021 17:14:23 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A15F3A12C4 for <tls@ietf.org>; Thu, 5 Aug 2021 17:14:22 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E8DEF548005; Fri, 6 Aug 2021 02:14:16 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id DF91B4E7C55; Fri, 6 Aug 2021 02:14:16 +0200 (CEST)
Date: Fri, 6 Aug 2021 02:14:16 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Christian Huitema <huitema@huitema.net>
Cc: Richard Barnes <rlb@ipv.sx>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20210806001416.GJ57091@faui48e.informatik.uni-erlangen.de>
References: <20210805204355.GB57091@faui48e.informatik.uni-erlangen.de> <491413A8-E420-49AA-AA0D-1494C29F20C8@akamai.com> <20210805213523.GD57091@faui48e.informatik.uni-erlangen.de> <CABcZeBMENb1bvgtWG7o180NM2Pm43qkFBNe9kRv3F4A49k21tg@mail.gmail.com> <20210805225244.GE57091@faui48e.informatik.uni-erlangen.de> <CABcZeBMbfQdKi2cOFip5o4CFfGEtFKDSKJM=Zvt6=0cZWXqb4w@mail.gmail.com> <20210805231102.GF57091@faui48e.informatik.uni-erlangen.de> <CAL02cgQnJYCthmnX6j0U8dCjE1fJZX2Kf9MAE3-k06Tcgqh=2g@mail.gmail.com> <4edb7050-2e05-ebef-12c7-cde8471dc94d@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4edb7050-2e05-ebef-12c7-cde8471dc94d@huitema.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JOSM5gyzjsOOIoFgStoxAc5XxtY>
Subject: Re: [TLS] RFC8446 backward compatibility question
X-BeenThere: tls@ietf.org
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." <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: Fri, 06 Aug 2021 00:14:28 -0000

RFC9001/4.2:
  "Clients MUST NOT offer TLS versions older than 1.3. A badly configured TLS implementation could negotiate TLS 1.2 or another older version of TLS. An endpoint MUST terminate the connection if a version of TLS older than 1.3 is negotiated"

At least demultiplexing between HTTP TLS and QUIC TLS implementations
should be an challenge due to encap differences. Sharing a single
implementation maybe a bit more advanced if TLS/TCP should support
1.2.

Cheers
   Toerless


On Thu, Aug 05, 2021 at 04:58:54PM -0700, Christian Huitema wrote:
> Also, it depends whether the application is HTTP or something else. QUIC
> makes an explicit reference to version 1.3. AFAIK, several implementations
> of QUIC use stacks that just implement 1.3, no attempts at backward
> compatibility whatsoever.
> 
> -- Christian Huitema
> 
> On 8/5/2021 4:15 PM, Richard Barnes wrote:
> > I’m not aware of any spec (at least in the IETF) that mandates support for
> > prior versions.  Are you?
> > 
> > My point being that there is a pretty universal default assumption that no
> > such requirement exists.  No different for TLS, and thus no need to explain
> > when that’s the case.
> > 
> > —Richard
> > 
> > On Thu, Aug 5, 2021 at 13:12 Toerless Eckert <tte@cs.fau.de> wrote:
> > 
> > > Sure, i like playing TLS cluedo ;-)
> > > 
> > > But for uneducated readers, i was thinking more about text that uplevels
> > > to the operational
> > > aspect of interoperability:
> > > 
> > >    All (curent) TLS versions can negotiate to lower versions, but
> > >    no version specification mandates actual support for such a lower
> > > version.
> > > 
> > >    In result: to ensure interoperability with a peer of version 1.x,
> > >    it is not sufficient to support 1.y, where y > x, but an implementation
> > >    must explicitly also have support for 1.x.
> > > 
> > > Btw: pretty sure that if i go back to my domain (IP Multicast for example),
> > > our text will likely not be any better, but TLS just has the biggest
> > > interest
> > > surface so it makes most sense to encourage authors to write the most
> > > easily
> > > read text.
> > > 
> > > Cheers
> > >      Toerless
> > > 
> > > 
> > > On Thu, Aug 05, 2021 at 03:57:07PM -0700, Eric Rescorla wrote:
> > > > On Thu, Aug 5, 2021 at 3:52 PM Toerless Eckert <tte@cs.fau.de> wrote:
> > > > 
> > > > > Another way to educate what you may consider to be "non-core"
> > > readership,
> > > > > is maybe some form of "TLS operational considerations". Your prior
> > > answer
> > > > > about that TLS server cluster consideration would also nicely fit into
> > > > > something like that. Maybe something for opsec wg..
> > > > > 
> > > > This is in the next section:
> > > > https://tools.ietf.org/rfcmarkup?doc=8446#appendix-D.3
> > > > 
> > > > -Ekr
> > > > 
> > > > 
> > > > 
> > > > > Cheers
> > > > >      Toerless
> > > > > 
> > > > > (*) Not sure about the number. Could have been egyption or chinese
> > > history
> > > > > ;-)
> > > > > 
> > > > > 
> > > > > On Thu, Aug 05, 2021 at 03:23:42PM -0700, Eric Rescorla wrote:
> > > > > > On Thu, Aug 5, 2021 at 2:37 PM Toerless Eckert <tte@cs.fau.de>
> > > wrote:
> > > > > > > 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
> > > > > > 
> > > > > > That's correct.
> > > > > > 
> > > > > > 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.
> > > > > > > 
> > > > > > TBH, I think this is pretty clear in the document. We don't generally
> > > > > expect
> > > > > > that support for version X includes support for version X-1.
> > > Moreover,
> > > > > there
> > > > > > is text in the document which doesn't make much sense if you couldn't
> > > > > > just have a TLS 1.3 stack:
> > > > > > 
> > > > > >   This document defines TLS version 1.3.  While TLS 1.3 is not
> > > directly
> > > > > >    compatible with previous versions, all versions of TLS incorporate
> > > a
> > > > > >    versioning mechanism which allows clients and servers to
> > > > > >    interoperably negotiate a common version if one is supported by
> > > both
> > > > > >    peers.
> > > > > > 
> > > > > > 
> > > > > > Or
> > > > > > 
> > > > > >    TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627
> > > > > > <https://tools.ietf.org/rfcmarkup?rfc=7627>]
> > > > > >     extension which digested large parts of the handshake transcript
> > > into
> > > > > >     the master secret.  Because TLS 1.3 always hashes in the
> > > transcript
> > > > > >     up to the server Finished, implementations which support both TLS
> > > 1.3
> > > > > >     and earlier versions SHOULD indicate the use of the Extended
> > > Master
> > > > > >     Secret extension in their APIs whenever TLS 1.3 is used.
> > > > > > 
> > > > > > -Ekr
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 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".
> > > > > > > 
> > > > > > > Cheers
> > > > > > >      Toerless
> > > > > > > 
> > > > > > > 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.
> > > > > > > > 
> > > > > > > --
> > > > > > > ---
> > > > > > > tte@cs.fau.de
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > TLS mailing list
> > > > > > > TLS@ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/tls
> > > > > > > 
> > > > > --
> > > > > ---
> > > > > tte@cs.fau.de
> > > > > 
> > > --
> > > ---
> > > tte@cs.fau.de
> > > 
> > > _______________________________________________
> > > TLS mailing list
> > > TLS@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tls
> > > 
> > 
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls

-- 
---
tte@cs.fau.de