[TLS] Re: Mohamed Boucadair's Yes on draft-ietf-tls-rfc8447bis-12: (with COMMENT)

[[e-mail]]

Hi Sean,

Thanks for the follow-up. I also checked iddiff?url1=draft-ietf-tls-rfc8447bis-12&url2=draft-ietf-tls-rfc8447bis-13, the changes look good to me. Thank you.

Cheers,
Med

De : Sean Turner <[e-mail]>
Envoyé : mercredi 28 mai 2025 22:00
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : The IESG <[e-mail]>; [e-mail]; TLS Chairs <[e-mail]>; TLS List <[e-mail]>; Deirdre Connolly <[e-mail]>
Objet : Re: Mohamed Boucadair's Yes on draft-ietf-tls-rfc8447bis-12: (with COMMENT)



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 <[e-mail]<mailto:[e-mail]>> 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
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.