Re: [TLS] Upgrading TLS session resumption from TLS 1.2 to TLS 1.3?

David Benjamin <> Thu, 24 June 2021 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 930C23A2006 for <>; Thu, 24 Jun 2021 08:11:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.448
X-Spam-Status: No, score=-9.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DyY04OE1gJL6 for <>; Thu, 24 Jun 2021 08:11:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E2B33A2003 for <>; Thu, 24 Jun 2021 08:11:49 -0700 (PDT)
Received: by with SMTP id u190so4968726pgd.8 for <>; Thu, 24 Jun 2021 08:11:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j1Eeuv3smWoNuXUvJwWSdVqpplhevb0YSajvHkDKI9w=; b=BjNHTjd8yPL5twhAAppPJUaF95Vh4tznb8OxW7XF1J9Yqd1JfemEQVTZo3OYaLvaTn w/nO59FxcwDvu2OkY638T/kIGnTuRsqhhlwW8789y+87zkFWgryMVVa+Jn6cRR2BKKrJ kjGD1ISeffYhyvC8UA/Jz8sO8zncQ/MIXtRQ8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j1Eeuv3smWoNuXUvJwWSdVqpplhevb0YSajvHkDKI9w=; b=kYpIkkN9oOjDZjeW0tdTBsW+I7vQjbMDLsFwFJ3v0JIqQkiQXUFL/iU+0VpIAAsfey D0t/A6otfY70vLpimQ/sSaWmccFuMeCkA/Kjpk9YRskmllZBWGyA6+hbKlsecp26eqm1 eWM+U7qVzpPz+EEnp5fhZn4YG0XOEhF91Deq532q1N4vwVfvD0ARQFsDO/oZZu8Ghe1l FPHX/xPnbaHSGXOyRFaOpqA7k3VMD1fpjTopH209EMsH8JCXHnF+XV6cxO5wCNAu8aoj Y2xij0vwtuGJnWLQym+ZwRw9PsoD2b4KyZ/E1Zerz5LbzWLZDtvYZGhZ5IgSTPxbqTeZ /EWA==
X-Gm-Message-State: AOAM531Cn030FTZpU7bm4Tw6P1eF1dfAMTstzRajiowDzR1zvHKFqI4X kwyaOa8gdN5qALva+2xZPWJ3aGMhuzCg7RkWFYDW
X-Google-Smtp-Source: ABdhPJxDihm6ql3byaXL0NrinANOvyVJ11Zol1SMd6NfQrmiJIcrmZ8QMaEGbop+ivQbCERylQNPMhDPfXnsD4HgAWA=
X-Received: by 2002:a62:7616:0:b029:305:f420:49cc with SMTP id r22-20020a6276160000b0290305f42049ccmr5572474pfc.51.1624547508321; Thu, 24 Jun 2021 08:11:48 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Benjamin <>
Date: Thu, 24 Jun 2021 11:11:31 -0400
Message-ID: <>
To: "Soni L." <>
Content-Type: multipart/alternative; boundary="00000000000028120305c58471a4"
Archived-At: <>
Subject: Re: [TLS] Upgrading TLS session resumption from TLS 1.2 to TLS 1.3?
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, 24 Jun 2021 15:11:55 -0000

No, resumption should happen after version negotiation, and be declined if
inconsistent. The way it works is:

1. Suppose the client previously connected to the server and received a TLS
1.2 session. It connects again. The client supports TLS 1.2 and 1.3, but
doesn't know a priori whether the server now supports TLS 1.3 server. So,
as always, it sends a ClientHello good for either version. That means, it
has TLS 1.3 extensions like supported_versions and key_shares. It probably
also has TLS 1.2 extensions like ec_point_formats. And it has the TLS 1.2
session identifier, either in the session_id field or in the session_ticket

2. The server negotiates the TLS version before anything else:

2a. If the server only supports TLS 1.2, it negotiates that and resumes the
TLS 1.2 session, as usual. This is important because it allows clients to
enable TLS 1.3 without regressing existing TLS 1.2 servers. (Of course, TLS
1.2 resumption has weaker privacy and security properties than TLS 1.3
resumption, so the client *may* eventually choose to reduce or remove TLS
1.2 resumption, but that's a separate decision from enabling TLS 1.3.)

2b. If the server supports TLS 1.3, it negotiates that. Sessions are not
resumed across versions and TLS 1.3 doesn't even use the same ClientHello
fields for session identifiers, so the server ignores it and does a full
handshake. This new connection will likely issue a new TLS 1.3 session to
the client. That should replace the TLS 1.2 session in the client's session
cache, so the next connection will resume at TLS 1.3.

This is generally the pattern with resumption. The client offers everything
it is okay with: the session, older versions, and newer versions. The
server evaluates its preferences and then only resumes if the session is
consistent with them.


On Thu, Jun 24, 2021 at 8:50 AM Soni L. <> wrote:

> What's the story on backwards compatibility between TLS 1.2 session
> resumption and TLS 1.3 session resumption? Appendix D. Backward
> Compatibility doesn't seem to say anything about it. It seems like TLS
> 1.2 session resumption is gonna keep using TLS 1.2 even if both sides
> support TLS 1.3?
> _______________________________________________
> TLS mailing list