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

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.

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