[TLS] Re: Opsdir last call review of draft-ietf-tls-rfc8447bis-11

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Wed, 16 April 2025 14:26 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 668E61D0665B; Wed, 16 Apr 2025 07:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuRVuR3za4Bv; Wed, 16 Apr 2025 07:26:57 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 189381D06654; Wed, 16 Apr 2025 07:26:57 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Zd3CN1wLSz6D9SP; Wed, 16 Apr 2025 22:22:56 +0800 (CST)
Received: from frapeml100007.china.huawei.com (unknown [7.182.85.133]) by mail.maildlp.com (Postfix) with ESMTPS id 52B811402F4; Wed, 16 Apr 2025 22:26:55 +0800 (CST)
Received: from frapeml500006.china.huawei.com (7.182.85.219) by frapeml100007.china.huawei.com (7.182.85.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 16 Apr 2025 16:26:55 +0200
Received: from frapeml500006.china.huawei.com ([7.182.85.219]) by frapeml500006.china.huawei.com ([7.182.85.219]) with mapi id 15.01.2507.039; Wed, 16 Apr 2025 16:26:55 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Sean Turner <sean@sn3rd.com>
Thread-Topic: Opsdir last call review of draft-ietf-tls-rfc8447bis-11
Thread-Index: AQHbqvw3Xh/d0UkR0UW6Z2NHYk6TebOmT0Eg
Date: Wed, 16 Apr 2025 14:26:55 +0000
Message-ID: <e0547f3b789b43ad98d16727ed30f0b2@huawei.com>
References: <174369205715.2732618.18280102439496098010@dt-datatracker-5b9b68c5b6-zxk6z> <C5410CED-DC24-4CEF-BD1D-649ECFAD5FF8@sn3rd.com>
In-Reply-To: <C5410CED-DC24-4CEF-BD1D-649ECFAD5FF8@sn3rd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.41.84]
Content-Type: multipart/alternative; boundary="_000_e0547f3b789b43ad98d16727ed30f0b2huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: VJAUE6XWL4GKDGSO7OFPG3LPFXAPHV7F
X-Message-ID-Hash: VJAUE6XWL4GKDGSO7OFPG3LPFXAPHV7F
X-MailFrom: giuseppe.fioccola@huawei.com
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
CC: "ops-dir@ietf.org" <ops-dir@ietf.org>, "draft-ietf-tls-rfc8447bis.all@ietf.org" <draft-ietf-tls-rfc8447bis.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, TLS List <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Opsdir last call review of draft-ietf-tls-rfc8447bis-11
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/OZAUlVOGvVmPlw4gFjq56wD3uBY>
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>

Hi Sean,
Thank you for considering my comments.
The proposed changes are ok for me.
I’m also ok with the last points given that these are only suggestions.

Regards,

Giuseppe

From: Sean Turner <sean@sn3rd.com>
Sent: Friday, April 11, 2025 6:10 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: ops-dir@ietf.org; draft-ietf-tls-rfc8447bis.all@ietf.org; last-call@ietf.org; TLS List <tls@ietf.org>
Subject: Re: Opsdir last call review of draft-ietf-tls-rfc8447bis-11


On Apr 3, 2025, at 10:54 AM, Giuseppe Fioccola via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:

Reviewer: Giuseppe Fioccola
Review result: Has Nits

This document updates the changes in RFC 8447 and requests IANA to make changes
to a number of TLS and DTLS registries. In particular, it updates the
"Recommended" column in TLS registries by defining a third value "D" for items
that are discouraged and adds a "Comment" column to the registries that do not
already have it. This document updates several RFCs: RFC 3749, RFC 5077, RFC
4680, RFC 5246, RFC 5705, RFC 5878, RFC 6520, RFC 7301, and RFC 8447.

I think that the document has a well defined scope and is quite clear. However,
I have few suggestions:

- In the Abstract, I suggest to replace 'adds a Comments column to all active
registries' with 'adds a Comment column to all the registries that do not
already have it'.

Done via:
https://github.com/tlswg/rfc8447bis/pull/76


- In section 3, I suggest to replace 'The permitted values are' with 'The
permitted values of the Recommended column are', just to avoid any confusion.

Done via:
https://github.com/tlswg/rfc8447bis/pull/76


- In the sections from 4 to 14, I suggest to add some explanation on why
specific registries are changed to discouraged. Some insight would help the
reader.

We had other comments along these lines. I went through and looked at whether there were links to the drafts that gave info on why D; see https://github.com/tlswg/rfc8447bis/pull/74. Mostly, we added a ref back to this document which includes the info.


- I would also add some observations on the operational and interoperability
impacts, if any, of the changes proposed in the document.

- Currently, the section on "IANA Considerations" simply says that the document
is entirely about changes to TLS-related IANA registries, as per RFC 8447.
Instead, I would put all the relevant sections on IANA requests (i.e. sections
from 4 to 14) under an "IANA Considerations" section. In this way you can avoid
the IANA section with no content.

On these, two we’ll take them under advisement. On the ops and inerop impacts, I am not sure there is much more to say beyond hey make sure your implementation is updatable and configurable. On the last point, we could do that, but this draft has been in this format for 4 years and RFC 8447 before it has the same format.

Cheers,
spt