Return-Path: 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 80D7D9F15C9 for ; Tue, 11 Mar 2025 05:53:20 -0700 (PDT) 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=sn3rd.com 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 gnRHe0-jID9i for ; Tue, 11 Mar 2025 05:53:19 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 5C0F49F15C2 for ; Tue, 11 Mar 2025 05:53:19 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id af79cd13be357-7c07b65efeeso510374585a.2 for ; Tue, 11 Mar 2025 05:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; t=1741697599; x=1742302399; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=xxFzY2VLW6biDvrqCAEFJe1HCeaMkFDt6/G0AbUWOKQ=; b=IxJJxNpnttqW4BYyCOWbAu1s1GMeMfdblwGUzU3iFL9/gJNYXujHbhBprs6muFDilN u/nsl+JYS19JuVqg+ihiRVQJopIuqF8IM6+5HQx5451nAMDYLvHP8NtvihJ0c74oYPbS XAVnctffV1Rya3Mx2W7dCXWDjcqm4R4I/Cdio= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741697599; x=1742302399; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xxFzY2VLW6biDvrqCAEFJe1HCeaMkFDt6/G0AbUWOKQ=; b=oLrJyPxkn7T4Y36jM2+vrkdWf/f61mAqKE/uZ/U2lKiEQmNeCoCzt7/e2y7QvspnrL yHpDK3bU0HugE2RIccCF7DbOtVBynOQB2xkR3wb62+xba4egddmWeDxCZUtuHG6ChPzH ziMDpsaYqsLkRmSDlPoZ3GctjNtZ0lgdOH0NNrAucfDjS/68NDxcLQmmsjvyftV1e8Ox VrQYLWkAWBDLtxne/81FnsNtSXmgRbZuqGKI2CNdEARHrfrn8CNVauf1fWEkUZfIeIWs fc/WPKR6xu/GvUdPxaBr0fE9u6sXwYZxbIzCZyF/hCJz6qH1oP58bkyf4I9BIIFuYT5s Afsg== X-Gm-Message-State: AOJu0YxQ72CYlIZaKJbDgL+t4XJQizjc/gAyvOHCNOHXpnYSzWirzmm9 oe4/YS1CvgllUoJdR2H5csUbBSWyDMeZvS7tN8x7nVgJA6NOOZKMKJxWyjYEZP7JDOH0E0yoE0f a X-Gm-Gg: ASbGncs6E20WjXtsIQQ1bOtWJ52ezkF/aSqSc5xFgzgBqlzAGiOF1+mq7B6H4m47MHF ILF8EdiAB9XiQyEYCAPpGHgz0h2puvrSxPBG/f709HwIt/qP2onrMTcdLRnB61LJTyqpODMUkI0 yArd65HvwnNHDq9IGbL65r8apnv51QRyZldEu8HxFXxgDayvPrrRXQ9vhqRNwat5UNsNhkCDLFD +PbZzbZy52ZOxhcnyjFnJe0dbIm9D12dF/rJwV/L1Ju2yBZnNEljhgKT8ZoVD2QUtjhEwi7HlJD 9wAgafs9f44zNwjaVeNr83ujvai89QKfclLNOD2+f1iF69ZYpuM9OMG10u4SZwq0uSNTttc= X-Google-Smtp-Source: AGHT+IGiDwQPhgjdVd/jDoFSVQng9jtah629T3jyekmXzwN2DenBD4qBVu9Byc4CeJn5cRhpz4E7eA== X-Received: by 2002:a05:620a:1d06:b0:7c5:5003:81c5 with SMTP id af79cd13be357-7c55e93ae9amr648320585a.52.1741697598653; Tue, 11 Mar 2025 05:53:18 -0700 (PDT) Received: from smtpclient.apple ([2600:4040:252a:8d00:e509:c24a:472e:7cbb]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7c554dcbb2bsm331443885a.84.2025.03.11.05.53.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Mar 2025 05:53:17 -0700 (PDT) From: Sean Turner Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D2914D7B-1253-40BE-8EDD-133D177DB688" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Date: Tue, 11 Mar 2025 08:52:57 -0400 In-Reply-To: To: Paul Wouters References: X-Mailer: Apple Mail (2.3826.400.131.1.6) Message-ID-Hash: N5TBPJRXXRXXADZ26HI2QHMIG27AR5M3 X-Message-ID-Hash: N5TBPJRXXRXXADZ26HI2QHMIG27AR5M3 X-MailFrom: sean@sn3rd.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: TLS List X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BTLS=5D_Re=3A_AD_review_draft-ietf-tls-rfc8447bis-10?= List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_D2914D7B-1253-40BE-8EDD-133D177DB688 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Okay PRs are ready to merge: https://github.com/tlswg/rfc8447bis/pull/61 https://github.com/tlswg/rfc8447bis/pull/62 And I found some typos: https://github.com/tlswg/rfc8447bis/pull/63 Will merge Sunday (when submission window re-opens) and spin a new = version, unless you say otherwise. spt > On Mar 10, 2025, at 8:10=E2=80=AFPM, Paul Wouters = wrote: >=20 >=20 > On Fri, Mar 7, 2025 at 12:52=E2=80=AFPM Sean Turner > wrote: >>=20 >>=20 >>> On Mar 6, 2025, at 9:33=E2=80=AFPM, Paul Wouters = > wrote: >>>=20 >>> AD review of draft-ietf-tls-rfc8447bis-10 >>>=20 >>> I have some comments and small change requests. Do let me know if I = got it wrong. >>=20 >> Will do. BTW - one choice for you below. >>=20 >>> Section 3 >>>=20 >>> 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. >>> =20 >>> Isn't this easier written as: >>>=20 >>> Setting a value to "Y" or "D" in the "Recommended" column = requires >>> IETF Standards Action [RFC8126] or IESG Approval. >>>=20 >>> This appears in a number of sections in the document. >>=20 >> This sentence structure appears in 10 places. The same types of = sentences appear in 5 places in RFC 8447, but there is it "Y" and "N" = not =E2=80=9CY" an "D". This I-D updates all of those 5 in RFC 8447, so = sure we can make this change. >=20 > Great. >>> Section 4 TLS ExtensionType Values >>>=20 >>> 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]. >>>=20 >>> 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: >>>=20 >>> Values in the range 0-65279 are assigned via Specification = Required >>> [RFC8126]. Values in the range 65280-65535 are reserved for = Private >>> Use [RFC8126]. >>>=20 >>> Also, this is not true for: >>>=20 >>> 65281 renegotiation_info >>>=20 >>> which is clearly not usable for Private Use. Maybe it makes sense to = say: >>>=20 >>> 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]. >>>=20 >>> 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. >>=20 >> I don=E2=80=99t think that has actually been much of a problem = because it has been specified this way since RFC 4346. So, we got two = options: >>=20 >> 1) leave it alone >> 2) drop the offending text because we are not changing anything WRT = to the ranges in those 3 sections. If we do that I would suggest: >>=20 >> OLD: >>=20 >> * Change the registration procedure to: >>=20 >> 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]. Setting a >> "Recommended" column value to "Y" or "D" requires Standards = Action [RFC8126]. >> Any state transition to or from a "Y" or "D" value requires >> IESG Approval. >>=20 >> NEW: >>=20 >> * Adjust the registration procedure related to setting the = =E2=80=9CRecommended=E2=80=9D column as follows: >>=20 >> Setting a value to "Y" or "D" in the "Recommended" column requires >> IETF Standards Action [RFC8126] or IESG Approval. >>=20 >> Which do you prefer? >=20 > I prefer 2) >>> Section 6 TLS Supported Groups >>>=20 >>> * Replace the registry range table note column for the = 0-255, >>> 512-65535 range with "Unallocated". >>>=20 >>> This makes no sense. That current line with its note reads: >>>=20 >>> 0-255, 512-65535 Specification Required Elliptic = curve groups >>>=20 >>> 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" ? >>=20 >> I can get behind that. >=20 > Okay >>> Section 11 TLS ClientCertificateTypes registry >>>=20 >>> The registry name is not "TLS ClientCertificateTypes" registry, but >>> "TLS ClientCertificateTypes Identifiers" registry. >>=20 >> You are correct! >=20 > Good :) >=20 > Paul --Apple-Mail=_D2914D7B-1253-40BE-8EDD-133D177DB688 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Okay PRs are = ready to merge:

