< draft-ietf-emu-eaptlscert-02.txt		draft-ietf-emu-eaptlscert-03.txt >
	Network Working Group M. Sethi		Network Working Group M. Sethi
	Internet-Draft J. Mattsson		Internet-Draft J. Mattsson
	Intended status: Informational Ericsson		Intended status: Informational Ericsson
	Expires: September 17, 2020 S. Turner		Expires: November 10, 2020 S. Turner
	sn3rd		sn3rd
	March 16, 2020		May 9, 2020
	Handling Large Certificates and Long Certificate Chains		Handling Large Certificates and Long Certificate Chains
	in TLS-based EAP Methods		in TLS-based EAP Methods
	draft-ietf-emu-eaptlscert-02		draft-ietf-emu-eaptlscert-03
	Abstract		Abstract
	EAP-TLS and other TLS-based EAP methods are widely deployed and used		EAP-TLS and other TLS-based EAP methods are widely deployed and used
	for network access authentication. Large certificates and long		for network access authentication. Large certificates and long
	certificate chains combined with authenticators that drop an EAP		certificate chains combined with authenticators that drop an EAP
	session after only 40 - 50 round-trips is a major deployment problem.		session after only 40 - 50 round-trips is a major deployment problem.
	This memo looks at the this problem in detail and describes the		This document looks at the this problem in detail and describes the
	potential solutions available.		potential solutions available.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 September 17, 2020.		This Internet-Draft will expire on November 10, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 14 ¶		skipping to change at page 2, line 14 ¶
	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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Experience with Deployments . . . . . . . . . . . . . . . . . 4		3. Experience with Deployments . . . . . . . . . . . . . . . . . 4
	4. Handling of Large Certificates and Long Certificate Chains . 4		4. Handling of Large Certificates and Long Certificate Chains . 5
	4.1. Updating Certificates and Certificate Chains . . . . . . 5		4.1. Updating Certificates and Certificate Chains . . . . . . 5
	4.1.1. Guidelines for certificates . . . . . . . . . . . . . 5		4.1.1. Guidelines for certificates . . . . . . . . . . . . . 5
	4.2. Updating TLS and EAP-TLS Code . . . . . . . . . . . . . . 6		4.2. Updating TLS and EAP-TLS Code . . . . . . . . . . . . . . 6
	4.2.1. Pre-distributing and Omitting CA Certificates . . . . 6		4.2.1. Pre-distributing and Omitting CA Certificates . . . . 6
	4.2.2. Caching Certificates . . . . . . . . . . . . . . . . 7		4.2.2. URLs for Client Certificates . . . . . . . . . . . . 7
	4.2.3. Compressing Certificates . . . . . . . . . . . . . . 7		4.2.3. Compact TLS 1.3 . . . . . . . . . . . . . . . . . . . 7
	4.2.4. Suppressing Intermediate Certificates . . . . . . . . 8		4.2.4. Caching Certificates . . . . . . . . . . . . . . . . 7
	4.2.5. Using Fewer Intermediate Certificates . . . . . . . . 8		4.2.5. Compressing Certificates . . . . . . . . . . . . . . 8
	4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 8		4.2.6. Suppressing Intermediate Certificates . . . . . . . . 8
			4.2.7. Using Fewer Intermediate Certificates . . . . . . . . 8
			4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . 9		7.1. Normative References . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . 11
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The Extensible Authentication Protocol (EAP), defined in [RFC3748],		The Extensible Authentication Protocol (EAP), defined in [RFC3748],
	provides a standard mechanism for support of multiple authentication		provides a standard mechanism for support of multiple authentication
	methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216]		methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216]
	[I-D.ietf-emu-eap-tls13] relies on TLS [RFC8446] to provide strong		[I-D.ietf-emu-eap-tls13] relies on TLS [RFC8446] to provide strong
	mutual authentication with certificates [RFC5280] and is widely		mutual authentication with certificates [RFC5280] and is widely
	deployed and often used for network access authentication. There are		deployed and often used for network access authentication. There are
	also many other TLS-based EAP methods, such as FAST [RFC4851], TTLS		also many other TLS-based EAP methods, such as Flexible
	[RFC5281], TEAP [RFC7170], and possibly many vendor specific EAP		Authentication via Secure Tunneling (EAP-FAST) [RFC4851], Tunneled
	methods.		Transport Layer Security (EAP-TTLS) [RFC5281], Tunnel Extensible
			Authentication Protocol (EAP-TEAP) [RFC7170], and possibly many
			vendor specific EAP methods.
	TLS certificates are often relatively large, and the certificate		TLS certificates in EAP deployments can be relatively large, and the
	chains are often long. Unlike the use of TLS on the web, where		certificate chains can be long. Unlike the use of TLS on the web,
	typically only the TLS server is authenticated; EAP-TLS deployments		where typically only the TLS server is authenticated; EAP-TLS
	typically authenticates both the EAP peer and the EAP server. Also,		deployments typically authenticates both the EAP peer and the EAP
	from deployment experience, EAP peers typically have longer		server. Also, from deployment experience, EAP peers typically have
	certificate chains than servers. This is because EAP peers often		longer certificate chains than servers. This is because EAP peers
	follow organizational hierarchies and tend to have many intermediate		often follow organizational hierarchies and tend to have many
	certificates. Thus, EAP-TLS authentication usually involve		intermediate certificates. Thus, EAP-TLS authentication usually
	significantly more octets than when TLS is used as part of HTTPS.		involve significantly more octets than when TLS is used as part of
			HTTPS.
	Section 3.1 of [RFC3748] states that EAP implementations can assume a		Section 3.1 of [RFC3748] states that EAP implementations can assume a
	MTU of at least 1020 octets from lower layers. The EAP fragment size		MTU of at least 1020 octets from lower layers. The EAP fragment size
	in typical deployments is just 1020 - 1500 octets. Thus, EAP-TLS		in typical deployments is just 1020 - 1500 octets (since the maximum
	authentication needs to be fragmented into many smaller packets for		Ethernet frame size is ~ 1500 bytes). Thus, EAP-TLS authentication
	transportation over the lower layers. Such fragmentation can not		needs to be fragmented into many smaller packets for transportation
	only negatively affect the latency, but also results in other		over the lower layers. Such fragmentation can not only negatively
	challenges. For example, many EAP authenticator (access point)		affect the latency, but also results in other challenges. For
	implementations will drop an EAP session if it has not finished after		example, some EAP authenticator (access point) implementations will
	40 - 50 round-trips. This is a major problem and means that in many		drop an EAP session if it has not finished after 40 - 50 round-trips.
	situations, the EAP peer cannot perform network access authentication		This is a major problem and means that in many situations, the EAP
	even though both the sides have valid credentials for successful		peer cannot perform network access authentication even though both
	authentication and key derivation.		the sides have valid credentials for successful authentication and
			key derivation.
	Not all EAP deployments are constrained by the MTU of the lower		Not all EAP deployments are constrained by the MTU of the lower
	layer. For example, some implementations support EAP over Ethernet		layer. For example, some implementations support EAP over Ethernet
	"Jumbo" frames that can easily allow very large EAP packets. Larger		"Jumbo" frames that can easily allow very large EAP packets. Larger
	packets will naturally help lower the number of round trips required		packets will naturally help lower the number of round trips required
	for successful EAP-TLS authentication. However, deployment		for successful EAP-TLS authentication. However, deployment
	experience has shown that these jumbo frames are not always		experience has shown that these jumbo frames are not always
	implemented correctly. Additionally, EAP fragment size is also		implemented correctly. Additionally, EAP fragment size is also
	restricted by protocols such as RADIUS [RFC2865] which are		restricted by protocols such as RADIUS [RFC2865] which are
	responsible for transporting EAP messages between an authenticator		responsible for transporting EAP messages between an authenticator
	and an EAP server. RADIUS can generally transport only about 4000		and an EAP server. RADIUS can generally transport only about 4000
	octets of EAP in a single message.		octets of EAP in a single message (the maximum length of RADIUS
			packet is restricted to 4096 octets in [RFC2865]).
	This memo looks at related work and potential tools available for		This document looks at related work and potential tools available for
	overcoming the deployment challenges induced by large certificates		overcoming the deployment challenges induced by large certificates
	and long certificate chains. It then discusses the solutions		and long certificate chains. It then discusses the solutions
	available to overcome these challenges.		available to overcome these challenges.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	skipping to change at page 4, line 21 ¶		skipping to change at page 4, line 26 ¶
	TLS, the EAP peer implements the TLS client role.		TLS, the EAP peer implements the TLS client role.
	EAP server The entity that terminates the EAP authentication method		EAP server The entity that terminates the EAP authentication method
	with the peer. In the case where no backend authentication		with the peer. In the case where no backend authentication
	server is used, the EAP server is part of the authenticator.		server is used, the EAP server is part of the authenticator.
	In the case where the authenticator operates in pass-through		In the case where the authenticator operates in pass-through
	mode, the EAP server is located on the backend authentication		mode, the EAP server is located on the backend authentication
	server. In EAP-TLS, the EAP server implements the TLS server		server. In EAP-TLS, the EAP server implements the TLS server
	role.		role.
			The document additionally uses the terms trust anchor and
			certification path defined in [RFC5280].
	3. Experience with Deployments		3. Experience with Deployments
	As stated earlier, the EAP fragment size in typical deployments is		As stated earlier, the EAP fragment size in typical deployments is
	just 1020 - 1500 octets. Certificate sizes can however be large for		just 1020 - 1500 octets. Certificate sizes can however be large for
	a number of reasons:		a number of reasons:
	o Long Subject Alternative Name field.		o Long Subject Alternative Name field.
	o Long Public Key and Signature fields.		o Long Public Key and Signature fields.
	o Can contain multiple object identifiers (OID) that indicate the		o Can contain multiple object identifiers (OID) that indicate the
	permitted uses of the certificate as noted in Section 5.3 of		permitted uses of the certificate as noted in Section 5.3 of
	[RFC5216]. Most implementations verify the presence of these OIDs		[RFC5216]. Most implementations verify the presence of these OIDs
	for successful authentication.		for successful authentication.
	o Multiple user groups in the certificate.		o Multiple user groups in the certificate.
	A certificate chain (called a certification path in [RFC5280]) can		A certificate chain (called a certification path in [RFC5280]) can
	have 2 - 6 intermediate certificates between the end-entity		have 2 - 6 intermediate certificates between the end-entity
	certificate and the trust anchor [RFC5280].		certificate and the trust anchor.
	Most common access point implementations drop EAP sessions that do		Many access point implementations drop EAP sessions that do not
	not complete within 50 round-trips. This means that if the chain is		complete within 50 round-trips. This means that if the chain is
	larger than ~ 60 kB, EAP-TLS authentication cannot complete		larger than ~ 60 kB, EAP-TLS authentication cannot complete
	successfully in most deployments.		successfully in most deployments.
	4. Handling of Large Certificates and Long Certificate Chains		4. Handling of Large Certificates and Long Certificate Chains
	This section discusses some possible alternatives for overcoming the		This section discusses some possible alternatives for overcoming the
	challenge of large certificates and long certificate chains in EAP-		challenge of large certificates and long certificate chains in EAP-
	TLS authentication. In Section 4.1 we look at recommendations that		TLS authentication. In Section 4.1 we look at recommendations that
	require an update of the certificates or certificate chains that are		require an update of the certificates or certificate chains that are
	used for EAP-TLS authentication without requiring changes to the		used for EAP-TLS authentication without requiring changes to the
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 48 ¶
	intermediate certificates (such as postal addresses) do not		intermediate certificates (such as postal addresses) do not
	provide any additional value and they can be shortened (for		provide any additional value and they can be shortened (for
	example: only including the department name instead of the full		example: only including the department name instead of the full
	postal address).		postal address).
	4.2. Updating TLS and EAP-TLS Code		4.2. Updating TLS and EAP-TLS Code
	4.2.1. Pre-distributing and Omitting CA Certificates		4.2.1. Pre-distributing and Omitting CA Certificates
	The TLS Certificate message conveys the sending endpoint's		The TLS Certificate message conveys the sending endpoint's
	certificate chain. TLS allows endpoints to reduce the sizes of the		certificate chain. TLS allows endpoints to reduce the size of the
	Certificate messages by omitting certificates that the other endpoint		Certificate message by omitting certificates that the other endpoint
	is known to possess. When using TLS 1.3, all certificates that		is known to possess. When using TLS 1.3, all certificates that
	specify a trust anchor known by the other endpoint may be omitted		specify a trust anchor known by the other endpoint may be omitted
	(see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or earlier,		(see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or earlier,
	only the self-signed certificate that specifies the root certificate		only the self-signed certificate that specifies the root certificate
	authority may be omitted (see Section 7.4.2 of [RFC5246] Therefore,		authority may be omitted (see Section 7.4.2 of [RFC5246] Therefore,
	updating TLS implementations to version 1.3 can help to significantly		updating TLS implementations to version 1.3 can help to significantly
	reduce the number of messages exchanged for EAP-TLS authentication.		reduce the number of messages exchanged for EAP-TLS authentication.
	The omitted certificates need to be pre-distributed independently of		The omitted certificates need to be pre-distributed independently of
	TLS and the TLS implementation need to be configured to omit the pre-		TLS and the TLS implementations need to be configured to omit these
	distributed certificates.		pre-distributed certificates.
	4.2.2. Caching Certificates		4.2.2. URLs for Client Certificates
			[RFC6066] defines the "client_certificate_url" extension which allows
			TLS clients to send a sequence of Uniform Resource Locators (URLs)
			instead of the client certificate. URLs can refer to a single
			certificate or a certificate chain. Using this extension can curtail
			the amount of fragmentation in EAP deployments thereby allowing EAP
			sessions to successfully complete.
			4.2.3. Compact TLS 1.3
			[I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and
			reduces the message size of the protocol by removing obsolete
			material and using more efficient encoding. This naturally means
			that cTLS is not interoperable with previous versions of the TLS
			protocol. It also defines a compression profile with which either
			side can define dictionary of "known certificates". Thus, cTLS can
			provide another mechanism for EAP-TLS deployments to reduce the size
			of messages and avoid excessive fragmentation.
			4.2.4. Caching Certificates
	The TLS Cached Information Extension [RFC7924] specifies an extension		The TLS Cached Information Extension [RFC7924] specifies an extension
	where a server can exclude transmission of certificate information		where a server can exclude transmission of certificate information
	cached in an earlier TLS handshake. The client and the server would		cached in an earlier TLS handshake. The client and the server would
	first execute the full TLS handshake. The client would then cache		first execute the full TLS handshake. The client would then cache
	the certificate provided by the server. When the TLS client later		the certificate provided by the server. When the TLS client later
	connects to the same TLS server without using session resumption, it		connects to the same TLS server without using session resumption, it
	can attach the "cached_info" extension to the ClientHello message.		can attach the "cached_info" extension to the ClientHello message.
	This would allow the client to indicate that it has cached the		This would allow the client to indicate that it has cached the
	certificate. The client would also include a fingerprint of the		certificate. The client would also include a fingerprint of the
	skipping to change at page 7, line 35 ¶		skipping to change at page 8, line 15 ¶
	authenticators in a roaming network are more strict at dropping long		authenticators in a roaming network are more strict at dropping long
	EAP sessions, an EAP peer can use the Cached Information Extension to		EAP sessions, an EAP peer can use the Cached Information Extension to
	reduce the total number of messages.		reduce the total number of messages.
	However, if all authenticators drop the EAP session for a given EAP		However, if all authenticators drop the EAP session for a given EAP
	peer and EAP server combination, a successful full handshake is not		peer and EAP server combination, a successful full handshake is not
	possible. An option in such a scenario would be to cache validated		possible. An option in such a scenario would be to cache validated
	certificate chains even if the EAP-TLS exchange fails, but this is		certificate chains even if the EAP-TLS exchange fails, but this is
	currently not allowed according to [RFC7924].		currently not allowed according to [RFC7924].
	4.2.3. Compressing Certificates		4.2.5. Compressing Certificates
	The TLS working group is also working on an extension for TLS 1.3		The TLS working group is also working on an extension for TLS 1.3
	[I-D.ietf-tls-certificate-compression] that allows compression of		[I-D.ietf-tls-certificate-compression] that allows compression of
	certificates and certificate chains during full handshakes. The		certificates and certificate chains during full handshakes. The
	client can indicate support for compressed server certificates by		client can indicate support for compressed server certificates by
	including this extension in the ClientHello message. Similarly, the		including this extension in the ClientHello message. Similarly, the
	server can indicate support for compression of client certificates by		server can indicate support for compression of client certificates by
	including this extension in the CertificateRequest message. While		including this extension in the CertificateRequest message. While
	such an extension can alleviate the problem of excessive		such an extension can alleviate the problem of excessive
	fragmentation in EAP-TLS, it can only be used with TLS version 1.3		fragmentation in EAP-TLS, it can only be used with TLS version 1.3
	and higher. Deployments that rely on older versions of TLS cannot		and higher. Deployments that rely on older versions of TLS cannot
	benefit from this extension.		benefit from this extension.
	4.2.4. Suppressing Intermediate Certificates		4.2.6. Suppressing Intermediate Certificates
	For a client that has all intermediates, having the server send		For a client that has all intermediates, having the server send
	intermediates in the TLS handshake increases the size of the		intermediates in the TLS handshake increases the size of the
	handshake unnecessarily. The TLS working group is working on an		handshake unnecessarily. The TLS working group is working on an
	extension for TLS 1.3 [I-D.thomson-tls-sic] that allows a TLS client		extension for TLS 1.3 [I-D.thomson-tls-sic] that allows a TLS client
	that has access to the complete set of published intermediate		that has access to the complete set of published intermediate
	certificates to inform servers of this fact so that the server can		certificates to inform servers of this fact so that the server can
	avoid sending intermediates, reducing the size of the TLS handshake.		avoid sending intermediates, reducing the size of the TLS handshake.
	The mechanism is intended to be complementary with certificate		The mechanism is intended to be complementary with certificate
	compression.		compression.
	4.2.5. Using Fewer Intermediate Certificates		4.2.7. Using Fewer Intermediate Certificates
	The EAP peer certificate chain does not have to mirror the		The EAP peer certificate chain does not have to mirror the
	organizational hierarchy. For successful EAP-TLS authentication,		organizational hierarchy. For successful EAP-TLS authentication,
	certificate chains should not contain more than 2-4 intermediate		certificate chains should not contain more than 2-4 intermediate
	certificates.		certificates.
	Administrators responsible for deployments using TLS-based EAP		Administrators responsible for deployments using TLS-based EAP
	methods can examine the certificate chains and make rough		methods can examine the certificate chains and make rough
	calculations about the number of round trips required for successful		calculations about the number of round trips required for successful
	authentication. For example, dividing the total size of all the		authentication. For example, dividing the total size of all the
	skipping to change at page 9, line 9 ¶		skipping to change at page 9, line 33 ¶
	infrastructure is ossified for the time being.		infrastructure is ossified for the time being.
	Vendors making new authenticators should consider increasing the		Vendors making new authenticators should consider increasing the
	number of round-trips allowed to 100 before denying the EAP		number of round-trips allowed to 100 before denying the EAP
	authentication to complete. At the same time, administrators		authentication to complete. At the same time, administrators
	responsible for EAP deployments should ensure that this 100 roundtrip		responsible for EAP deployments should ensure that this 100 roundtrip
	limit is not exceeded in practice.		limit is not exceeded in practice.
	5. IANA Considerations		5. IANA Considerations
	This memo includes no request to IANA.		This document includes no request to IANA.
	6. Security Considerations		6. Security Considerations
	Updating implementations to TLS version 1.3 allows omitting all		Updating implementations to TLS version 1.3 allows omitting all
	certificates with a trust anchor known by the other endpoint. TLS		certificates with a trust anchor known by the other endpoint. TLS
	1.3 additionally provides improved security, privacy, and reduced		1.3 additionally provides improved security, privacy, and reduced
	latency for EAP-TLS [I-D.ietf-emu-eap-tls13].		latency for EAP-TLS [I-D.ietf-emu-eap-tls13].
	When compressing certificates, the underlying compression algorithm		When compressing certificates, the underlying compression algorithm
	MUST output the same data that was provided as input by. After		MUST output the same data that was provided as input by. After
	skipping to change at page 9, line 28 ¶		skipping to change at page 10, line 4 ¶
	When compressing certificates, the underlying compression algorithm		When compressing certificates, the underlying compression algorithm
	MUST output the same data that was provided as input by. After		MUST output the same data that was provided as input by. After
	decompression, the Certificate message MUST be processed as if it		decompression, the Certificate message MUST be processed as if it
	were encoded without being compressed. Additional security		were encoded without being compressed. Additional security
	considerations when compressing certificates are specified in		considerations when compressing certificates are specified in
	[I-D.ietf-tls-certificate-compression]		[I-D.ietf-tls-certificate-compression]
	As noted in [I-D.thomson-tls-sic], suppressing intermediate		As noted in [I-D.thomson-tls-sic], suppressing intermediate
	certificates creates an unencrypted signal that might be used to		certificates creates an unencrypted signal that might be used to
	identify which clients believe that they have all intermediates.		identify which clients believe that they have all intermediates.
	This might also allow more effective fingerprinting and tracking of		This might also allow more effective fingerprinting and tracking of
	clients.		clients.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-emu-eap-tls13]		[I-D.ietf-emu-eap-tls13]
	Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3",		Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3",
	draft-ietf-emu-eap-tls13-08 (work in progress), December		draft-ietf-emu-eap-tls13-09 (work in progress), March
	2019.		2020.
	[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,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, Ed., "Extensible Authentication Protocol		Levkowetz, Ed., "Extensible Authentication Protocol
	(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,		(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
	<https://www.rfc-editor.org/info/rfc3748>.		<https://www.rfc-editor.org/info/rfc3748>.
	skipping to change at page 10, line 43 ¶		skipping to change at page 11, line 16 ¶
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-tls-certificate-compression]		[I-D.ietf-tls-certificate-compression]
	Ghedini, A. and V. Vasiliev, "TLS Certificate		Ghedini, A. and V. Vasiliev, "TLS Certificate
	Compression", draft-ietf-tls-certificate-compression-10		Compression", draft-ietf-tls-certificate-compression-10
	(work in progress), January 2020.		(work in progress), January 2020.
			[I-D.ietf-tls-ctls]
			Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS
			1.3", draft-ietf-tls-ctls-00 (work in progress), April
			2020.
	[I-D.thomson-tls-sic]		[I-D.thomson-tls-sic]
	Thomson, M., "Suppressing Intermediate Certificates in		Thomson, M., "Suppressing Intermediate Certificates in
	TLS", draft-thomson-tls-sic-00 (work in progress), March		TLS", draft-thomson-tls-sic-00 (work in progress), March
	2019.		2019.
	[IEEE-802.1X]		[IEEE-802.1X]
	Institute of Electrical and Electronics Engineers, "IEEE		Institute of Electrical and Electronics Engineers, "IEEE
	Standard for Local and metropolitan area networks -- Port-		Standard for Local and metropolitan area networks -- Port-
	Based Network Access Control", IEEE Standard 802.1X-2010 ,		Based Network Access Control", IEEE Standard 802.1X-2010 ,
	February 2010.		February 2010.
	skipping to change at page 11, line 20 ¶		skipping to change at page 11, line 47 ¶
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<https://www.rfc-editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-		[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
	256/384 and AES Galois Counter Mode (GCM)", RFC 5289,		256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
	DOI 10.17487/RFC5289, August 2008,		DOI 10.17487/RFC5289, August 2008,
	<https://www.rfc-editor.org/info/rfc5289>.		<https://www.rfc-editor.org/info/rfc5289>.
			[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
			Extensions: Extension Definitions", RFC 6066,
			DOI 10.17487/RFC6066, January 2011,
			<https://www.rfc-editor.org/info/rfc6066>.
	[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic		[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
	Curve Cryptography Algorithms", RFC 6090,		Curve Cryptography Algorithms", RFC 6090,
	DOI 10.17487/RFC6090, February 2011,		DOI 10.17487/RFC6090, February 2011,
	<https://www.rfc-editor.org/info/rfc6090>.		<https://www.rfc-editor.org/info/rfc6090>.
	[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security		[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
	(TLS) Cached Information Extension", RFC 7924,		(TLS) Cached Information Extension", RFC 7924,
	DOI 10.17487/RFC7924, July 2016,		DOI 10.17487/RFC7924, July 2016,
	<https://www.rfc-editor.org/info/rfc7924>.		<https://www.rfc-editor.org/info/rfc7924>.
End of changes. 27 change blocks.
	54 lines changed or deleted		95 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/