< draft-ietf-tls-iana-registry-updates-03.txt		draft-ietf-tls-iana-registry-updates-04.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 January 3, 2018		Intended status: Standards Track February 15, 2018
	Expires: July 7, 2018		Expires: August 19, 2018
	IANA Registry Updates for TLS and DTLS		IANA Registry Updates for TLS and DTLS
	draft-ietf-tls-iana-registry-updates-03		draft-ietf-tls-iana-registry-updates-04
	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 July 7, 2018.		This Internet-Draft will expire on August 19, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Add "TLS" to Registry Names . . . . . . . . . . . . . . . . . 3		4. Add "TLS" to Registry Names . . . . . . . . . . . . . . . . . 3
	5. Aligning with RFC 8126 . . . . . . . . . . . . . . . . . . . 3		5. Aligning with RFC 8126 . . . . . . . . . . . . . . . . . . . 3
	6. Adding recommended Column . . . . . . . . . . . . . . . . . . 4		6. Adding Recommended Column . . . . . . . . . . . . . . . . . . 4
	7. Session Ticket TLS Extension . . . . . . . . . . . . . . . . 4		7. Session Ticket TLS Extension . . . . . . . . . . . . . . . . 4
	8. TLS ExtensionType Values . . . . . . . . . . . . . . . . . . 4		8. TLS ExtensionType Values . . . . . . . . . . . . . . . . . . 4
	9. TLS Cipher Suite Registry . . . . . . . . . . . . . . . . . . 6		9. TLS Cipher Suite Registry . . . . . . . . . . . . . . . . . . 7
	10. TLS Supported Groups . . . . . . . . . . . . . . . . . . . . 9		10. TLS Supported Groups . . . . . . . . . . . . . . . . . . . . 10
	11. TLS ClientCertificateType Identifiers . . . . . . . . . . . . 10		11. TLS ClientCertificateType Identifiers . . . . . . . . . . . . 10
	12. New Session Ticket TLS Handshake Message Type . . . . . . . . 10		12. New Session Ticket TLS Handshake Message Type . . . . . . . . 11
	13. TLS Exporter Label Registry . . . . . . . . . . . . . . . . . 10		13. TLS Exporter Label Registry . . . . . . . . . . . . . . . . . 11
	14. Add Missing Item to TLS Alert Registry . . . . . . . . . . . 11		14. Add Missing Item to TLS Alert Registry . . . . . . . . . . . 13
	15. TLS Certificate Types . . . . . . . . . . . . . . . . . . . . 12		15. TLS Certificate Types . . . . . . . . . . . . . . . . . . . . 13
	16. Orphaned Extensions . . . . . . . . . . . . . . . . . . . . . 12		16. Orphaned Extensions . . . . . . . . . . . . . . . . . . . . . 13
	17. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . 12		17. Orphaned Registries . . . . . . . . . . . . . . . . . . . . . 14
	18. Designated Expert Pool . . . . . . . . . . . . . . . . . . . 13		18. Designated Expert Pool . . . . . . . . . . . . . . . . . . . 14
	19. Security Considerations . . . . . . . . . . . . . . . . . . . 14		19. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	21. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		21. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	21.1. Normative References . . . . . . . . . . . . . . . . . . 15		21.1. Normative References . . . . . . . . . . . . . . . . . . 16
	21.2. Informative References . . . . . . . . . . . . . . . . . 16		21.2. Informative References . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	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
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 11 ¶
	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.
	6. 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.
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	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 notes:
	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. An Internet Draft that is posted and never
			published or a standard in another standards body, industry
			consortium, university site, etc. suffices.
			Note: As specified in [RFC8126], assignments made in the Private Use
			space are not generally useful for broad interoperability. It is
			the responsibility of those making use of the Private Use range to
			ensure that no conflicts occur (within the intended scope of use).
			For widespread experiments, temporary reservations are available.
	See Section 18 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. In order to register an
	[RFC8126] is REQUIRED to register an extension with the value		extension with the value "Yes", a Standards Track document
	"Yes". IESG action is REQUIRED for a Yes->No transition.		[RFC8126] is REQUIRED. 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 34 ¶		skipping to change at page 6, line 43 ¶
	| | |		| | |
	| 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 |
	+----------------------------------------+-------------+		+----------------------------------------+-------------+
			NOTE: The following is from [I-D.ietf-tls-tls13] and is included
			here to ensure aligment between these specifications.
			[I-D.ietf-tls-tls13] also uses the TLS ExtensionType Registry
			originally created in [RFC4366]. IANA has updated it to reference
			this document. The registry and its allocation policy is listed
			below:
			o IANA [SHALL update/has updated] this registry to include the
			"key_share", "pre_shared_key", "psk_key_exchange_modes",
			"early_data", "cookie", "supported_versions",
			"certificate_authorities", "oid_filters", "post_handshake_auth",
			and "signature_algorithms_certs", extensions with the values
			defined in this document and the Recommended value of "Yes".
			o IANA [SHALL update/has updated] this registry to include a "TLS
			1.3" column which lists the messages in which the extension may
			appear. This column [SHALL be/has been] initially populated from
			the table in Section 4.2 of [I-D.ietf-tls-tls13] with any
			extension not listed there marked as "-" to indicate that it is
			not used by TLS 1.3.
	9. 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 private 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:
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 43 ¶
	See Section 18 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. In order to
	Track document [RFC8126] is REQUIRED to register a cipher suite		register an extension with the value "Yes, a Standards Track
	with the value "Yes". IESG action is REQUIRED for a Yes->No		document [RFC8126] is REQUIRED. IESG action is REQUIRED for a
	transition.		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 18 ¶		skipping to change at page 8, line 44 ¶
	TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | {0x00,0xAB}		TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | {0x00,0xAB}
	TLS_DHE_PSK_WITH_AES_128_CCM | {0xC0,0xA6}		TLS_DHE_PSK_WITH_AES_128_CCM | {0xC0,0xA6}
	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 misguided, experience has shown
	some customers use the IANA registry as checklist against which to		that some customers use the IANA registry as checklist against which
	measure an implementation's completeness and some implementers		to measure an implementation's completeness and some implementers
	blindly implement cipher suites. Therefore, IANA [SHALL add/has		blindly implement cipher suites. Therefore, IANA [SHALL add/has
	added] 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 add/has added] the following note to ensure that those		IANA [SHALL add/has added] the following note to ensure that those
	skipping to change at page 8, line 49 ¶		skipping to change at page 9, line 26 ¶
	used with TLS 1.3.		used with TLS 1.3.
	IANA [SHALL add/has added] the following notes to document the rules		IANA [SHALL add/has added] the following notes to document the rules
	for populating the Recommended column:		for populating the Recommended column:
	Note: Cipher suites marked as "Yes" are those allocated via		Note: Cipher suites marked as "Yes" are those allocated via
	Standards Track RFCs. Cipher suites marked as "No" are not;		Standards Track RFCs. Cipher suites marked as "No" are not;
	cipher suites marked "No" range from "good" to "bad" from a		cipher suites marked "No" range from "good" to "bad" from a
	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.
			IANA [SHALL add/has added] the following notes for additional
			information:
	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. An Internet Draft that is
			posted and never published or a standard in another standards
			body, industry consortium, university site, etc. suffices.
			Note: As specified in [RFC8126], assignments made in the Private Use
			space are not generally useful for broad interoperability. It is
			the responsibility of those making use of the Private Use range to
			ensure that no conflicts occur (within the intended scope of use).
			For widespread experiments, temporary reservations are available.
	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.
	10. 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. In order to register an
	document [RFC8126] is REQUIRED to register an entry with the value		extension with the value "Yes", a Standards Track document [RFC8126]
	"Yes". IESG action is REQUIRED for a Yes->No transition.		is REQUIRED. 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. An Internet Draft that is
			posted and never published or a standard in another standards
			body, industry consortium, university site, etc. suffices.
	Despite the following behavior being crazy, experience has shown that		Despite the following behavior being misguided, experience has shown
	some customers use the IANA registry as checklist against which to		that some customers use the IANA registry as checklist against which
	measure an implementation's completeness and some implementers		to measure an implementation's completeness and some implementers
	blindly implement cipher supported. Therefore, IANA [SHALL add/has		blindly implement groups supported. Therefore, IANA [SHALL add/has
	added] 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.
	skipping to change at page 10, line 24 ¶		skipping to change at page 11, line 18 ¶
	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 18 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. An Internet Draft that is
			posted and never published or a standard in another standards
			body, industry consortium, university site, etc. suffices.
			Note: As specified in [RFC8126], assignments made in the Private Use
			space are not generally useful for broad interoperability. It is
			the responsibility of those making use of the Private Use range to
			ensure that no conflicts occur (within the intended scope of use).
			For widespread experiments, temporary reservations are available.
	Note: ClientCertificateType Identifiers 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.
	12. 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:
	skipping to change at page 11, line 8 ¶		skipping to change at page 12, line 13 ¶
	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. In order to register an
	[RFC8126] is REQUIRED to register an extension with the value		extension with the value "Yes", a Standards Track document
	"Yes". IESG action is REQUIRED for a Yes->No transition.		[RFC8126] is REQUIRED. IESG action is REQUIRED for a Yes->No
			transition.
	Exporter Value		Exporter Value | Recommended |
	-------------------------------		--------------------------------|-------------|
	client finished		client finished | Yes |
	server finished		server finished | Yes |
	master secret		master secret | Yes |
	key expansion		key expansion | Yes |
	client EAP encryption		client EAP encryption | Yes |
	ttls keying material		ttls keying material | Yes |
	ttls challenge		ttls challenge | Yes |
	EXTRACTOR-dtls_srtp		EXTRACTOR-dtls_srtp | Yes |
	EXPORTER_DTLS_OVER_SCTP		EXPORTER_DTLS_OVER_SCTP | Yes |
	EXPORTER: teap session key seed		EXPORTER: teap session key seed | Yes |
	To provide additional information for the designated experts, IANA		To provide additional information for the designated experts, IANA
	[SHALL add/has added] the following note:		[SHALL add/has added] the following note:
	Note: The designated expert [RFC8126] ensures that the specification		Note: The designated expert [RFC8126] ensures that the specification
	is publicly available. The expert also verifies that the label is		is publicly available. An Internet Draft that is posted and never
	a string consisting of printable ASCII characters beginning with		published or a standard in another standards body, industry
	"EXPORTER". IANA MUST also verify that one label is not a prefix		consortium, university site, etc. suffices. The expert also
	of any other label. For example, labels "key" or "master		verifies that the label is a string consisting of printable ASCII
	secretary" are forbidden.		characters beginning with "EXPORTER". IANA MUST also verify that
			one label is not a prefix of any other label. For example, labels
			"key" or "master 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.
	14. 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
	skipping to change at page 12, line 13 ¶		skipping to change at page 13, line 21 ¶
	120 no_application_protocol Y [RFC7301]		120 no_application_protocol Y [RFC7301]
	15. 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 private 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". In order to register an extension with
	required to register a certificate type with the value "Yes". Future		the value "Yes", a Standards Track document [RFC8126] is REQUIRED.
	Certificate Types MUST define the value of this column. A Standards		Future Certificate Types MUST define the value of this column. A
	Track document [RFC8126] is REQUIRED to register an entry with the		Standards Track document [RFC8126] is REQUIRED to register an entry
	value "Yes". IESG action is REQUIRED for a Yes->No transition.		with the value "Yes". IESG action is REQUIRED for a Yes->No
			transition.
	See Section 18 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
	skipping to change at page 13, line 22 ¶		skipping to change at page 14, line 31 ¶
	protocol versions prior to 1.3.		protocol versions prior to 1.3.
	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 SignatureAlgorithm
	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 implementations 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.
	18. 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 tls-reg-review@ietf.org
	review@ietf.org) mailing list, on the advice of one or more		mailing list, on the advice of one or more Designated Experts.
	Designated Experts. However, to allow for the allocation of values		However, to allow for the allocation of values prior to publication,
	prior to publication, the Designated Experts may approve registration		the Designated Experts may approve registration once they are
	once they are satisfied that such a specification will be published.		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
	registry").		registry").
	Within the review period, the Designated Experts will either approve		Within the review period, the Designated Experts will either approve
	or deny the registration request, communicating this decision to the		or deny the registration request, communicating this decision to the
	review list and IANA. Denials SHOULD include an explanation and, if		review list and IANA. Denials SHOULD include an explanation and, if
	applicable, suggestions as to how to make the request successful.		applicable, suggestions as to how to make the request successful.
	Registration requests that are undetermined for a period longer than		Registration requests that are undetermined for a period longer than
	skipping to change at page 14, line 33 ¶		skipping to change at page 15, line 43 ¶
	Experts.		Experts.
	19. 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 are regarded as secure for general use at the
	of registration, however, cryptographic algorithms and parameters		time of registration, however, cryptographic algorithms and
	will be broken or weakened over time. It is possible that the		parameters will be broken or weakened over time. It is possible that
	recommended status in the registry lags behind the most recent		the 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.
	20. 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.
	21. References		21. References
	21.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-22 (work in progress),		Version 1.3", draft-ietf-tls-tls13-23 (work in progress),
	November 2017.		January 2018.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	editor.org/info/rfc2119>.		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>.
	skipping to change at page 16, line 32 ¶		skipping to change at page 17, line 38 ¶
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	21.2. Informative References		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.
			[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
			and T. Wright, "Transport Layer Security (TLS)
			Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
			<https://www.rfc-editor.org/info/rfc4366>.
	[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-
	editor.org/info/rfc6961>.		editor.org/info/rfc6961>.
	Authors' Addresses		Authors' Addresses
	Joe Salowey		Joe Salowey
	Tableau Software		Tableau Software
	Email: joe@salowey.net		Email: joe@salowey.net
	Sean Turner		Sean Turner
	sn3rd		sn3rd
	Email: sean@sn3rd.com		Email: sean@sn3rd.com
End of changes. 31 change blocks.
	83 lines changed or deleted		143 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/