And I found some = typos:

Will merge Sunday = (when submission window re-opens) and spin a new version, unless you say = otherwise.

spt

On Mar 10, 2025, at 8:10=E2=80=AFPM, Paul Wouters = <paul.wouters@aiven.io> wrote:


On Fri, Mar = 7, 2025 at 12:52=E2=80=AFPM Sean Turner <sean@sn3rd.com> = wrote:


On Mar 6, 2025, at 9:33=E2=80=AFPM, Paul = Wouters <paul.wouters=3D40aiven.io@dmarc.ietf.org> = wrote:

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.

Will do.  = BTW - one choice for you below.

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.

This = sentence structure appears in 10 places. The same types of sentences = appear in 5 places in RFC 8447, but there is it "Y" and "N" not =E2=80=9CY= " an "D". This I-D updates all of those 5 in RFC 8447, so sure we can = make this = change.

Great.
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.

I = don=E2=80=99t think that has actually been much of a problem because it = has been specified this way since RFC 4346.  So, we got two = options:

1) leave it alone
2) drop = the offending text because we are not changing anything WRT to the = ranges in those 3 sections. If we do that I would = suggest:

OLD:

*  Change the =
registration procedure to:

    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].  Setting a
    "Recommended" column value to "Y" or "D" requires Standards Action =
[RFC8126].
    Any state transition to or from a "Y" or "D" value requires
    IESG Approval.

NEW:

 *  Adjust =
the registration procedure related to setting the =E2=80=9CRecommended=E2=80=
=9D column as follows:

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


Which do you =
prefer?

I prefer 2)
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" = ?

I can get behind = that.

Okay
Section 11 TLS = ClientCertificateTypes registry

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

You are = correct!

Good = :)

Paul

= --Apple-Mail=_D2914D7B-1253-40BE-8EDD-133D177DB688--