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

"Soni L." <fakedme+tls@gmail.com> Thu, 24 June 2021 15:21 UTC

Return-Path: <fakedme+tls@gmail.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 BD5DF3A2053 for <tls@ietfa.amsl.com>; Thu, 24 Jun 2021 08:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.435
X-Spam-Level:
X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nOHTy70rHhHC for <tls@ietfa.amsl.com>; Thu, 24 Jun 2021 08:20:58 -0700 (PDT)
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 839F93A2051 for <tls@ietf.org>; Thu, 24 Jun 2021 08:20:58 -0700 (PDT)
Received: by mail-qv1-xf36.google.com with SMTP id j6so2877034qvp.3 for <tls@ietf.org>; Thu, 24 Jun 2021 08:20:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=zSgd3jc7Bh9KSFLNR2oE0CvINtNypw66zw/EUYELU5k=; b=jlUP51LCnbCccVYui0g58OgGfOzO7GYEd37OYJ/mhl34j5lNg7xwttxTe5uk9bSFLx U0umJzUAmZUgY8TOhODu/NFAsKhKD66HYHFpQaxEevokjuxGTH/dd161wjqpL/o2eae3 wJNs+GkzanpmsWUwkzqCcF6OSnGpF6jDdglTfZO/l8Mz9eCnLJTy4/AEMDxUvHWhdpHp 3zkQksuS59GPciRwjCQR93kWsVEvFIP5VIWyNGzoUidCrw/JQWD2T095S3fMeNTCFpU+ 1EwduT7K5jZWjCLT2gnSlCAiRINxiVJYhL8c0LRY8Bvt/eJekBmunIwWAIw16cRqF7WM l01Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=zSgd3jc7Bh9KSFLNR2oE0CvINtNypw66zw/EUYELU5k=; b=n6ndDnIaUnp+6jiM0U9RmJz0A/ng0fD8UzEc0/7d88GJxhQ9XIS3DrTkEdOYl78vSt CjYuiH/7q1UwhNcxuMmclhx8xLH59a6xrgFIIGOQb/opx6OsR96FZMQAjsBCuEPuICfX btUdAOluL/hUOKwKOBSWUJFkfQjAiwWDKXOTuWOV5idSEVhflLrviyYkxBlRnxoIyiY7 XmyZvOIqaGt3uaJZDdYHwwZWgglgp8J9k2qQ+QHUuDuH4svF6XsVvlaxGKcMwm6lHYe5 +nl3xTI0c/9GPT4T1Tt6779q2nTsXkGaPBxyploTCR6x+9YhVseH/i+JXxFz4v37PUgK +z2Q==
X-Gm-Message-State: AOAM533eURl74H7r1LJXj+3J1xusi+ZlgUqJbAb4L/pvJpvOZTaZQAVP DsZGmSCe1/nqhKG1yRJcTLKb6wyvLMk=
X-Google-Smtp-Source: ABdhPJyZ5M2dY+A80EZxc5YwIbS5qlGzzFpt6eVoMc6MNOFnyrKrQRyv+f4qLnwAN37T/7vH5tF3og==
X-Received: by 2002:ad4:41ce:: with SMTP id a14mr5847715qvq.56.1624548056978; Thu, 24 Jun 2021 08:20:56 -0700 (PDT)
Received: from ?IPv6:2804:431:d77d:610a::536f:6e69? ([2804:431:d77d:610a::536f:6e69]) by smtp.googlemail.com with ESMTPSA id k1sm2092593qtm.49.2021.06.24.08.20.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Jun 2021 08:20:56 -0700 (PDT)
Sender: "Soni L." <fakedme@gmail.com>
To: David Benjamin <davidben@chromium.org>
Cc: tls@ietf.org
References: <3121bfd7-c6cb-4af3-4780-32a9a5b25d8b@gmail.com> <CAF8qwaARRC5HXwWinAL78rZyR-OA_wxr4whu3ibKiiv8FF5ZqQ@mail.gmail.com>
From: "Soni L." <fakedme+tls@gmail.com>
Message-ID: <4872994f-d332-6da8-ec28-c4882ea08256@gmail.com>
Date: Thu, 24 Jun 2021 12:20:52 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <CAF8qwaARRC5HXwWinAL78rZyR-OA_wxr4whu3ibKiiv8FF5ZqQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------9F4EAE932237F229F3437C86"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/H9rMzr45QxX6sJ-vT5fbvOji9B8>
Subject: Re: [TLS] Upgrading TLS session resumption from TLS 1.2 to TLS 1.3?
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, 24 Jun 2021 15:21:03 -0000

Ah, okay. That's unfortunate, tho, resumption upgrades would be useful
with TLS-SRP, to get the benefits TLS 1.3 brings without having to
update login details.

Thanks tho.

On 2021-06-24 12:11 p.m., David Benjamin wrote:
> 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 extension.
>
> 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.
>
> David
>
> On Thu, Jun 24, 2021 at 8:50 AM Soni L. <fakedme+tls@gmail.com
> <mailto:fakedme%2Btls@gmail.com>> 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
>     TLS@ietf.org <mailto:TLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tls
>     <https://www.ietf.org/mailman/listinfo/tls>
>