[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Fri, 06 December 2024 17:31 UTC

Return-Path: <muhammad_usama.sardar@tu-dresden.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 3C888C14F6F3 for <tls@ietfa.amsl.com>; Fri, 6 Dec 2024 09:31:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tu-dresden.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-leZPKb0msQ for <tls@ietfa.amsl.com>; Fri, 6 Dec 2024 09:31:36 -0800 (PST)
Received: from mailout3.zih.tu-dresden.de (mailout3.zih.tu-dresden.de [141.30.67.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A53DC14F6EE for <tls@ietf.org>; Fri, 6 Dec 2024 09:31:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=Content-Type:In-Reply-To:From:References:To: Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WGj2wVtpOsGHkEaBI4Iq9nR1k1LngEY8CuM/9ySsuIE=; b=LRhE689vUJEQbTG8hk7U1/1Ldy 5gl490J1rHgOE4uPP+VjABaF/VNg83VV2QngEELD0uhpIayR91l5oz5bVHyMdCVPNsqwrOHB8r4BN 7hF1raC3sSBnbFsjQzmX2ijHfuX+Vp4caaBoaga5Mko9hLvQpKcQsDnCfSNSb4GJathajZ0gL3WUu u9ppkoJ7KDSKUkixOhYFGsWwqZje8OYIdtgLbLQm+/di+4uc3UJovz6JE5yPnf86lvSto0BRQRp/b 86QSCW0Q/mRyLzBV6ATpSiShY+XSJH0rgBwfV8uDhMuOhFx582V5nlfpG9PLZV397ENlpPjbfIjZ+ PjfRJ7Pg==;
Received: from [172.26.35.139] (helo=msx.tu-dresden.de) by mailout3.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <muhammad_usama.sardar@tu-dresden.de>) id 1tJcAu-00175A-Ft; Fri, 06 Dec 2024 18:31:32 +0100
Received: from [192.168.1.2] (92.224.186.156) by msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:31:27 +0100
Message-ID: <cc74d2fa-c452-4267-900f-41dee05dd9c6@tu-dresden.de>
Date: Fri, 06 Dec 2024 18:31:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Valery Smyslov <smyslov.ietf@gmail.com>, 'Sean Turner' <sean@sn3rd.com>, 'TLS List' <tls@ietf.org>
References: <F98C87B7-B31D-4702-B694-0CB1A8FB38C5@sn3rd.com> <07fa01db461a$b2f05330$18d0f990$@gmail.com>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <07fa01db461a$b2f05330$18d0f990$@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms080408090501010102070807"
X-ClientProxiedBy: msx-l317.msx.ad.zih.tu-dresden.de (172.26.34.117) To msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139)
X-TUD-Virus-Scanned: mailout3.zih.tu-dresden.de
Message-ID-Hash: VIDJEZKIJYPETBLPXMYXFBUESGQX6ZOZ
X-Message-ID-Hash: VIDJEZKIJYPETBLPXMYXFBUESGQX6ZOZ
X-MailFrom: muhammad_usama.sardar@tu-dresden.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/6QoaLDE3_2UQTcawV2QQznQ5Pbs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

A few quick questions. Sorry if I am missing something obvious or some 
background.

On 04.12.24 08:04, Valery Smyslov wrote:
> note, that UTA WG has issued a WGLC for draft-ietf-uta-require-tls13-02 (New Protocols Must Require TLS 1.3) [1].
>
>   [1]https://datatracker.ietf.org/doc/draft-ietf-uta-require-tls13/
Thanks for pointer to this. It looks like a more detailed version of 
tls12-frozen draft. Is there a good reason not to merge the two 
documents? Is it due to different WGs? or different intended status? or 
something else?


On 04.12.24 10:36, John Mattsson wrote:
>
> as-is, TLS 1.3 does not provide excellent security for long-term 
> connections.
>
Do we have an I-D which defines /how long/ do we consider as long-term 
connections? or I-D which gives recommendations or best practices for 
/how long /do we consider TLS 1.3 to provide excellent security?

---

Considering the following two statements in I-D, I have two questions:

>   For TLS it is important to note that the focus of these efforts is
>   TLS 1.3 or later.  Put bluntly, post-quantum cryptography for TLS 1.2
>   WILL NOT be supported.

To me the two sentences are contradicting. Which one of the following is 
intended?

 1. (My understanding from 1st sentence) Some PQC support for TLS 1.2
    will still continue but it will not be the focus.
 2. (My understanding from 2nd sentence) We will exclusively work on PQC
    for TLS 1.3 or later.

What does the capitalization of WILL NOT mean? I did not find any such 
capitalization in RFC 2119 and RFC 8174. Please add the relevant RFC in 
section 2 or define it.

>   This
>   document specifies that outside of urgent security fixes, no new
>   features will be approved for TLS 1.2.

If the intention of draft was #2 above, cross-reading with this 
sentence, are we implying that PQC is not an urgent security issue?