< draft-ietf-tls-iana-registry-updates-02.txt		draft-ietf-tls-iana-registry-updates-03.txt >
	TLS WG J. Salowey		TLS WG J. Salowey
	Internet-Draft Tableau Software		Internet-Draft Tableau Software
	Updates: 3749, 5077, 4680, 5246, 5705, S. Turner		Updates: 3749, 5077, 4680, 5246, 5705, S. Turner
	5878, 6520, 7301 (if approved) sn3rd		5878, 6520, 7301 (if approved) sn3rd
	Intended status: Standards Track October 30, 2017		Intended status: Standards Track January 3, 2018
	Expires: May 3, 2018		Expires: July 7, 2018
	IANA Registry Updates for TLS and DTLS		IANA Registry Updates for TLS and DTLS
	draft-ietf-tls-iana-registry-updates-02		draft-ietf-tls-iana-registry-updates-03
	Abstract		Abstract
	This document describes a number of changes to (D)TLS IANA registries		This document describes a number of changes to (D)TLS IANA registries
	that range from adding notes to the registry all the way to changing		that range from adding notes to the registry all the way to changing
	the registration policy. These changes were mostly motivated by WG		the registration policy. These changes were mostly motivated by WG
	review of the (D)TLS-related registries undertaken as part of the		review of the (D)TLS-related registries undertaken as part of the
	TLS1.3 development process. This document updates many (D)TLS RFCs		TLS1.3 development process. This document updates many (D)TLS RFCs
	(see updates header).		(see updates header).
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 3, 2018.		This Internet-Draft will expire on July 7, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Process Note . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Process Note . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Add "TLS" to Registry Names . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Aligning with RFC 8126 . . . . . . . . . . . . . . . . . . . 3		4. Add "TLS" to Registry Names . . . . . . . . . . . . . . . . . 3
	5. Adding recommended Column . . . . . . . . . . . . . . . . . . 4		5. Aligning with RFC 8126 . . . . . . . . . . . . . . . . . . . 3
	6. Session Ticket TLS Extension . . . . . . . . . . . . . . . . 4		6. Adding recommended Column . . . . . . . . . . . . . . . . . . 4
	7. TLS ExtensionType Values . . . . . . . . . . . . . . . . . . 4		7. Session Ticket TLS Extension . . . . . . . . . . . . . . . . 4
	8. TLS Cipher Suite Registry . . . . . . . . . . . . . . . . . . 6		8. TLS ExtensionType Values . . . . . . . . . . . . . . . . . . 4
	9. TLS Supported Groups . . . . . . . . . . . . . . . . . . . . 8		9. TLS Cipher Suite Registry . . . . . . . . . . . . . . . . . . 6
	10. TLS ClientCertificateType Identifiers . . . . . . . . . . . . 9		10. TLS Supported Groups . . . . . . . . . . . . . . . . . . . . 9
	11. New Session Ticket TLS Handshake Message Type . . . . . . . . 10		11. TLS ClientCertificateType Identifiers . . . . . . . . . . . . 10
	12. TLS Exporter Label Registry . . . . . . . . . . . . . . . . . 10		12. New Session Ticket TLS Handshake Message Type . . . . . . . . 10
	13. Add Missing Item to TLS Alert Registry . . . . . . . . . . . 11		13. TLS Exporter Label Registry . . . . . . . . . . . . . . . . . 10
	14. TLS Certificate Types . . . . . . . . . . . . . . . . . . . . 11		14. Add Missing Item to TLS Alert Registry . . . . . . . . . . . 11
	15. Orphaned Extensions . . . . . . . . . . . . . . . . . . . . . 12		15. TLS Certificate Types . . . . . . . . . . . . . . . . . . . . 12
	16. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . 12		16. Orphaned Extensions . . . . . . . . . . . . . . . . . . . . . 12
	17. Designated Expert Pool . . . . . . . . . . . . . . . . . . . 13		17. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . 12
	18. Security Considerations . . . . . . . . . . . . . . . . . . . 14		18. Designated Expert Pool . . . . . . . . . . . . . . . . . . . 13
	19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		19. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	20. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	20.1. Normative References . . . . . . . . . . . . . . . . . . 14		21. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	20.2. Informative References . . . . . . . . . . . . . . . . . 15		21.1. Normative References . . . . . . . . . . . . . . . . . . 15
			21.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Process Note		1. Process Note
	As the authors of this draft are also the WG chairs, the responsible		As the authors of this draft are also the WG chairs, the responsible
	Area Director has agreed to judge consensus.		Area Director has agreed to judge consensus.
	RFC EDITOR: Please delete section prior to publication.		RFC EDITOR: Please delete section prior to publication.
	2. Introduction		2. Introduction
	This document instructs IANA to make changes to a number of (D)TLS-		This document instructs IANA to make changes to a number of (D)TLS-
	related IANA registries. These changes were almost entirely		related IANA registries. These changes were almost entirely
	motiviated by the development of TLS1.3 [I-D.ietf-tls-tls13].		motivated by the development of TLS1.3 [I-D.ietf-tls-tls13].
	The changes introduced by this document range from simple, e.g.,		The changes introduced by this document range from simple, e.g.,
	adding notes, to commplex, e.g., changing a registry's registration		adding notes, to complex, e.g., changing a registry's registration
	policy. Intsead of listing the changes and their rationale in this,		policy. Instead of listing the changes and their rationale in this,
	the introducotry, section each section provides rationale for the		the introductory, section each section provides rationale for the
	proposed change(s).		proposed change(s).
	This document proposes no changes to the registration policies for		This document proposes no changes to the registration policies for
	TLS Alert [I-D.ietf-tls-tls13], TLS ContentType [I-D.ietf-tls-tls13],		TLS Alert [I-D.ietf-tls-tls13], TLS ContentType [I-D.ietf-tls-tls13],
	TLS HandshakeType [I-D.ietf-tls-tls13], and TLS Certificate Status		TLS HandshakeType [I-D.ietf-tls-tls13], and TLS Certificate Status
	Types [RFC6961] registries; the existing policies (Standards Action		Types [RFC6961] registries; the existing policies (Standards Action
	for the first three; IETF Review for the last), are appropriate for		for the first three; IETF Review for the last), are appropriate for
	these one-byte code points because of their scarcity.		these one-byte code points because of their scarcity.
	3. Add "TLS" to Registry Names		3. Terminology
	For consistency amongst TLS reqgistries, IANA [SHALL prepend/has		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
			4. Add "TLS" to Registry Names
			For consistency amongst TLS registries, IANA [SHALL prepend/has
	prepended] "TLS" to the following registries:		prepended] "TLS" to the following registries:
	o Application-Layer Protocol Negotiation (ALPN) Protocol IDs		o Application-Layer Protocol Negotiation (ALPN) Protocol IDs
	[RFC7301],		[RFC7301],
	o ExtensionType Values,		o ExtensionType Values,
	o Heartbeat Message Types [RFC6520], and		o Heartbeat Message Types [RFC6520], and
	o Heartbeat Modes [RFC6520].		o Heartbeat Modes [RFC6520].
	IANA [SHALL update/has updated] the reference for these four		IANA [SHALL update/has updated] the reference for these four
	registires to also refer to this document. The remainder of this		registries to also refer to this document. The remainder of this
	document will use the registry names with the "TLS" prefix.		document will use the registry names with the "TLS" prefix.
	4. Aligning with RFC 8126		5. Aligning with RFC 8126
	Many of the TLS-related IANA registries were defined prior to		Many of the TLS-related IANA registries were defined prior to
	[RFC8126] where "IETF Consensus" was used instead of the		[RFC8126] where "IETF Consensus" was used instead of the
	RFC8126-defined "IETF Review". To align with the new terminology,		RFC8126-defined "IETF Review". To align with the new terminology,
	IANA [SHALL update/has updated] the following registries to use "IETF		IANA [SHALL update/has updated] the following registries to use "IETF
	Review" in place of "IETF Consensus":		Review" in place of "IETF Consensus":
	o TLS Authorization Data Formats [RFC4680]		o TLS Authorization Data Formats [RFC4680]
	o TLS Supplemental Data Formats (SupplementalDataType) [RFC5878]		o TLS Supplemental Data Formats (SupplementalDataType) [RFC5878]
	skipping to change at page 3, line 41 ¶		skipping to change at page 4, line 4 ¶
	Many of the TLS-related IANA registries were defined prior to		Many of the TLS-related IANA registries were defined prior to
	[RFC8126] where "IETF Consensus" was used instead of the		[RFC8126] where "IETF Consensus" was used instead of the
	RFC8126-defined "IETF Review". To align with the new terminology,		RFC8126-defined "IETF Review". To align with the new terminology,
	IANA [SHALL update/has updated] the following registries to use "IETF		IANA [SHALL update/has updated] the following registries to use "IETF
	Review" in place of "IETF Consensus":		Review" in place of "IETF Consensus":
	o TLS Authorization Data Formats [RFC4680]		o TLS Authorization Data Formats [RFC4680]
	o TLS Supplemental Data Formats (SupplementalDataType) [RFC5878]		o TLS Supplemental Data Formats (SupplementalDataType) [RFC5878]
	This is not a universal change as some registries originally defined		This is not a universal change as some registries originally defined
	with "IETF Consensus" are undergoing other changes either as a result		with "IETF Consensus" are undergoing other changes either as a result
	of this document or [I-D.ietf-tls-rfc4492bis].		of this document or [I-D.ietf-tls-rfc4492bis].
	IANA [SHALL update/has updated] the reference for these two		IANA [SHALL update/has updated] the reference for these two
	registries to also refer to this document.		registries to also refer to this document.
	5. Adding recommended Column		6. Adding recommended Column
	The instructions in this document add a recommended column to many of		The instructions in this document add a recommended column to many of
	the TLS registries to indicate parameters that are generally		the TLS registries to indicate parameters that are generally
	recommended for implementations to support. Adding a recommended		recommended for implementations to support. Adding a recommended
	parameter to a registry or updating a parameter to recommended status		parameter to a registry or updating a parameter to recommended status
	requires standards action. Not all parameters defined in standards		requires standards action. Not all parameters defined in standards
	track documents need to be marked as recommended.		track documents need to be marked as recommended.
	If an item is marked as not recommended it does not necessarily mean		If an item is marked as not recommended it does not necessarily mean
	that it is flawed, rather, it indicates that either the item has not		that it is flawed, rather, it indicates that either the item has not
	been through the IETF consensus process, has limited applicability,		been through the IETF consensus process, has limited applicability,
	or is intended only for specific use cases.		or is intended only for specific use cases.
	6. Session Ticket TLS Extension		7. Session Ticket TLS Extension
	The nomenclature for the registry entries in the TLS ExtensionType		The nomenclature for the registry entries in the TLS ExtensionType
	Values registry correspond to the presentation language field name		Values registry correspond to the presentation language field name
	except for entry 35. To ensure that the values in the registry are		except for entry 35. To ensure that the values in the registry are
	consistently identified in the registry, IANA:		consistently identified in the registry, IANA:
	o [SHALL rename/has renamed] entry 35 to "session_ticket (renamed		o [SHALL rename/has renamed] entry 35 to "session_ticket (renamed
	from "SessionTicket TLS")" [RFC5077].		from "SessionTicket TLS")" [RFC5077].
	o [SHALL add/has added] a reference to this document in the		o [SHALL add/has added] a reference to this document in the
	Reference column for entry 35.		Reference column for entry 35.
	7. TLS ExtensionType Values		8. TLS ExtensionType Values
	Experience has shown that the IETF Review registry policy for TLS		Experience has shown that the IETF Review registry policy for TLS
	Extensions was too strict. Based on WG consensus, the decision was		Extensions was too strict. Based on WG consensus, the decision was
	taken to change the registration policy to Specification Required		taken to change the registration policy to Specification Required
	[RFC8126] while reserving a small part of the code space for		[RFC8126] while reserving a small part of the code space for
	experimental and prviate use. Therefore, IANA [SHALL update/has		experimental and private use. Therefore, IANA [SHALL update/has
	updated] the TLS ExtensionType Values registry to:		updated] the TLS ExtensionType Values registry to:
	o Change the registry policy to:		o Change the registry policy to:
	Values with the first byte in the range 0-254 (decimal) are		Values with the first byte in the range 0-254 (decimal) are
	assigned via Specification Required [RFC8126]. Values with the		assigned via Specification Required [RFC8126]. Values with the
	first byte 255 (decimal) are reserved for Private Use [RFC8126].		first byte 255 (decimal) are reserved for Private Use [RFC8126].
	o Update the "Reference" to also refer to this document.		o Update the "Reference" to also refer to this document.
	o Add the following note:		o Add the following note:
	Note: Experts are to verify that there is in fact a publicly		Note: Experts are to verify that there is in fact a publicly
	available standard.		available standard.
	See Section 17 for additional information about the designated expert		See Section 18 for additional information about the designated expert
	pool.		pool.
	Despite wanting to "loosen" the registration policies for TLS		Despite wanting to "loosen" the registration policies for TLS
	Extensions, it is still useful to indicate in the IANA registry which		Extensions, it is still useful to indicate in the IANA registry which
	extensions the WG recommends be supported. Therefore, IANA [SHALL		extensions the WG recommends be supported. Therefore, IANA [SHALL
	update/has updated] the TLS ExtensionType Values registry to:		update/has updated] the TLS ExtensionType Values registry to:
	o Add a "Recommended" column with the contents as listed below.		o Add a "Recommended" column with the contents as listed below.
	This table has been generated by marking Standards Track RFCs as		This table has been generated by marking Standards Track RFCs as
	"Yes" and all others as "No". Future extensions MUST define the		"Yes" and all others as "No". Future extensions MUST define the
	value of the Recommended column. A Standards Track document		value of the Recommended column. A Standards Track document
	[RFC8126] is required to register an extension with the value		[RFC8126] is REQUIRED to register an extension with the value
	"Yes".		"Yes". IESG action is REQUIRED for a Yes->No transition.
	+----------------------------------------+-------------+		+----------------------------------------+-------------+
	| Extension | Recommended |		| Extension | Recommended |
	+----------------------------------------+-------------+		+----------------------------------------+-------------+
	| server_name | Yes |		| server_name | Yes |
	| | |		| | |
	| max_fragment_length | Yes |		| max_fragment_length | Yes |
	| | |		| | |
	| client_certificate_url | Yes |		| client_certificate_url | Yes |
	| | |		| | |
	skipping to change at page 6, line 27 ¶		skipping to change at page 6, line 34 ¶
	| | |		| | |
	| encrypt_then_mac | Yes |		| encrypt_then_mac | Yes |
	| | |		| | |
	| extended_master_secret | Yes |		| extended_master_secret | Yes |
	| | |		| | |
	| session_ticket | Yes |		| session_ticket | Yes |
	| | |		| | |
	| renegotiation_info | Yes |		| renegotiation_info | Yes |
	+----------------------------------------+-------------+		+----------------------------------------+-------------+
	8. TLS Cipher Suite Registry		9. TLS Cipher Suite Registry
	Experience has shown that the IETF Consensus registry policy for TLS		Experience has shown that the IETF Consensus registry policy for TLS
	Cipher Suites was too strict. Based on WG consensus, the decision		Cipher Suites was too strict. Based on WG consensus, the decision
	was taken to change the TLS Cipher Suite registry's registration		was taken to change the TLS Cipher Suite registry's registration
	policy to Specification Required [RFC8126] while reserving a small		policy to Specification Required [RFC8126] while reserving a small
	part of the code space for experimental and prviate use. Therefore,		part of the code space for experimental and private use. Therefore,
	IANA [SHALL update/has updated] the TLS Cipher Suite registry's		IANA [SHALL update/has updated] the TLS Cipher Suite registry's
	policy as follows:		policy as follows:
	Values with the first byte in the range 0-254 (decimal) are assigned		Values with the first byte in the range 0-254 (decimal) are
	via Specification Required {{RFC8126}}. Values with the first byte		assigned via Specification Required {{RFC8126}}. Values with the
	255 (decimal) are reserved for Private Use {{RFC8126}}.		first byte 255 (decimal) are reserved for Private Use {{RFC8126}}.
	See Section 17 for additional information about the designated expert		See Section 18 for additional information about the designated expert
	pool.		pool.
	The cipher suite registry has grown significantly and will continue		The cipher suite registry has grown significantly and will continue
	to do so. To better guide those not intimately involved in TLS, IANA		to do so. To better guide those not intimately involved in TLS, IANA
	[shall update/has updated] the TLS Cipher Suite registry as follows:		[shall update/has updated] the TLS Cipher Suite registry as follows:
	o Add a "Recommended" column to the TLS Cipher Suite registry. The		o Add a "Recommended" column to the TLS Cipher Suite registry. The
	cipher suites that follow in the two tables are marked as "Yes".		cipher suites that follow in the two tables are marked as "Yes".
	All other cipher suites are marked as "No". Future cipher suites		All other cipher suites are marked as "No". Future cipher suites
	MUST define the value of the Recommended column. A Standards		MUST define the value of the Recommended column. A Standards
	Track document [RFC8126] is required to register a cipher suite		Track document [RFC8126] is REQUIRED to register a cipher suite
	with the value "Yes".		with the value "Yes". IESG action is REQUIRED for a Yes->No
			transition.
	The cipher suites that follow are standards track server-		The cipher suites that follow are standards track server-
	authenticated (and optionally client-authenticated) cipher suites		authenticated (and optionally client-authenticated) cipher suites
	which are currently available in TLS 1.2.		which are currently available in TLS 1.2.
	RFC EDITOR: The previous paragraph is for document reviewers and is		RFC EDITOR: The previous paragraph is for document reviewers and is
	not meant for the registry.		not meant for the registry.
	Cipher Suite Name | Value		Cipher Suite Name | Value
	----------------------------------------------+------------		----------------------------------------------+------------
	skipping to change at page 8, line 4 ¶		skipping to change at page 8, line 20 ¶
	TLS_DHE_PSK_WITH_AES_256_CCM | {0xC0,0xA7}		TLS_DHE_PSK_WITH_AES_256_CCM | {0xC0,0xA7}
	TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | {TBD}		TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | {TBD}
	TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | {TBD}		TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | {TBD}
	TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | {TBD}		TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | {TBD}
	TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 | {TBD}		TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 | {TBD}
	TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAC}		TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAC}
	TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAD}		TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | {0xCC,0xAD}
	Despite the following behavior being crazy, experience has shown that		Despite the following behavior being crazy, experience has shown that
	some customers use the IANA registry as checklist against which to		some customers use the IANA registry as checklist against which to
	measure an implemention's completeness and some implementers blindly		measure an implementation's completeness and some implementers
	implement cipher suites. Therefore, IANA [SHALL add/has added] the		blindly implement cipher suites. Therefore, IANA [SHALL add/has
	following warning to the registry:		added] the following warning to the registry:
	WARNING: Cryptographic algorithms and parameters will be broken or		WARNING: Cryptographic algorithms and parameters will be broken or
	weakened over time. Blindly implementing cipher suites listed		weakened over time. Blindly implementing cipher suites listed
	here is not advised. Implementers and users need to check that		here is not advised. Implementers and users need to check that
	the cryptographic algorithms listed continue to provide the		the cryptographic algorithms listed continue to provide the
	expected level of security.		expected level of security.
	IANA [SHALL add/has added] the following note to ensure that those		IANA [SHALL add/has added] the following note to ensure that those
	that focus on IANA registries are aware that TLS 1.3		that focus on IANA registries are aware that TLS 1.3
	[I-D.ietf-tls-tls13] uses the same registry but defines ciphers		[I-D.ietf-tls-tls13] uses the same registry but defines ciphers
	skipping to change at page 8, line 41 ¶		skipping to change at page 9, line 8 ¶
	cryptographic standpoint.		cryptographic standpoint.
	Note: CCM_8 cipher suites are not marked as Recommended. These		Note: CCM_8 cipher suites are not marked as Recommended. These
	cipher suites have a significantly truncated authentication tag		cipher suites have a significantly truncated authentication tag
	that represents a security trade-off that may not be appropriate		that represents a security trade-off that may not be appropriate
	for general environments.		for general environments.
	Note: The designated expert [RFC8126] only ensures that the		Note: The designated expert [RFC8126] only ensures that the
	specification is publicly available.		specification is publicly available.
	IANA [SHALL uppdate/has updated] the reference for this registry to		IANA [SHALL update/has updated] the reference for this registry to
	also refer to this document.		also refer to this document.
	9. TLS Supported Groups		10. TLS Supported Groups
	Similar to cipher suites, supported groups have proliferated over		Similar to cipher suites, supported groups have proliferated over
	time and some use the registry to measure implementations.		time and some use the registry to measure implementations.
	Therefore, IANA [SHALL add/has added] a "Recommended" column with a		Therefore, IANA [SHALL add/has added] a "Recommended" column with a
	"Yes" for secp256r1, secp384r1, x25519, and x448 while all others are		"Yes" for secp256r1, secp384r1, x25519, and x448 while all others are
	"No". These "Yes" groups are taken from Standards Track RFCs. Not		"No". These "Yes" groups are taken from Standards Track RFCs. Not
	all groups from [I-D.ietf-tls-rfc4492bis], which is standards track,		all groups from [I-D.ietf-tls-rfc4492bis], which is standards track,
	are marked as "Yes"; these groups apply to TLS 1.3		are marked as "Yes"; these groups apply to TLS 1.3
	[I-D.ietf-tls-tls13] and previous versions of TLS. Future supported		[I-D.ietf-tls-tls13] and previous versions of TLS. Future supported
	groups MUST define the value of this column. A Standards Track		groups MUST define the value of this column. A Standards Track
	document [RFC8126] is required to register an entry with the value		document [RFC8126] is REQUIRED to register an entry with the value
	"Yes".		"Yes". IESG action is REQUIRED for a Yes->No transition.
	IANA [SHALL add/has added] the following note:		IANA [SHALL add/has added] the following note:
	Note: Supported Groups marked as "Yes" are those allocated via		Note: Supported Groups marked as "Yes" are those allocated via
	Standards Track RFCs. Supported Groups marked as "No" are not;		Standards Track RFCs. Supported Groups marked as "No" are not;
	supported groups marked "No" range from "good" to "bad" from a		supported groups marked "No" range from "good" to "bad" from a
	cryptographic standpoint.		cryptographic standpoint.
	Note: The designated expert [RFC8126] only ensures that the		Note: The designated expert [RFC8126] only ensures that the
	specification is publicly available.		specification is publicly available.
	Despite the following behavior being crazy, experience has shown that		Despite the following behavior being crazy, experience has shown that
	some customers use the IANA registry as checklist against which to		some customers use the IANA registry as checklist against which to
	measure an implemention's completeness and some implementers blindly		measure an implementation's completeness and some implementers
	implement cipher supported. Therefore, IANA [SHALL add/has added]		blindly implement cipher supported. Therefore, IANA [SHALL add/has
	the following warning to the registry:		added] the following warning to the registry:
	WARNING: Cryptographic algorithms and parameters will be broken or		WARNING: Cryptographic algorithms and parameters will be broken or
	weakened over time. Blindly implementing cipher suites listed		weakened over time. Blindly implementing cipher suites listed
	here is not advised. Implementers and users need to check that		here is not advised. Implementers and users need to check that
	the cryptographic algorithms listed continue to provide the		the cryptographic algorithms listed continue to provide the
	expected level of security.		expected level of security.
	IANA [SHALL update/has updated] the reference for this registry to		IANA [SHALL update/has updated] the reference for this registry to
	also refer to this document.		also refer to this document.
	The value 0 (0x0000) is to be marked as reserved.		The value 0 (0x0000) is to be marked as reserved.
	10. TLS ClientCertificateType Identifiers		11. TLS ClientCertificateType Identifiers
	Experience has shown that the IETF Consensus registry policy for TLS		Experience has shown that the IETF Consensus registry policy for TLS
	ClientCertificateType Identifers is too strict. Based on WG		ClientCertificateType Identifiers is too strict. Based on WG
	consensus, the decision was taken to change registration policy to		consensus, the decision was taken to change registration policy to
	Specification Required [RFC8126] while reserving a small part of the		Specification Required [RFC8126] while reserving a small part of the
	code space for experimental and prviate use. Therefore, IANA [SHALL		code space for experimental and prviate use. Therefore, IANA [SHALL
	update/has updated] the TLS Cipher Suite registry's policy as		update/has updated] the TLS Cipher Suite registry's policy as
	follows:		follows:
	Values in the range 0-223 are assigned via Specification Required		Values in the range 0-223 are assigned via Specification Required
	{{RFC8126}}. Values 224-255 are reserved for Private Use.		{{RFC8126}}. Values 224-255 are reserved for Private Use.
	See Section 17 for additional information about the designated expert		See Section 18 for additional information about the designated expert
	pool.		pool.
	IANA [SHALL add/has added] the following notes:		IANA [SHALL add/has added] the following notes:
	Note: The designated expert [RFC8126] only ensures that the		Note: The designated expert [RFC8126] only ensures that the
	specification is publicly available.		specification is publicly available.
	Note: ClientCertificateType Identifers marked as "Yes" are those		Note: ClientCertificateType Identifiers marked as "Yes" are those
	allocated via Standards Track RFCs. ClientCertificateTypes marked		allocated via Standards Track RFCs. ClientCertificateTypes marked
	as "No" are not.		as "No" are not.
	11. New Session Ticket TLS Handshake Message Type		12. New Session Ticket TLS Handshake Message Type
	To align with TLS implementations and to align the naming		To align with TLS implementations and to align the naming
	nomenclature with other Handshake message types, IANA:		nomenclature with other Handshake message types, IANA:
	o [SHALL rename/has renamed] entry 4 in the TLS HandshakeType		o [SHALL rename/has renamed] entry 4 in the TLS HandshakeType
	registry to "new_session_ticket (renamed from NewSessionTicket)"		registry to "new_session_ticket (renamed from NewSessionTicket)"
	[RFC5077].		[RFC5077].
	o [SHALL add/has added] a reference to this document in the		o [SHALL add/has added] a reference to this document in the
	Reference column for entry 4 in the TLS HandshakeType registry.		Reference column for entry 4 in the TLS HandshakeType registry.
	12. TLS Exporter Label Registry		13. TLS Exporter Label Registry
	To aid those reviewers who start with the IANA registry, IANA [SHALL		To aid those reviewers who start with the IANA registry, IANA [SHALL
	add/has added]:		add/has added]:
	o The following note to the TLS Exporter Label Registry:		o The following note to the TLS Exporter Label Registry:
	Note: [RFC5705] defines keying material exporters for TLS in terms		Note: [RFC5705] defines keying material exporters for TLS in terms
	of the TLS PRF. [I-D.ietf-tls-tls13] replaced the PRF with HKDF,		of the TLS PRF. [I-D.ietf-tls-tls13] replaced the PRF with HKDF,
	thus requiring a new construction. The exporter interface remains		thus requiring a new construction. The exporter interface remains
	the same, however the value is computed different.		the same, however the value is computed different.
	o A "Recommended" column to the TLS Exporter Label registry. The		o A "Recommended" column to the TLS Exporter Label registry. The
	table that follows has been generated by marking Standards Track		table that follows has been generated by marking Standards Track
	RFCs as "Yes" and all others as "No". Future exporters MUST		RFCs as "Yes" and all others as "No". Future exporters MUST
	define the value of this column. A Standards Track document		define the value of this column. A Standards Track document
	[RFC8126] is required to register an extension with the value		[RFC8126] is REQUIRED to register an extension with the value
	"Yes".		"Yes". IESG action is REQUIRED for a Yes->No transition.
	Exporter Value		Exporter Value
	-------------------------------		-------------------------------
	client finished		client finished
	server finished		server finished
	master secret		master secret
	key expansion		key expansion
	client EAP encryption		client EAP encryption
	ttls keying material		ttls keying material
	ttls challenge		ttls challenge
	skipping to change at page 11, line 34 ¶		skipping to change at page 11, line 41 ¶
	"EXPORTER". IANA MUST also verify that one label is not a prefix		"EXPORTER". IANA MUST also verify that one label is not a prefix
	of any other label. For example, labels "key" or "master		of any other label. For example, labels "key" or "master
	secretary" are forbidden.		secretary" are forbidden.
	Note: Exporters Labels marked as "Yes" are those allocated via		Note: Exporters Labels marked as "Yes" are those allocated via
	Standards Track RFCs. Exporter Labels marked as "No" are not.		Standards Track RFCs. Exporter Labels marked as "No" are not.
	IANA [SHALL update/has updated] the reference for this registry to		IANA [SHALL update/has updated] the reference for this registry to
	also refer to this document.		also refer to this document.
	13. Add Missing Item to TLS Alert Registry		14. Add Missing Item to TLS Alert Registry
	IANA [SHALL add/has added] the following entry to the TLS Alert		IANA [SHALL add/has added] the following entry to the TLS Alert
	Registry; the entry was omitted from the IANA instructions in		Registry; the entry was omitted from the IANA instructions in
	[RFC7301]):		[RFC7301]:
	120 no_application_protocol Y [RFC7301]		120 no_application_protocol Y [RFC7301]
	14. TLS Certificate Types		15. TLS Certificate Types
	Experience has shown that the IETF Consensus registry policy for TLS		Experience has shown that the IETF Consensus registry policy for TLS
	Certificate Types is too strict. Based on WG consensus, the decision		Certificate Types is too strict. Based on WG consensus, the decision
	was taken to change registration policy to Specification Required		was taken to change registration policy to Specification Required
	[RFC8126] while reserving a small part of the code space for		[RFC8126] while reserving a small part of the code space for
	experimental and prviate use. Therefore, IANA [SHALL add/has added]		experimental and private use. Therefore, IANA [SHALL add/has added]
	a "Recommended" column to the registry. X.509 and Raw Public Key are		a "Recommended" column to the registry. X.509 and Raw Public Key are
	"Yes". All others are "No". A Standards Track document [RFC8126] is		"Yes". All others are "No". A Standards Track document [RFC8126] is
	required to register a certificate type with the value "Yes". Future		required to register a certificate type with the value "Yes". Future
	Certificate Types MUST define the value of this column. A Standards		Certificate Types MUST define the value of this column. A Standards
	Track document [RFC8126] is required to register an entry with the		Track document [RFC8126] is REQUIRED to register an entry with the
	value "Yes".		value "Yes". IESG action is REQUIRED for a Yes->No transition.
	See Section 17 for additional information about the designated expert		See Section 18 for additional information about the designated expert
	pool.		pool.
	IANA [SHALL add/has added] the following note:		IANA [SHALL add/has added] the following note:
	Note: Certificate Types marked as "Yes" are those allocated via		Note: Certificate Types marked as "Yes" are those allocated via
	Standards Track RFCs. Certificate Types marked as "No" are not.		Standards Track RFCs. Certificate Types marked as "No" are not.
	IANA [SHALL update/has updated] the reference for this registry to		IANA [SHALL update/has updated] the reference for this registry to
	also refer this document.		also refer this document.
	15. Orphaned Extensions		16. Orphaned Extensions
	To make it clear that (D)TLS 1.3 has orphaned certain extensions		To make it clear that (D)TLS 1.3 has orphaned certain extensions
	(i.e., some extensions are only applicable to version of (D)TLS prior		(i.e., some extensions are only applicable to version of (D)TLS prior
	to 1.3), IANA [SHALL add/has added] the following note to the TLS		to 1.3), IANA [SHALL add/has added] the following note to the TLS
	ExtensionType Values registry:		ExtensionType Values registry:
	Note: The following extensions are only applicable to (D)TLS		Note: The following extensions are only applicable to (D)TLS
	protocol vesions prior to 1.3: trusted_ca_keys, truncated_hmac,		protocol versions prior to 1.3: trusted_ca_keys, truncated_hmac,
	ec_point_formats, srp, status_request_v2, encrypt_then_mac,		user_mapping, cert_type, ec_point_formats, srp, status_request_v2,
	extended_master_secret, session_ticket, and renegotiation_info.		encrypt_then_mac, extended_master_secret, session_ticket, and
	These extensions are not applicable to (D)TLS 1.3.		renegotiation_info. These extensions are not applicable to (D)TLS
			1.3.
	16. Orphaned Registries		17. Orphaned Registries
	To make it clear that (D)TLS 1.3 has orphaned certain registries		To make it clear that (D)TLS 1.3 has orphaned certain registries
	(i.e., they are only applicable to version of (D)TLS protocol		(i.e., they are only applicable to version of (D)TLS protocol
	versions prior to 1.3), IANA:		versions prior to 1.3), IANA:
	o [SHALL add/has added] the following to the TLS Compression Method		o [SHALL add/has added] the following to the TLS Compression Method
	Identifiers registry [RFC3749]:		Identifiers registry [RFC3749]:
	Note: Value 0 (NULL) is the only value in this registry applicable		Note: Value 0 (NULL) is the only value in this registry applicable
	to (D)TLS protocol version 1.3 or later.		to (D)TLS protocol version 1.3 or later.
	skipping to change at page 13, line 11 ¶		skipping to change at page 13, line 24 ¶
	o [SHALL update/has updated] the "Reference" field in the TLS		o [SHALL update/has updated] the "Reference" field in the TLS
	Compression Method Identifiers, TLS HashAlgorithm and TLS		Compression Method Identifiers, TLS HashAlgorithm and TLS
	SignatureAlgorithm registries to also refer to this document.		SignatureAlgorithm registries to also refer to this document.
	o [SHALL update/has updated] the TLS HashAlgorithm Registry to list		o [SHALL update/has updated] the TLS HashAlgorithm Registry to list
	values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry		values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry
	to list values 4-223 as "Reserved".		to list values 4-223 as "Reserved".
	Despite the fact that the HashAlgorithm and SignarureAlgorithm		Despite the fact that the HashAlgorithm and SignarureAlgorithm
	registries are orphaned, it is still import to warn implementers of		registries are orphaned, it is still import to warn implementers of
	pre-TLS1.3 implmentations about the dangers of blinding implementing		pre-TLS1.3 implementations about the dangers of blinding implementing
	cryptographic algorithms. Therefore, IANA [SHALL add/has added] the		cryptographic algorithms. Therefore, IANA [SHALL add/has added] the
	following warning to the HashAlgorithm and SignatureAlgorithm:		following warning to the HashAlgorithm and SignatureAlgorithm:
	WARNING: Cryptographic algorithms and parameters will be broken or		WARNING: Cryptographic algorithms and parameters will be broken or
	weakened over time. Blindly implementing cipher suites listed		weakened over time. Blindly implementing cipher suites listed
	here is not advised. Implementers and users need to check that		here is not advised. Implementers and users need to check that
	the cryptographic algorithms listed continue to provide the		the cryptographic algorithms listed continue to provide the
	expected level of security.		expected level of security.
	17. Designated Expert Pool		18. Designated Expert Pool
	Specification Required [RFC8126] registry requests are registered		Specification Required [RFC8126] registry requests are registered
	after a three-week review period on the (tbd but maybe tls-reg-		after a three-week review period on the (tbd but maybe tls-reg-
	review@ietf.org) mailing list, on the advice of one or more		review@ietf.org) mailing list, on the advice of one or more
	Designated Experts. However, to allow for the allocation of values		Designated Experts. However, to allow for the allocation of values
	prior to publication, the Designated Experts may approve registration		prior to publication, the Designated Experts may approve registration
	once they are satisfied that such a specification will be published.		once they are satisfied that such a specification will be published.
	Registration requests sent to the mailing list for review SHOULD use		Registration requests sent to the mailing list for review SHOULD use
	an appropriate subject (e.g., "Request to register value in TLS bar		an appropriate subject (e.g., "Request to register value in TLS bar
	skipping to change at page 14, line 13 ¶		skipping to change at page 14, line 25 ¶
	list.		list.
	It is suggested that multiple Designated Experts be appointed who are		It is suggested that multiple Designated Experts be appointed who are
	able to represent the perspectives of different applications using		able to represent the perspectives of different applications using
	this specification, in order to enable broadly informed review of		this specification, in order to enable broadly informed review of
	registration decisions. In cases where a registration decision could		registration decisions. In cases where a registration decision could
	be perceived as creating a conflict of interest for a particular		be perceived as creating a conflict of interest for a particular
	Expert, that Expert SHOULD defer to the judgment of the other		Expert, that Expert SHOULD defer to the judgment of the other
	Experts.		Experts.
	18. Security Considerations		19. Security Considerations
	The change to Specification Required from IETF Review lowers the		The change to Specification Required from IETF Review lowers the
	amount of review provided by the WG for cipher suites and supported		amount of review provided by the WG for cipher suites and supported
	groups. This change reflects reality in that the WG essentially		groups. This change reflects reality in that the WG essentially
	provided no cryptographic review of the cipher suites or supported		provided no cryptographic review of the cipher suites or supported
	groups. This was especially true of national cipher suites.		groups. This was especially true of national cipher suites.
	Recommended algorithms regarded as secure for general use at the time		Recommended algorithms regarded as secure for general use at the time
	of registration, however, cryptographic algorithms and parameters		of registration, however, cryptographic algorithms and parameters
	will be broken or weakened over time. It is possible that the		will be broken or weakened over time. It is possible that the
	recommended status in the registry lags behind the most recent		recommended status in the registry lags behind the most recent
	advances in cryptanalysis. Implementers and users need to check that		advances in cryptanalysis. Implementers and users need to check that
	the cryptographic algorithms listed continue to provide the expected		the cryptographic algorithms listed continue to provide the expected
	level of security.		level of security.
	Designated experts ensure the specification is publicly available.		Designated experts ensure the specification is publicly available.
	They may provide more in depth reviews. Their review should not be		They may provide more in depth reviews. Their review should not be
	taken as an endorsement of the cipher suite, extension, supported		taken as an endorsement of the cipher suite, extension, supported
	group, etc.		group, etc.
	19. IANA Considerations		20. IANA Considerations
	This document is entirely about changes to TLS-related IANA		This document is entirely about changes to TLS-related IANA
	registries.		registries.
	20. References		21. References
	20.1. Normative References		21.1. Normative References
	[I-D.ietf-tls-tls13]		[I-D.ietf-tls-tls13]
	Rescorla, E., "The Transport Layer Security (TLS) Protocol		Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", draft-ietf-tls-tls13-21 (work in progress),		Version 1.3", draft-ietf-tls-tls13-22 (work in progress),
	July 2017.		November 2017.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
			editor.org/info/rfc2119>.
	[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol		[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
	Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May		Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May
	2004, <https://www.rfc-editor.org/info/rfc3749>.		2004, <https://www.rfc-editor.org/info/rfc3749>.
	[RFC4680] Santesson, S., "TLS Handshake Message for Supplemental		[RFC4680] Santesson, S., "TLS Handshake Message for Supplemental
	Data", RFC 4680, DOI 10.17487/RFC4680, October 2006,		Data", RFC 4680, DOI 10.17487/RFC4680, October 2006,
	<https://www.rfc-editor.org/info/rfc4680>.		<https://www.rfc-editor.org/info/rfc4680>.
	[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,		[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
	skipping to change at page 15, line 48 ¶		skipping to change at page 16, line 20 ¶
	[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	"Transport Layer Security (TLS) Application-Layer Protocol		"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,		Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
	July 2014, <https://www.rfc-editor.org/info/rfc7301>.		July 2014, <https://www.rfc-editor.org/info/rfc7301>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	20.2. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			21.2. Informative References
	[I-D.ietf-tls-rfc4492bis]		[I-D.ietf-tls-rfc4492bis]
	Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic		Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
	Curve Cryptography (ECC) Cipher Suites for Transport Layer		Curve Cryptography (ECC) Cipher Suites for Transport Layer
	Security (TLS) Versions 1.2 and Earlier", draft-ietf-tls-		Security (TLS) Versions 1.2 and Earlier", draft-ietf-tls-
	rfc4492bis-17 (work in progress), May 2017.		rfc4492bis-17 (work in progress), May 2017.
	[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)		[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
	Multiple Certificate Status Request Extension", RFC 6961,		Multiple Certificate Status Request Extension", RFC 6961,
	DOI 10.17487/RFC6961, June 2013, <https://www.rfc-		DOI 10.17487/RFC6961, June 2013, <https://www.rfc-
End of changes. 52 change blocks.
	89 lines changed or deleted		108 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/