[TLS] AD review draft-ietf-tls-rfc8447bis-10

Paul Wouters <paul.wouters@aiven.io> Fri, 07 March 2025 02:33 UTC

Return-Path: <paul.wouters@aiven.io>
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 0CEFB8A390B for <tls@mail2.ietf.org>; Thu, 6 Mar 2025 18:33:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io
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 27X73je9PL4a for <tls@mail2.ietf.org>; Thu, 6 Mar 2025 18:33:58 -0800 (PST)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id F31C08A38FC for <tls@ietf.org>; Thu, 6 Mar 2025 18:33:57 -0800 (PST)
Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-abbd96bef64so203902966b.3 for <tls@ietf.org>; Thu, 06 Mar 2025 18:33:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; t=1741314837; x=1741919637; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=udCsqtDtnV03evpKX73n/XsjzLWYojzooznBdQwjE+s=; b=f00mnwMee8AllMmRZj5kWivSb0z7MDWTAiLZxCrsIl4hAYUnF6pWtk5LmqZDAgL3Tz vmm6q2E7tKQaDGYBeg3f/sOODhsq9b+SDT4XJVA/NiNbih7ORqP5Vj1kHu6krb8YwrLc 62R70VgF/7VLbhu7UL+xjBttoHlWBeorHSb0w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741314837; x=1741919637; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=udCsqtDtnV03evpKX73n/XsjzLWYojzooznBdQwjE+s=; b=Am+wVD1HeHzZl5by8xrgLq0mH9GjtJrpPkvW1phZDoFCHCOMfUP3W+A2kjsMgIERAT vwj/Q35VY92/QPdjXP+PUbMbyrIRUVVyOUFYoeSMeG/aEZq6IIeYUtwNqPCcHAOXVeTC muOAzztXayx4vV/LConwllS0Rj9fXO+v4LkdlDkupMbj+t5hiQuEAOCm2CIXGGbwhICu etjN9Y7UzE//m2QQ4MBGb3wXgyM08Pq4/SgaCxcKjWHkOJv0JiKPfuz5L20AS7TIqIBG OT+IunYehQhuSOHqhF2izRibJ3iAWRxRb3Fk1s2Jzb2XxeVt6RotkBxIVoBqpOC1Qa/b 3KOQ==
X-Gm-Message-State: AOJu0Yw2ODZ5tP6/rylP+P1N0qEIrrjDhI41CdQEwXsCbvLhsGd3Vu3h s4qmnoTDsV9Tjyh7ogz/R/tuoIlWDnXFFy3F/8G0G7sFGprnlByq/Pr4qoBMHkJR+aZZqF1dcTT leIdVPr7IrWUvfzLz5BekMUC4Fvk9piT5wTCZ6Ls/a29KflZCpbU=
X-Gm-Gg: ASbGncs/rt4AwvuNDe4rqWm01i+embaTHN3VwklfX4X/AlxKFfJs8kEI/HclDd/jSpL JrTk1XAeex8sNSfgFQBk0TnaNvKyiZI5Epvi3tH5btejSHkHewxZJZPN4lIv01K0o//ZuM9BWRr 3V4kVgtoh8Dxyx0Y82jhoD3wsv
X-Google-Smtp-Source: AGHT+IHsMpPYwJYGnI5NSe/2tKxkk9lgG1l3DN6H34gbjRhPdNOZNRCNbkQByafjvmfwFnxTCmKUciEFG1MrwqtyquY=
X-Received: by 2002:a17:907:980d:b0:abf:7a26:c46a with SMTP id a640c23a62f3a-ac252edb844mr166202766b.50.1741314836798; Thu, 06 Mar 2025 18:33:56 -0800 (PST)
MIME-Version: 1.0
From: Paul Wouters <paul.wouters@aiven.io>
Date: Thu, 06 Mar 2025 21:33:45 -0500
X-Gm-Features: AQ5f1Jqundf8cTzIu3Ue1R0qDC2evMMJoHAsprNkCoSzb5LjliPZPee3hC8Nk90
Message-ID: <CAGL5yWZy1xXLTVGhj3s_gNCoph_3XcShO7DWm=aDsYR1ySvY6g@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004aa128062fb774cd"
Message-ID-Hash: IJFZ6DRJYJP5N47PILCGYKSL4FOZR26Y
X-Message-ID-Hash: IJFZ6DRJYJP5N47PILCGYKSL4FOZR26Y
X-MailFrom: paul.wouters@aiven.io
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] AD review draft-ietf-tls-rfc8447bis-10
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/j6AZwUXiGm9-Et5fwJVLBhuThQ8>
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>

AD review of draft-ietf-tls-rfc8447bis-10

I have some comments and small change requests. Do let me know if I got it
wrong.


Section 3

        Setting a value to "Y" or "D" in the "Recommended" column requires
        IETF Standards Action [RFC8126]. Any state transition to or from a
        "Y" or "D" value requires IESG Approval.

Isn't this easier written as:

        Setting a value to "Y" or "D" in the "Recommended" column requires
        IETF Standards Action [RFC8126] or IESG Approval.

This appears in a number of sections in the document.

Section 4 TLS ExtensionType Values

        Values with the first byte in the range 0-254 (decimal) are
        assigned via Specification Required [RFC8126].  Values with the
        first byte 255 (decimal) are reserved for Private Use [RFC8126].

I'd rather not let IANA figure out decimal network order byte math. Or
require everyone to do that math when checking the registry. Why not:

        Values in the range 0-65279 are assigned via Specification Required
        [RFC8126]. Values in the range 65280-65535 are reserved for Private
        Use [RFC8126].

Also, this is not true for:

        65281   renegotiation_info

which is clearly not usable for Private Use. Maybe it makes sense to say:

        Values in the range 0-65279 are assigned via Specification Required
        [RFC8126]. Values in the range 65280-65295 are Reserved. Values in
        the range 65296-65535 are reserved for Private Use [RFC8126].

This then leaves 0xff00-0xff0f for whatever the reason for 65281 was to be
able to happen a few more times, and keep the private range valid without
strange exceptions.

Section 5  TLS Cipher Suites Registry

This section contains some reasoning why it is Discouraging things. The
current
IANA registry also contains such reasoning on the form of notes, but this
section
does not add to the notes. So now this inforation is splintered between RFC
and
Registry. I think the easiest fix is to add these few reasons specified here
as Note: to the IANA registry.


Note that this registry states:

        When this registry is modified, the YANG module
        "iana-tls-cipher-suite-algs" [iana-tls-cipher-suite-algs] must
        be updated as defined in [RFC9645].

Has this happened or is it scheduled? If so who is the contact I can follow
up with?


Section 6 TLS Supported Groups

        * Replace the registry range table note column for the 0-255,
          512-65535 range with "Unallocated".

This makes no sense. That current line with its note reads:

        0-255, 512-65535        Specification Required  Elliptic curve
groups

I understand that the note should remove the text "Elliptic curve groups",
but it makes no sense to add "Unallocated" because the range does have
allocations in it. Maybe just instruct IANA to remove the note "Elliptic
curve groups" ?


Section 11 TLS ClientCertificateTypes registry

The registry name is not "TLS ClientCertificateTypes" registry, but
"TLS ClientCertificateTypes Identifiers" registry.


Paul