Draft: draft-ietf-tls-rfc8447bis

Commentary: Updated introduction and recommended column section . Deleted some irrelevant sections . 
 Changed from obsolete to update . 
 Obsoleting RFC 8447 means duplicating a lot of text and making changes to it which makes the document have awkward wording and makes the changes difficult to follow . I think it would be clearer if it were an update and just listed the changes . see Extension Types PR 
 At IETF 115 , there was general agreement that this document could be an update as opposed to an obsolete to make it easier on IANA . 
 These are nits .
This document describes a number of changes to TLS and DTLS IANA
registries that range from adding notes to the registry all the way
to changing the registration policy.  These changes were mostly
motivated by WG review of the TLS- and DTLS-related registries
undertaken as part of the TLS 1.3 development process.
This document obsoletes RFC 8447 and updates the following RFCs:
3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.
This document instructs IANA to make changes to a number of the IANA
registries related to Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS).
Most of the instructions included herein and previously included in
RFC8447, which this document obsoletes, were motivated by the
development of TLS 1.3 RFC8446.  The changes ranged from simple,
e.g., adding notes, to complex, e.g., changing a registry's
registration policy.  Instead of listing the changes and their
rationale here in the introduction, each section provides rationale
for the proposed change(s).  The instructions in this document revise
the values of "Recommended" column, applies the new value to the
registries, and adds this column as noted in orphaned-registries.
There are also instructions to update references, including replacing
references to RFC8446 with I-D.ietf-tls-rfc8446bis and RFC8447 with
I-D.ietf-tls-rfc8447bis.
This document proposes no changes to the registration policies for
TLS Alerts I-D.ietf-tls-rfc8446bis, TLS ContentType I-D.ietf-tls-
rfc8446bis, TLS HandshakeType I-D.ietf-tls-rfc8446bis, and TLS
Certificate Status Types RFC6961 registries; the existing policies
(Standards Action for the first three; IETF Review for the last), are
appropriate for these one-byte code points because of their scarcity.
This document updates the changes to TLS and DTLS IANA registries
made in RFC 8447.  It adds a new value "D" for discouraged to the
recommended column of the selected TLS registries.
This document updates the following RFCs: 3749, 5077, 4680, 5246,
5705, 5878, 6520, 7301, and 8447.
This document instructs IANA to make changes to a number of the IANA
registries related to Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS).  These changes update the changes
made in RFC8447.
This specification updates the "Recommended" column in TLS registries
to define a third value "D" for items that are discouraged.
Application-Layer Protocol Negotiation (ALPN) Protocol IDs
RFC7301,
ExtensionType Values,
Heartbeat Modes RFC6520.
IANA [SHALL update/has updated] the reference for these four
registries to also refer to this document.  The remainder of this
document will use the registry names with the "TLS" prefix.
This is not a universal change, as some registries originally defined
with "IETF Consensus" are undergoing other changes either as a result
of this document or RFC8422.
IANA [SHALL update/has updated] the reference for these two
registries to also refer to this document.
D: Indicates that the item is discouraged and SHOULD NOT or MUST
NOT be used.  This marking could be used to identify mechanisms
that might result in problems if they are used, such as a weak
cryptographic algorithm or a mechanism that might cause
interoperability problems in deployment.
Setting the Recommended item to "Y" or "D" or changing a item whose
current value is "Y" or "D" requires Standards Action RFC8126.  Not
all items defined in Standards Track RFCs need to be marked as
Recommended.  Changing the Recommended status of an item in a
Standards Track RFC requires Standards Action RFC8126.
has renamed entry 35 to "session_ticket (renamed from
"SessionTicket TLS")" RFC5077.
Update the "Recommended" column with the changes as listed below.
This table has been generated by keeping existing "Y" and "N"
entries except for "truncated_hmac" (4), "connection_id
(deprecated)" (53), "reserved" (40) and "Reserved" (46) as "D".  A
reference to this document SHALL be added to these entries.
Added a "Recommended" column to the TLS Cipher Suites registry.
The cipher suites that follow in the two tables are marked as "Y".
All other cipher suites are marked as "N".  The "Recommended"
column is assigned a value of "N" unless explicitly requested, and
adding a value with a "Recommended" value of "Y" requires
Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N
transition.
The cipher suites that follow are Standards Track server-
authenticated (and optionally client-authenticated) cipher suites
that are currently available in TLS 1.2.
The cipher suites that follow are Standards Track ephemeral pre-
shared key cipher suites that are available in TLS 1.2.
The TLS 1.3 cipher suites specified by I-D.ietf-tls-rfc8446bis are
not listed here; that document provides for their "Recommended"
status.
Similar to cipher suites, supported groups have proliferated over
time, and some use the registry to measure implementations.
Therefore, IANA [SHALL add/has added] a "Recommended" column with a
"Y" for secp256r1, secp384r1, x25519, and x448, while all others are
"N".  These "Y" groups are taken from Standards Track RFCs; RFC8422
elevates secp256r1 and secp384r1 to Standards Track.  Not all groups
from RFC8422, which is Standards Track, are marked as "Y"; these
groups apply to TLS 1.3 I-D.ietf-tls-rfc8446bis and previous versions
of TLS.  The "Recommended" column is assigned a value of "N" unless
explicitly requested, and adding a value with a "Recommended" value
of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED
for a Y->N transition.
The value 0 (0x0000) has been marked as reserved.
has renamed entry 4 in the TLS HandshakeType registry to
"new_session_ticket (renamed from NewSessionTicket)" RFC5077.
A "Recommended" column to the TLS Exporter Labels registry.  The
table that follows has been generated by marking Standards Track
RFCs as "Y" and all others as "N".  The "Recommended" column is
assigned a value of "N" unless explicitly requested, and adding a
value with a "Recommended" value of "Y" requires Standards Action
RFC8126.  IESG Approval is REQUIRED for a Y->N, Y->D, or D->Y|N
transitions.
IANA [SHALL update/has updated] the reference for this registry to
refer to refer to this document instead of RFC8447.
Added a "Recommended" column to the registry.  X.509 and Raw
Public Key are "Y".  All others are "N".  The "Recommended" column
is assigned a value of "N" unless explicitly requested, and adding
a value with a "Recommended" value of "Y" requires Standards
Action RFC8126.  IESG Approval is REQUIRED for a Y->N, Y->D, and
D->Y|N transitions.
IANA [SHALL update/has updated] the reference for this registry to
refer this document instead of RFC8447.
has updated the TLS HashAlgorithm registry to list values 7 and
9-223 as "Reserved" and the TLS SignatureAlgorithm registry to
list values 4-6 and 9-223 as "Reserved".
In the TLS HashAlgorithm, TLS SignatureAlgorithm, and TLS
ClientCertificateTypes registries, all unassigned and reserved values
have a "Recommended" that is blank.
Specification Required RFC8126 registry requests are registered after
a three-week review period on the tls-reg-review@ietf.org [1] mailing
list, on the advice of one or more designated experts.  However, to
allow for the allocation of values prior to publication, the
designated experts may approve registration once they are satisfied
that such a specification will be published.
Registration requests sent to the mailing list for review SHOULD use
an appropriate subject (e.g., "Request to register value in TLS bar
registry").
Within the review period, the designated experts will either approve
or deny the registration request, communicating this decision to the
review list and IANA.  Denials SHOULD include an explanation and, if
applicable, suggestions as to how to make the request successful.
Registration requests that are undetermined for a period longer than
21 days can be brought to the IESG's attention (using the
iesg@ietf.org [2] mailing list) for resolution.
Criteria that SHOULD be applied by the designated experts includes
determining whether the proposed registration duplicates existing
functionality, whether it is likely to be of general applicability or
useful only for a single application, and whether the registration
description is clear.
IANA MUST only accept registry updates from the designated experts
and SHOULD direct all requests for registration to the review mailing
list.
It is suggested that multiple designated experts be appointed who are
able to represent the perspectives of different applications using
this specification, in order to enable broadly informed review of
registration decisions.  In cases where a registration decision could
be perceived as creating a conflict of interest for a particular
Expert, that Expert SHOULD defer to the judgment of the other
Experts.
D: Indicates that the item is discouraged.  This marking could be
used to identify mechanisms that might result in problems if they
are used, such as a weak cryptographic algorithm or a mechanism
that might cause interoperability problems in deployment.
Implementers SHOULD consult the linked references associated with
the item to determine the conditions under which it SHOULD NOT or
MUST NOT be used.
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 Apporval.  Not all items defined in
Standards Track RFCs need to be set to "Y" or "D".  Any item not
otherwise specified is set to "N".  The column is blank for values
that are unassigned or reserved unless specifically set.
This document is entirely about changes to TLS-related IANA
registries.