TLS 1.2 is in Feature Freeze
draft-ietf-tls-tls12-frozen-08

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-tls-tls12-frozen-07
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tls-tls12-frozen-07.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### Unlimited registrations

```
131   There are no limits on the registrations for either of the following
132   two registries:

134   *  TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs

136   *  TLS Exporter Labels
```

I might phrase this as the guidance to DEs and registration policies for the following registries are not changed by this document.

[Ballot comment]
Thanks for this document. A couple of comments (that I found ambiguous) for consideration of the authors and the responsible AD.

1) Section 1

"This document specifies that outside of urgent security fixes, and the exceptions listed in Section 4, no changes will be approved for TLS 1.2."

Following the conversations, it seems like the goal is for IETF to not adopt or approve work related to TLS 1.2 except some (exceptional) cases of security issues that are agreed upon in the TLS WG. If so, text along those lines would help clear ambiguities.

2) Section 2

"Put bluntly, post-quantum cryptography for TLS 1.2 WILL NOT be supported (see Section 4) at any time and anyone wishing to deploy post-quantum cryptography should expect to be using TLS 1.3."

The use of uppercase BCP14-like language tripped me as well. I believe the intention here is again that this work not be undertaken in the IETF (i.e., enhancements related to PQC MUST NOT be specified by IETF?).

Is there something to be added in the IANA considerations with regards to guidance to DEs to follow the guidelines in this document and not make allocations for TLS 1.2 extensions that may come from outside the IETF standards track?


Finally a question, unrelated to this document, does the TLS WG charter need an update to capture some of this decision/direction?

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-tls-tls12-frozen-07
CC @evyncke

Thank you for the work put into this document. It is short, useful, but may need some adjustments (see below).

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Sean Turner for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric



## COMMENTS (non-blocking)

### Section 2

Thanks for prefixing NIST with US in `US National Institute of Standards and Technology` but you forgot to introduce the NIST acronym ;-)

Any reason why BCP14-like notation is used in `TLS 1.2 WILL NOT be supported` ? Rather then `supported`, which is outside of the IETF remit, why not using `specified` ?

## Section 4

s/Any TLS entry added after the IESG approves publication of {THIS RFC}/Any TLS entry added after the publication of {THIS RFC}/ ? It is clearer for outsiders at the expense of a small time window between IESG approval and RFC publication.

```
Any registries created after this document is approved for publication should indicate whether the actions defined here are applicable
```
I find the above text really vague and underspecified. Who will decide the applicability ? Should there be guidelines ?

[Ballot comment]
Hi Rich,

Thank you for the effort put in this spec.

Thanks to Jen Linkova for the opsdir review. I understood that her comment will be fixed.

=======
= OLD DISCUSS (resolved, for archiving only)
============

I’m supportive of this work. I will be balloting “Yes” after the DISCUSS point is addressed.

## On urgent security conditions

CURRENT:
  This
  document specifies that outside of urgent security fixes, and the
  exceptions listed in Section 4, no changes will be approved for TLS
  1.2.

Who will make the call about what is “urgent”? Is it the TLS WG? Else? What about extensions that may be required by applications defined in other WGs?

====
= Comments
=========

# Abstract

## Reword for better clarity

OLD:
  Use of TLS 1.3 is growing and fixes some known deficiencies in TLS
  1.2. 

NEW:
  Use of TLS 1.3, which fixes some known deficiencies in TLS
  1.2, is growing. 

## I think “for TLS 1.2-only” would be more accurate as some of these are applicable to TLS1.3 as well. Consider updating accordingly:

CURRENT:
  This document specifies that except urgent security fixes,
  new TLS Exporter Labels, or new Application-Layer Protocol
  Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS
  1.2. 

# Introduction

## Reword for better clarity

