Re: [TLS] RFC8446 backward compatibility question

Eric Rescorla <ekr@rtfm.com> Thu, 05 August 2021 22:24 UTC

Return-Path: <ekr@rtfm.com>
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 759E43A09AC for <tls@ietfa.amsl.com>; Thu, 5 Aug 2021 15:24:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 d6_g93WGtGJ0 for <tls@ietfa.amsl.com>; Thu, 5 Aug 2021 15:24:24 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75303A0BC6 for <tls@ietf.org>; Thu, 5 Aug 2021 15:24:24 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id 188so7066689ioa.8 for <tls@ietf.org>; Thu, 05 Aug 2021 15:24:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kirjVEXFaqHp7kuzBQ9QVxHrhPzn1jW39q0aUKrzBSU=; b=dhUsFQshA5TBurHADj6wDC1zvN2167p4CEO6zxCsNl2VabDlX7aoQsdlmW1wx8zFAd /I97W4KIz57Oi+JHm4JzeA0LUEU20b5T0Jcw3xpjh37D+Fp7ONH7AxgocGr/mzuGqzRS Ljs0o00+BoyXo0HMTdjBjKqXIQar8wPkFHlqiyKfs/N2A2xpwo2n5oOUOSA0m6b4GoZ5 QvdDhsjz/TT1WJ1NEZ7aJLNdCOWRmJ+1B+H5IlCulnes5N5oRoQ6CPgyK3JLlI02eBkf IKRuryXd3bXuvSWSnYoOuqxSGXejmppPA3AeomrPlB2THjAoBBNq+t62RgQxOWtZhk1j p63Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kirjVEXFaqHp7kuzBQ9QVxHrhPzn1jW39q0aUKrzBSU=; b=cRgAQWBKlGiKYxbZtuJSgUhHBx7XEcIfxx6YLdQhOxddAb1rsKU6kWtch0kvvW3f7i TcSteaV54AQcCLvfKc/9UVYP1VDi7PuTlJGxP3WIylbG640N0EJLW6p5rkHsnnm6ohOs jIAGz+hNzxk9y/gPTLtn/3hDPX42r6N0qMJpcfBI/TcEGM8WkR8BHdIDLWIQM4lW6q7S vXAkwmalPk4s2RgzMHVvawv6nnMiUhEb3SjBvRUYV7o+0Z31g3fEyE1c/vTPQ66rr6Op EgK7o5sOwhOOIalhUMjEfKgpjbXmUN4CaIr/4twQ04FqbeV2d5mTGIAzIi7QKRxYo5IT YACw==
X-Gm-Message-State: AOAM531BqjQVZmQJTztaROTdP6rrihlGw+WJfw1mHAA0QSDFbIkEqldx 9gGN/0o5+mLF03Dxqs5M3/xNJpdbdbdkk/+Hz+uqYw==
X-Google-Smtp-Source: ABdhPJxIpcEP3Oi+VHTN++BpqtP1GnphI2sFVKH96kPoUJ6Adq13ju+fst6FrUr4c02+vMqdmQK6KvjgrRtmkgeWdcs=
X-Received: by 2002:a05:6602:2812:: with SMTP id d18mr109978ioe.98.1628202258977; Thu, 05 Aug 2021 15:24:18 -0700 (PDT)
MIME-Version: 1.0
References: <20210805204355.GB57091@faui48e.informatik.uni-erlangen.de> <491413A8-E420-49AA-AA0D-1494C29F20C8@akamai.com> <20210805213523.GD57091@faui48e.informatik.uni-erlangen.de>
In-Reply-To: <20210805213523.GD57091@faui48e.informatik.uni-erlangen.de>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 5 Aug 2021 15:23:42 -0700
Message-ID: <CABcZeBMENb1bvgtWG7o180NM2Pm43qkFBNe9kRv3F4A49k21tg@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000044eddc05c8d761cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ltLnRzZ_1res-760WqTRdX3VLWQ>
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: Thu, 05 Aug 2021 22:24:30 -0000

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
>