Re: [TLS] RFC8446 backward compatibility question

Eric Rescorla <ekr@rtfm.com> Thu, 05 August 2021 21:26 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 E6DB13A0AB4 for <tls@ietfa.amsl.com>; Thu, 5 Aug 2021 14:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=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 DUChQA8-i_zF for <tls@ietfa.amsl.com>; Thu, 5 Aug 2021 14:26:51 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 477AF3A0AB1 for <tls@ietf.org>; Thu, 5 Aug 2021 14:26:51 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id f11so8561133ioj.3 for <tls@ietf.org>; Thu, 05 Aug 2021 14:26:51 -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=S4ga730wBUHpA2+Ehwxjf6akO+twQ8fT5Xfs2NliBMY=; b=JrMaOgeGcFo/YFPmZFcPh/Bzvxe8Yxo09sh6I0pn0hsy9WrbGS0A0+5DQ2GdRKvQuX SxVkAipW7qin91VI2/g5+40dAgXEUs8wehfoco9zUsusYoDKKCF/pIj+AU3+XJql1qhD g5EhbGRslR0c7qfz9uahG4GuqREJwsu1eGiXGS/HKhzUpljIZuARlTq6JrdOK4IZrsVT u5NeTlrsXF3PQkOahaoM8GkOjw3i2pwBo9xgz8oOdphIe40xXteojPe0QNodIqKz7oNT 9cTtAojY5U5DipLYiUQT2FmdoMqL/OjARhY3VBeol1wxEP7DbOHuqc+nTs8Z3CrXpoTX 6Dfw==
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=S4ga730wBUHpA2+Ehwxjf6akO+twQ8fT5Xfs2NliBMY=; b=rIFnw9e73I8A/9z56WRsYWKhROU9vWuPSdOx+xRWzwOw0/J/zRRa/EIOU4IATMIeUJ spAuUnzfWpexI3ZgVpRdnYJOysSLlPN8ZtpY8lXjgBa/BBKxQeV/E6nBVrltlS56iJ4l G+cVfs/D+Cn2Tc4RO7DmE5YV7WKnX1t+uz/bRTm83akMv7/gdfhl/CX2yXUfszhp+6Cv vuzOVFTTTQNQWnJ8Clqd3RdVwwOSR1gjQqLp0wxY2dVyPD8qnbyuyaBmngJWTmNy+Lfk fGOfKc2m648AUCnHXM0vs67BHhbve65yvBZ1vCSExfFePKmiE8ZobuJ0VhO2xA87mzwI BW9Q==
X-Gm-Message-State: AOAM533yiFcMigXVzFaLr7tjFTiQQ3zrLnqEstnssoAtiMqGJNxNZ70e dFeqG9/648S/u+QnefTBXBcFF4IWxrOO+NBf2ss22w==
X-Google-Smtp-Source: ABdhPJzERIOzY5qJT2zcP4fFr7TLksI7gbSjdrz9VmnklLnYCBXSXLK5rmYRvdqGRSXgcJtwf1ZENUNTgSTJtNcNqg8=
X-Received: by 2002:a05:6602:14cb:: with SMTP id b11mr611327iow.48.1628198809898; Thu, 05 Aug 2021 14:26:49 -0700 (PDT)
MIME-Version: 1.0
References: <20210805204355.GB57091@faui48e.informatik.uni-erlangen.de> <491413A8-E420-49AA-AA0D-1494C29F20C8@akamai.com>
In-Reply-To: <491413A8-E420-49AA-AA0D-1494C29F20C8@akamai.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 5 Aug 2021 14:26:13 -0700
Message-ID: <CABcZeBMcF6FLwwHohcZ+n9eJow6nVGg+THaUg8RTiwjZFtnK2g@mail.gmail.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Cc: Toerless Eckert <tte@cs.fau.de>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b02a3305c8d69371"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CiFiQGBpot-sWnodgbyAHcKFjuk>
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 21:26:56 -0000

FWIW, the situation Rich outlines has been true for all prior versions of
TLS as well; it's just that TLS 1.3 is so different that there's a lot more
advantage to doing TLS 1.3 only than (say) doing TLS 1.2 but not TLS 1.1.

This isn't the question asked, but for the most part, ClientHellos
generated by stacks which support both TLS 1.3 and TLS 1.2 will be
compatible with unmodified TLS 1.2 servers, thus allowing for clients to
upgrade even when servers have not.

The exception is that if a TLS 1.3 client is attempting 0-RTT (which it can
only do if it has already successfully connected with TLS 1.3 to the
server), then this is not compatible with TLS 1.2. Thus, if you have
multiple servers associated with a given address you need to ensure that
they all speak TLS 1.3 prior to advertising 0-RTT. It is safe, however to
upgrade only some of them to TLS 1.3 as long as you do not advertise 0-RTT
because the ClientHello will still be TLS 1.2 compatible.

-Ekr


On Thu, Aug 5, 2021 at 2:17 PM Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>
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.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>