OLD:
  Both versions have several extension points, so items like new
  cryptographic algorithms, new supported groups (formerly "named
  curves"), etc., can be added without defining a new protocol.

NEW:
  Both TLS versions have several extension points. Items such as new
  cryptographic algorithms, new supported groups (formerly "named
  curves"), etc., can be added without defining a new protocol. 

As a side note on “etc.”, I’d like to check if we should be more explicit here given that we have notes in the registry such as: “Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers and hash function, and cannot be used for TLS 1.2. Similarly, TLS 1.2 and lower cipher suite values cannot be used with TLS 1.3.”

# Section 2

## Provider examples of “huge impact” mentioned in this text:

CURRENT:
  Cryptographically relevant quantum computers, once available, will
  have a huge impact on RSA, FFDH, and ECC which are currently used in
  TLS. 

## On the various NIST citations: Are there any other similar pointers to list for non-US regions?

# Section 4:

## I think the IANA registries should be authoritative here, not the RFC.

CURRENT:
  No registries [TLS13REG] are being closed by this document.

## Call out this is about TLS registries:

OLD:
  No registries [TLS13REG] are being closed by this document.

NEW:
  No registries in TLS registry groups [REF] are being closed by this document.

## Not any random registry, but TLS:

OLD:
  Any registries created after this document is approved for
  publication should indicate whether the actions defined here are
  applicable.

NEW:
  Any TLS registry created after this document is approved for
  publication should indicate whether the actions defined here are
  applicable.

[Ballot discuss]
Hi Rich,

Thank you for the effort put in this spec.

Thanks to Jen Linkova for the opsdir review. I understood that her comment will be fixed.

I’m supportive of this work. I will be balloting “Yes” after the DISCUSS point is addressed.

## On urgent security conditions

CURRENT:
  This
  document specifies that outside of urgent security fixes, and the
  exceptions listed in Section 4, no changes will be approved for TLS
  1.2.

Who will make the call about what is “urgent”? Is it the TLS WG? Else? What about extensions that may be required by applications defined in other WGs?

[Ballot discuss]
Hi Rich,

Thank you for the effort put in this effort.

Thanks to Jen Linkova for the opsdir review. I understood that her comment will be fixed.

I’m supportive of this work. I will be balloting “Yes” after the DISCUSS point is addressed.

## On urgent security conditions

CURRENT:
  This
  document specifies that outside of urgent security fixes, and the
  exceptions listed in Section 4, no changes will be approved for TLS
  1.2.

Who will make the call about what is “urgent”? Is it the TLS WG? Else? What about extensions that may be required by applications defined in other WGs?

[Ballot comment]
FWIW, my full review can be found at:

* pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-tls-tls12-frozen-06-rev%20Med.pdf
* doc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-tls-tls12-frozen-06-rev%20Med.doc

Only a subset of items are echoed here. The author can refer to the full review for nits/edits/etc.

# Abstract

## Reword for better clarity

OLD:
  Use of TLS 1.3 is growing and fixes some known deficiencies in TLS
  1.2. 

NEW:
  Use of TLS 1.3, which fixes some known deficiencies in TLS
  1.2, is growing. 

## I think “for TLS 1.2-only” would be more accurate as some of these are applicable to TLS1.3 as well. Consider updating accordingly:

CURRENT:
  This document specifies that except urgent security fixes,
  new TLS Exporter Labels, or new Application-Layer Protocol
  Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS
  1.2. 

# Introduction

## Reword for better clarity

OLD:
  Both versions have several extension points, so items like new
  cryptographic algorithms, new supported groups (formerly "named
  curves"), etc., can be added without defining a new protocol.

NEW:
  Both TLS versions have several extension points. Items such as new
  cryptographic algorithms, new supported groups (formerly "named
  curves"), etc., can be added without defining a new protocol. 

As a side note on “etc.”, I’d like to check if we should be more explicit here given that we have notes in the registry such as: “Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers and hash function, and cannot be used for TLS 1.2. Similarly, TLS 1.2 and lower cipher suite values cannot be used with TLS 1.3.”

# Section 2

## Provider examples of “huge impact” mentioned in this text:

CURRENT:
  Cryptographically relevant quantum computers, once available, will
  have a huge impact on RSA, FFDH, and ECC which are currently used in
  TLS. 

## On the various NIST citations: Are there any other similar pointers to list for non-US regions?

# Section 4:

## I think the IANA registries should be authoritative here, not the RFC.

CURRENT:
  No registries [TLS13REG] are being closed by this document.

## Call out this is about TLS registries:

OLD:
  No registries [TLS13REG] are being closed by this document.

NEW:
  No registries in TLS registry groups [REF] are being closed by this document.

## Not any random registry, but TLS:

OLD:
  Any registries created after this document is approved for
  publication should indicate whether the actions defined here are
  applicable.

NEW:
  Any TLS registry created after this document is approved for
  publication should indicate whether the actions defined here are
  applicable.

[Ballot comment]
The registry note "Any entry [...] makes no requirement on DTLS" does not seem correct. Consider rewording this to indicate that the *notation* does not impact DTLS, or consider adding separate explicit columns for TLS and DTLS version restrictions.

[Ballot comment]
# Internet AD comments for draft-ietf-tls-tls12-frozen-06
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S4

* s/indication indication/indication/

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tls-tls12-frozen-06. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the Transport Layer Security (TLS) Parameters registry group at:

https://www.iana.org/assignments/tls-parameters/

there are nineteen registries:

TLS ClientCertificateType Identifiers
TLS Cipher Suites
TLS ContentType
TLS Alerts
TLS HandshakeType
TLS Supported Groups
TLS EC Point Formats
TLS EC Curve Types
TLS Supplemental Data Formats (SupplementalDataType)
TLS UserMappingType Values
TLS SignatureAlgorithm
TLS HashAlgorithm
TLS Exporter Labels
TLS Authorization Data Formats
TLS Heartbeat Message Types
TLS Heartbeat Modes
TLS SignatureScheme
TLS PskKeyExchangeMode
TLS KDF Identifiers

IANA understands that, for one of these registries no changes are to be made. That registry is:

TLS Exporter Labels

For the other eighteen registries in that group, IANA understands that a note is to be added to each registry as follows:

Any entry added after the IESG approves publication of [ RFC-to-be ] is intended for TLS 1.3 or later, and makes no requirement on DTLS. Such entries should have an informal indication indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Second, in the Transport Layer Security (TLS) Extensions registry group at:

https://www.iana.org/assignments/tls-extensiontype-values/

there are six registries:

TLS ExtensionType Values
TLS Certificate Types
TLS Certificate Status Types
TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs
TLS CachedInformationType Values
TLS Certificate Compression Algorithm IDs

IANA understands that, for one of these registries no changes are to be made. That registry is:

TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs

For the other five registries in that group, IANA understands that a note is to be added to each registry as follows:

Any entry added after the IESG approves publication of [ RFC-to-be ] is intended for TLS 1.3 or later, and makes no requirement on DTLS. Such entries should have an informal indication indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

IANA understands that no other registries or registry group are affected by the publication of [ RFC-to-be ].

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-02-25):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tls-tls12-frozen@ietf.org, paul.wouters@aiven.io, sean@sn3rd.com, tls-chairs@ietf.org, tls@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (TLS 1.2 is in Feature Freeze) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'TLS 1.2 is in Feature Freeze'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-02-25. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Use of TLS 1.3 is growing and fixes some known deficiencies in TLS
  1.2.  This document specifies that outside of urgent security fixes,
  new TLS Exporter Labels, or new Application-Layer Protocol
  Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS
  1.2.  This prescription does not pertain to DTLS (in any DTLS
  version); it pertains to TLS only.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-tls-rfc8447bis: IANA Registry Updates for TLS and DTLS (None - Internet Engineering Task Force (IETF) stream)

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This I-D represents the consensus on the WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Not particularly, but the initial round of comments did ensure that this I-D was only about TLS and not DTLS and split out the application-specific information into draft-ietf-uta-require-tls13, which is also in WGLC. If possible, it makes sense that these two proceed together.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

There have been no threats of appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

In some sense it does because it says that new protocols should not expect to work on TLS 1.2.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does add new restrictions to the TLS registries; it was written by one of the DE's for those registries.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Shepherd believes that this document is ready to go.

10. Several IETF Areas have assembled [lists of common issues that their
reviewers encounter][6]. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

Almost all of the common issues are N/A as this is not a protocol document.

11. What type of RFC publication is being requested on the IETF stream ([Best
Current Practice][12], [Proposed Standard, Internet Standard][13],
[Informational, Experimental or Historic][14])? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational Track was originally requested, but after discussions with IANA and our AD it was changed to Standards Track because the I-D updates registration procedures for a number of registries.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in [BCP 79][7]? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

The Shepherd has confirmed with the authors that all required disclosures have been filed.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

The Shepherd has confirmed with the authors that all are willing to be an author.

14. Document any remaining I-D nits in this document. Simply running the [idnits
tool][8] is not enough; please review the ["Content Guidelines" on
authors.ietf.org][15]. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

No remaining I-D nits in this I-D.

15. Should any informative references be normative or vice-versa? See the [IESG
Statement on Normative and Informative References][16].

There are not many references and they seem to be categorized correctly.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?
N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
list them.

N/A

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

I-D includes references to draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8446bis. draft-ietf-tls-rfc8446bis is through IETF LC and draft-ietf-tls-rfc8447bis is about to enter IETF LC.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

N/A

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see [RFC 8126][11]).

The instructions are short and clear. Additionally, one of the authors is a TLS DE.

21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This I-D represents the consensus on the WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Not particularly, but the initial round of comments did ensure that this I-D was only about TLS and not DTLS and split out the application-specific information into draft-ietf-uta-require-tls13, which is also in WGLC. If possible, it makes sense that these two proceed together.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

There have been no threats of appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

In some sense it does because it says that new protocols should not expect to work on TLS 1.2.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does add new restrictions to the TLS registries; it was written by one of the DE's for those registries.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Shepherd believes that this document is ready to go.

10. Several IETF Areas have assembled [lists of common issues that their
reviewers encounter][6]. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

Almost all of the common issues are N/A as this is not a protocol document.

11. What type of RFC publication is being requested on the IETF stream ([Best
Current Practice][12], [Proposed Standard, Internet Standard][13],
[Informational, Experimental or Historic][14])? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational Track was originally requested, but after discussions with IANA and our AD it was changed to Standards Track because the I-D updates registration procedures for a number of registries.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in [BCP 79][7]? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

The Shepherd has confirmed with the authors that all required disclosures have been filed.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

The Shepherd has confirmed with the authors that all are willing to be an author.

14. Document any remaining I-D nits in this document. Simply running the [idnits
tool][8] is not enough; please review the ["Content Guidelines" on
authors.ietf.org][15]. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

No remaining I-D nits in this I-D.

15. Should any informative references be normative or vice-versa? See the [IESG
Statement on Normative and Informative References][16].

There are not many references and they seem to be categorized correctly.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?
N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
list them.

N/A

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

I-D includes references to draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8446bis. draft-ietf-tls-rfc8446bis is through IETF LC and draft-ietf-tls-rfc8447bis is about to enter IETF LC.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

N/A

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see [RFC 8126][11]).

The instructions are short and clear. Additionally, one of the authors is a TLS DE.

21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tls-tls12-frozen-05. If any part of this review is inaccurate, please let us know.

IANA has questions about the actions requested in the IANA Considerations section of this document.

First, there seems to be a consistency problem between this draft and the 8447bis draft. In particular, 8447bis seems to be changing registration procedures for registries that this draft intends to close.

Second, it would be very helpful if the authors would name - specifically - the registries that are "frozen." If a specific list of the registries is difficult, then at least the registry groups that will no longer be available for new registrations (for instance, "Transport Layer Security (TLS) Parameters" at https://www.iana.org/assignments/tls-parameters and "Transport Layer Security (TLS) Extensions" at https://www.iana.org/assignments/tls-extensiontype-values).

Third, what should "Entries in any other TLS protocol registry should have an indication like 'For TLS 1.3 or later' in their entry" actually look like in the registries? Do the authors want to add a new column (called what and filled in how?), or would it be in the "Note:" accompanying the registry, or would we be adding this to every description in parentheses? Are all existing TLS registrations (excluding deprecations and obsoletions?) "for TLS 1.3 or later"?

Fourth, should IANA wait to make the changes requested by draft-ietf-tls-tls12-frozen-05 until the TLS 1.3 bis documents are agreed upon and published?

Finally, marking a registry as "no longer accepting registrations" is extremely unusual. Given RFC 8126, IANA sometimes changes a registry's procedure to "Registry Closed." Is this an acceptable method to meet the intent of the current draft? Otherwise, the draft should be revised to provide specific language to use along with specifics of which registries to which that language should be applied.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-01-13):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tls-tls12-frozen@ietf.org, paul.wouters@aiven.io, sean@sn3rd.com, tls-chairs@ietf.org, tls@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (TLS 1.2 is in Feature Freeze) to Informational RFC


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'TLS 1.2 is in Feature Freeze'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-01-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Use of TLS 1.3 is growing and fixes some known deficiencies in TLS
  1.2.  This document specifies that outside of urgent security fixes,
  new TLS Exporter Labels, or new Application-Layer Protocol
  Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS
  1.2.  This prescription does not pertain to DTLS (in any DTLS
  version); it pertains to TLS only.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This I-D represents the consensus on the WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Not particularly, but the initial round of comments did ensure that this I-D was only about TLS and not DTLS and split out the application-specific information into draft-ietf-uta-require-tls13, which is also in WGLC. If possible, it makes sense that these two proceed together.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

There have been no threats of appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

In some sense it does because it says that new protocols should not expect to work on TLS 1.2.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does add new restrictions to the TLS registries; it was written by one of the DE's for those registries.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Shepherd believes that this document is ready to go.

10. Several IETF Areas have assembled [lists of common issues that their
reviewers encounter][6]. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

Almost all of the common issues are N/A as this is not a protocol document.

11. What type of RFC publication is being requested on the IETF stream ([Best
Current Practice][12], [Proposed Standard, Internet Standard][13],
[Informational, Experimental or Historic][14])? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational Track is requested. This is proper because there is no protocol.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in [BCP 79][7]? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

The Shepherd has confirmed with the authors that all required disclosures have been filed.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

The Shepherd has confirmed with the authors that all are willing to be an author.

14. Document any remaining I-D nits in this document. Simply running the [idnits
tool][8] is not enough; please review the ["Content Guidelines" on
authors.ietf.org][15]. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

No remaining I-D nits in this I-D.

15. Should any informative references be normative or vice-versa? See the [IESG
Statement on Normative and Informative References][16].

There are not many references and they seem to be categorized correctly.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?
N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
list them.

N/A

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

I-D includes references to draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8446bis. draft-ietf-tls-rfc8446bis is through IETF LC and draft-ietf-tls-rfc8447bis is about to enter IETF LC.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

N/A

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see [RFC 8126][11]).

The instructions are short and clear. Additionally, one of the authors is a TLS DE.

21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This I-D represents the consensus on the WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Not particularly, but the initial round of comments did ensure that this I-D was only about TLS and not DTLS and split out the application-specific information into draft-ietf-uta-require-tls13, which is also in WGLC. If possible, it makes sense that these two proceed together.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

There have been no threats of appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

In some sense it does because it says that new protocols should not expect to work on TLS 1.2.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does add new restrictions to the TLS registries; it was written by one of the DE's for those registries.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Shepherd believes that this document is ready to go.

10. Several IETF Areas have assembled [lists of common issues that their
reviewers encounter][6]. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

Almost all of the common issues are N/A as this is not a protocol document.

11. What type of RFC publication is being requested on the IETF stream ([Best
Current Practice][12], [Proposed Standard, Internet Standard][13],
[Informational, Experimental or Historic][14])? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational Track is requested. This is proper because there is no protocol.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in [BCP 79][7]? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

The Shepherd has confirmed with the authors that all required disclosures have been filed.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

The Shepherd has confirmed with the authors that all are willing to be an author.

14. Document any remaining I-D nits in this document. Simply running the [idnits
tool][8] is not enough; please review the ["Content Guidelines" on
authors.ietf.org][15]. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

No remaining I-D nits in this I-D.

15. Should any informative references be normative or vice-versa? See the [IESG
Statement on Normative and Informative References][16].

There are not many references and they seem to be categorized correctly.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?
N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
list them.

N/A

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

I-D includes references to draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8446bis. draft-ietf-tls-rfc8446bis is through IETF LC and draft-ietf-tls-rfc8447bis is about to enter IETF LC.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

N/A

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see [RFC 8126][11]).

The instructions are short and clear. Additionally, one of the authors is a TLS DE.

21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/