Thanks for your careful read. I created an issue for your comments:
https://github.com/tlswg/rfc8447bis/issues/85
and a PR to address them:
https://github.com/tlswg/rfc8447bis/pulls/86
<https://github.com/tlswg/rfc8447bis/issues/85>
tl;dr: we incorporated most of your suggestions.
More below.
> On May 18, 2025, at 07:52, Mohamed Boucadair via Datatracker
> <nore...@ietf.org> wrote:
>
> Mohamed Boucadair has entered the following ballot position for
> draft-ietf-tls-rfc8447bis-12: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Hi Joe and Sean,
>
> Thank you for the effort put into this specification. This maintenance effort
> is really important from an OPS standpoint. As rightfully discussed in the
> spec, the registry may “lag behind the most recent advances in cryptanalysis”,
> but that risk can’t be nullified especially given the process time to
> transition some values.
>
> Thanks to Giuseppe Fioccola for the OPSDIR review and for the authors for
> engaging and converging.
>
> Please find below some comments:
>
> # Meta comment
>
> I understand this is an update not a bis, but the discussion in the write-up
> confuses me a bit.
>
> # Updates Duplication/Updates Inheritance
>
> We have the following:
>
> CURRENT:
> Updates: 3749, 5077, 4680, 5246, 5705, 5878, S. Turner
> 6520, 7301, 8447 (if approved) sn3rd
>
> …
>
> This document updates the following RFCs: 3749, 5077, 4680, 5246,
> 5705, 5878, 6520, 7301, and 8447.
>
> Except the mention of 8447 (which is justified), all other entries were
> already
> updated by 8447. Unless there are new updates in this new iteration (which I
> fail to tag), the other updates are already anchored in 8447 and do not to be
> repeated here. Did I miss something here?
spt: Makes sense to me; see: https://github.com/tlswg/rfc8447bis/pull/86
<https://github.com/tlswg/rfc8447bis/pull/84>
> # TLS registries
>
> CURRENT:
> This document instructs IANA to make changes to a number of the IANA
> registries
>
> I suggest to add pointers to these registries. This is even important,
> especially that the IANA registries are authoritative in this context.
>
> I had to search for those when reviewing the document. Having
> readily-available
> pointers (not only here, but also when discussing individual registries) is
> convenient for readers, especially that these are not in the same location,
> e.g.,
>
> *
>
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
>
> * https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
>
> BTW, we may explicit this is about TLS registries.
>
> OLD:
> This document instructs IANA to make changes to a number of the IANA
> registries
>
> NEW:
> This document instructs IANA to make changes to a number of IANA TLS
> registries ..
>
> # Section 1: IANA Note
>
> CURRENT:
> | NOTE for IANA: This document specifies changes to the registry
> | to update the changes made in [RFC8447].
>
> Do we expect this note to stay in the final RFC?
>
> I don’t see how this is useful for readers once the doc is published as an
> RFC.
> Consider adding a note to the RFC editor to remove this.
spt: Since the section headings include the names of the registries in most
places, how about we make sure they all include registry and then people can
use the ToC as the pointer. As for the specific change to add “TLS”, the
remainder of the sentence qualifies which registries; I think this would be
weird: This document instructs IANA to make changes to a number of IANA TLS
registries related to Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS).
see: https://github.com/tlswg/rfc8447bis/pull/84
> # Section 1: List of changes
>
> CURRENT:
> This specification updates the "Recommended" column in TLS registries
> to define a third value "D" for items that are discouraged.
>
> Should we also mention the other change about the comment column? At least the
> abstract/intro should be in sync on the list of changes.
spt: Sure; see: https://github.com/tlswg/rfc8447bis/pull/86
<https://github.com/tlswg/rfc8447bis/pull/84>
> # Section 3: Adding "Recommended" Column
>
> This update is not about adding a new column, but updating permitted values. I
> would update the title to reflect the update. You may consider, for example:
>
> OLD: Adding "Recommended" Column
>
> NEW: Updating Permitted Value in "Recommended" Column
spt: Sure; see: https://github.com/tlswg/rfc8447bis/pull/86
<https://github.com/tlswg/rfc8447bis/pull/84>
> # Section 3: Check on “Y”/”N” Value and applicability of a mechanism
>
> RFC8447 used to have: “This table has been generated by marking Standards
> Track
> RFCs as "Y" and all others as "N".”. That guidance seems “mechanical” to me.
>
> This document seems to have a slightly modified guidance as it says:
>
> CURRENT:
> Y: Indicates that the IETF has consensus that the item is
> RECOMMENDED. This only means that the associated mechanism is fit
> for the purpose for which it was defined. Careful reading of the
> documentation for the mechanism is necessary to understand the
> applicability of that mechanism. The IETF could recommend
> mechanisms that have limited applicability, but will provide
> applicability statements that describe any limitations of the
> mechanism or necessary constraints on its use.
>
> Does this mean that all “Y” have been checked based on “Careful reading ..”
> and
> their applicability is called?
spt: We went through every one with the WG.
> I’m asking this question, especially that we also have the following under
> “N”:
>
> CURRENT:
> The IETF
> might have consensus to leave an items marked as "N" on the basis
> of its having limited applicability or usage constraints.
>
> # Section 3: Why Implementers only? What about those who will make use of a
> mechanism?
>
> ## Consider mention users as well
>
> CURRENT:
> Implementers SHOULD consult the …
>
> Any reason why users are not listed here?
>
> The wording in the Security Section is better IMO as it covers both:
>
> “Implementers and users need to check that…”
spt: Sure; see:
https://github.com/tlswg/rfc8447bis/pull/86
<https://github.com/tlswg/rfc8447bis/pull/84>
> ## I see the intent here for the use of normative language “SHOULD”, but we
> can’t actually enforce this.
spt: Correct.
> ## Explicit “it” + avoid confusion about the use of normative language
>
> Maybe:
>
> OLD:
> conditions under which it SHOULD NOT or MUST NOT be used.
>
> NEW:
> conditions under which an item “SHOULD NOT” or “MUST NOT” be used.
spt: Eh, I can see the flip side where people like does that mean something
different when it’s quoted. But, we fixed the "it" problem.
See: https://github.com/tlswg/rfc8447bis/pull/86
<https://github.com/tlswg/rfc8447bis/pull/84>
> # Section 3.1: picky
>
> CURRENT:
> For the registries discussed in the subsequent sections this
> note is updated with a sentence describing the "D" value as follows:
>
> Agree. The wording of the first sentence is also tweaked, but the meaning is
> same as in the registry, though. IANA registry has the following:
>
> If an item is not marked as "Recommended", it does not
> necessarily mean that it is flawed; rather, it indicates that
> the item either has not been through the IETF consensus process,
> has limited applicability, or is intended only for specific use
> cases.
spt: We want to keep the “N” in there and we’d like to keep it parallel to the
2nd sentence.
> # IESG Approval is also covered by 8126!
>
> There many occurrences in the doc where 8126 is systematically provided as
> reference to Standard action only. Please consider updating all these
> occurrences as follows:
>
> OLD:
> Setting a value to "Y" or "D" or transitioning the value from
> "Y" or "D" in the "Recommended" column requires
> IETF Standards Action [RFC8126] or IESG Approval.
>
> NEW:
> Setting a value to "Y" or "D" or transitioning the value from
> "Y" or "D" in the "Recommended" column requires
> IETF Standards Action (Section 4.9 of [RFC8126]) or IESG Approval
> (Section 4.10 of [RFC8126]).
spt: We will move the reference to the end of the sentences; see:
https://github.com/tlswg/rfc8447bis/pull/86
<https://github.com/tlswg/rfc8447bis/pull/84>
> # “IANA SHALL …” constructs
>
> Like other uses in an IANA consideration sections, the normative language is
> not justified to request an action. Please consider making these changes (many
> occurrences)
>
> OLD: IANA SHALL
> NEW: IANA is requested
>
> OLD: A reference to this document SHALL be added to these entries.
> NEW: IANA is requested to add a reference to this document for these entries.
spt: Sure; see https://github.com/tlswg/rfc8447bis/pull/86.
I will note we did this in the pre-RFC 8447 specification and it was all fine.
> # Section 5: nits
>
> OLD:
> Cipher suites marked as anon do not provide any authentication and
> are vulnerable to man-in-the-middle attacks and are deprecated
>
> NEW:
> Ciphersuites marked as anon do not provide any authentication and
> are vulnerable to on-path attacks and are deprecated
spt: Sure; see https://github.com/tlswg/rfc8447bis/pull/86.
> # Section 8: nit
>
> OLD: the the TLS Certificate Types
> NEW: the TLS Certificate Types
>
> # Section 9: use the IANA registry name
>
> OLD: TLS HashAlgorithm Registry registry
> NEW: TLS HashAlgorithm registry
spt: Sure; see https://github.com/tlswg/rfc8447bis/pull/86.
> # Section 10: nit
>
> OLD: SignatureAlgorithm registry registry
> NEW: SignatureAlgorithm registry
spt: Sure; see https://github.com/tlswg/rfc8447bis/pull/86.
> # Section 11: Use the IANA registry name (several occurrences to fix)
>
> OLD: TLS ClientCertificateType Identifier registry
> NEW: TLS ClientCertificateType Identifiers registry
spt: Sure; see https://github.com/tlswg/rfc8447bis/pull/86.
> # Section 13: Lack of recommended note, intentional?
>
> Is it OK that there is no note on the recommended column in this IANA
> registry,
> while a recommended column is present? is the new note in 3.1 apply here as
> well?
spt: Whoops we need to add that; see
https://github.com/tlswg/rfc8447bis/pull/86.
> # Section 15: standard
>
> CURRENT:
> The intent of the Specification Required standard
>
> What does this mean? Do we meant registration policy? Please reword. Thanks.
spt: Will replace “standard” with “choice”; see
https://github.com/tlswg/rfc8447bis/pull/86.
> # Section 16: WG
>
> CURRENT:
> The change to Specification Required from IETF Review lowers the
> amount of review provided by the WG for cipher suites and supported
> groups. This change reflects reality in that the WG essentially
> provided no cryptographic review of the cipher suites or supported
> groups. This was especially true of national cipher suites.
>
> Which WG? I guess you mean "TLS WG". This is confusing especially that the
> document reflect an IETF consensus, not a specific WG.
spt: We are providing the history of why the change was made. Maybe we could do:
The change to Specification Required from IETF Review lowers the
amount of review provided for cipher suites and supported
groups. This change reflects reality in that the TLS WG essentially
provided no cryptographic review of the cipher suites or supported
groups. This was especially true of national cipher suites.
See https://github.com/tlswg/rfc8447bis/pull/86.
Cheers,
spt
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
