draft-ietf-uta-rfc7525bis-02.txt		draft-ietf-uta-rfc7525bis-03.txt
	UTA Working Group Y. Sheffer		UTA Working Group Y. Sheffer
	Internet-Draft Intuit		Internet-Draft Intuit
	Obsoletes: 7525 (if approved) R. Holz		Obsoletes: 7525 (if approved) R. Holz
	Updates: 5288, 6066 (if approved) University of Twente		Updates: 5288, 6066 (if approved) University of Twente
	Intended status: Best Current Practice P. Saint-Andre		Intended status: Best Current Practice P. Saint-Andre
	Expires: 1 March 2022 Mozilla		Expires: 28 April 2022 Mozilla
	T. Fossati		T. Fossati
	arm		arm
	28 August 2021		25 October 2021
	Recommendations for Secure Use of Transport Layer Security (TLS) and		Recommendations for Secure Use of Transport Layer Security (TLS) and
	Datagram Transport Layer Security (DTLS)		Datagram Transport Layer Security (DTLS)
	draft-ietf-uta-rfc7525bis-02		draft-ietf-uta-rfc7525bis-03
	Abstract		Abstract
	Transport Layer Security (TLS) and Datagram Transport Layer Security		Transport Layer Security (TLS) and Datagram Transport Layer Security
	(DTLS) are widely used to protect data exchanged over application		(DTLS) are widely used to protect data exchanged over application
	protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the		protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the
	last few years, several serious attacks on TLS have emerged,		last few years, several serious attacks on TLS have emerged,
	including attacks on its most commonly used cipher suites and their		including attacks on its most commonly used cipher suites and their
	modes of operation. This document provides recommendations for		modes of operation. This document provides recommendations for
	improving the security of deployed services that use TLS and DTLS.		improving the security of deployed services that use TLS and DTLS.
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	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 1 March 2022.		This Internet-Draft will expire on 28 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. General Recommendations . . . . . . . . . . . . . . . . . . . 5		3. General Recommendations . . . . . . . . . . . . . . . . . . . 5
	3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 5		3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 5
	3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 5		3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 5
	3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 6		3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 6
	3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 7		3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 7
	3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8		3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8
	3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 8		3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 8
	3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9		3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9
	3.6. Post-Handshake Authentication . . . . . . . . . . . . . . 10		3.6. Post-Handshake Authentication . . . . . . . . . . . . . . 9
	3.7. Server Name Indication . . . . . . . . . . . . . . . . . 10		3.7. Server Name Indication . . . . . . . . . . . . . . . . . 10
	3.8. Application-Layer Protocol Negotiation . . . . . . . . . 10		3.8. Application-Layer Protocol Negotiation . . . . . . . . . 10
	3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 . . . . . . 11		3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 . . . . . . 11
	4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 11		4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 11
	4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 12		4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 11
	4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 13		4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 13
	4.2.1. Implementation Details . . . . . . . . . . . . . . . 14		4.2.1. Implementation Details . . . . . . . . . . . . . . . 13
	4.3. Cipher Suites for TLS 1.3 . . . . . . . . . . . . . . . . 14		4.3. Cipher Suites for TLS 1.3 . . . . . . . . . . . . . . . . 14
	4.4. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 15		4.4. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 14
	4.5. Public Key Length . . . . . . . . . . . . . . . . . . . . 15		4.5. Public Key Length . . . . . . . . . . . . . . . . . . . . 15
	4.6. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 16		4.6. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 16
	5. Applicability Statement . . . . . . . . . . . . . . . . . . . 16		5. Applicability Statement . . . . . . . . . . . . . . . . . . . 16
	5.1. Security Services . . . . . . . . . . . . . . . . . . . . 17		5.1. Security Services . . . . . . . . . . . . . . . . . . . . 17
	5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 18		5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 18
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 18		6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	6.1. Host Name Validation . . . . . . . . . . . . . . . . . . 18		6.1. Host Name Validation . . . . . . . . . . . . . . . . . . 18
	6.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 19		6.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6.2.1. Nonce Reuse in TLS 1.2 . . . . . . . . . . . . . . . 19		6.2.1. Nonce Reuse in TLS 1.2 . . . . . . . . . . . . . . . 19
	6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 20		6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 20
	6.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 21		6.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 21
	6.5. Certificate Revocation . . . . . . . . . . . . . . . . . 22		6.5. Certificate Revocation . . . . . . . . . . . . . . . . . 22
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	8.1. Normative References . . . . . . . . . . . . . . . . . . 23		8.1. Normative References . . . . . . . . . . . . . . . . . . 23
	8.2. Informative References . . . . . . . . . . . . . . . . . 26		8.2. Informative References . . . . . . . . . . . . . . . . . 26
	Appendix A. Differences from RFC 7525 . . . . . . . . . . . . . 32		Appendix A. Differences from RFC 7525 . . . . . . . . . . . . . 32
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 33		Appendix B. Document History . . . . . . . . . . . . . . . . . . 33
	B.1. draft-ietf-uta-rfc7525bis-02 . . . . . . . . . . . . . . 33		B.1. draft-ietf-uta-rfc7525bis-03 . . . . . . . . . . . . . . 33
	B.2. draft-ietf-uta-rfc7525bis-01 . . . . . . . . . . . . . . 33		B.2. draft-ietf-uta-rfc7525bis-02 . . . . . . . . . . . . . . 33
	B.3. draft-ietf-uta-rfc7525bis-00 . . . . . . . . . . . . . . 34		B.3. draft-ietf-uta-rfc7525bis-01 . . . . . . . . . . . . . . 33
	B.4. draft-sheffer-uta-rfc7525bis-00 . . . . . . . . . . . . . 34		B.4. draft-ietf-uta-rfc7525bis-00 . . . . . . . . . . . . . . 34
	B.5. draft-sheffer-uta-bcp195bis-00 . . . . . . . . . . . . . 34		B.5. draft-sheffer-uta-rfc7525bis-00 . . . . . . . . . . . . . 34
			B.6. draft-sheffer-uta-bcp195bis-00 . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	1. Introduction		1. Introduction
	Transport Layer Security (TLS) [RFC5246] and Datagram Transport		Transport Layer Security (TLS) [RFC5246] and Datagram Transport
	Security Layer (DTLS) [RFC6347] are widely used to protect data		Security Layer (DTLS) [RFC6347] are widely used to protect data
	exchanged over application protocols such as HTTP, SMTP, IMAP, POP,		exchanged over application protocols such as HTTP, SMTP, IMAP, POP,
	SIP, and XMPP. Over the years leading to 2015, several serious		SIP, and XMPP. Over the years leading to 2015, several serious
	attacks on TLS have emerged, including attacks on its most commonly		attacks on TLS have emerged, including attacks on its most commonly
	used cipher suites and their modes of operation. For instance, both		used cipher suites and their modes of operation. For instance, both
	skipping to change at page 9, line 39 ¶		skipping to change at page 9, line 39 ¶
	server is able to track the client, in some cases indefinitely. See		server is able to track the client, in some cases indefinitely. See
	[Sy2018] for more details.		[Sy2018] for more details.
	3.5. TLS Renegotiation		3.5. TLS Renegotiation
	Where handshake renegotiation is implemented, both clients and		Where handshake renegotiation is implemented, both clients and
	servers MUST implement the renegotiation_info extension, as defined		servers MUST implement the renegotiation_info extension, as defined
	in [RFC5746]. Note: this recommendation applies to TLS 1.2 only,		in [RFC5746]. Note: this recommendation applies to TLS 1.2 only,
	because renegotiation has been removed from TLS 1.3.		because renegotiation has been removed from TLS 1.3.
	The most secure option for countering the Triple Handshake attack is		A related attack resulting from TLS session parameters not properly
	to refuse any change of certificates during renegotiation. In		authenticated is Triple Handshake [triple-handshake]. To address
	addition, TLS clients SHOULD apply the same validation policy for all		this attack, TLS 1.2 implementations SHOULD support the
	certificates received over a connection. The [triple-handshake]		extended_master_secret extension defined in [RFC7627].
	document suggests several other possible countermeasures, such as
	binding the master secret to the full handshake (see [SESSION-HASH])
	and binding the abbreviated session resumption handshake to the
	original full handshake. Although the latter two techniques are
	still under development and thus do not qualify as current practices,
	those who implement and deploy TLS are advised to watch for further
	development of appropriate countermeasures.
	3.6. Post-Handshake Authentication		3.6. Post-Handshake Authentication
	Renegotiation in TLS 1.2 was replaced in TLS 1.3 by separate post-		Renegotiation in TLS 1.2 was replaced in TLS 1.3 by separate post-
	handshake authentication and key update mechanisms. In the context		handshake authentication and key update mechanisms. In the context
	of protocols that multiplex requests over a single connection (such		of protocols that multiplex requests over a single connection (such
	as HTTP/2), post-handshake authentication has the same problems as		as HTTP/2), post-handshake authentication has the same problems as
	TLS 1.2 renegotiation. Multiplexed protocols SHOULD follow the		TLS 1.2 renegotiation. Multiplexed protocols SHOULD follow the
	advice provided for HTTP/2 in [RFC8740].		advice provided for HTTP/2 in [RFC8740].
	skipping to change at page 10, line 33 ¶		skipping to change at page 10, line 24 ¶
	Rationale: SNI supports deployment of multiple TLS-protected virtual		Rationale: SNI supports deployment of multiple TLS-protected virtual
	servers on a single address, and therefore enables fine-grained		servers on a single address, and therefore enables fine-grained
	security for these virtual servers, by allowing each one to have its		security for these virtual servers, by allowing each one to have its
	own certificate. However, SNI also leaks the target domain for a		own certificate. However, SNI also leaks the target domain for a
	given connection; this information leak will be plugged by use of TLS		given connection; this information leak will be plugged by use of TLS
	Encrypted Client Hello.		Encrypted Client Hello.
	In order to prevent the attacks described in [ALPACA], a server that		In order to prevent the attacks described in [ALPACA], a server that
	does not recognize the presented server name SHOULD NOT continue the		does not recognize the presented server name SHOULD NOT continue the
	handshake and instead fail with a fatal-level		handshake and instead fail with a fatal-level unrecognized_name(112)
	"unrecognized_name(112)" alert. Note that this recommendation		alert. Note that this recommendation updates Section 3 of [RFC6066]:
	updates Section 3 of [RFC6066]: "If the server understood the		"If the server understood the ClientHello extension but does not
	ClientHello extension but does not recognize the server name, the		recognize the server name, the server SHOULD take one of two actions:
	server SHOULD take one of two actions: either abort the handshake by		either abort the handshake by sending a fatal-level
	sending a fatal-level "unrecognized_name(112)" alert or continue the		unrecognized_name(112) alert or continue the handshake." It is also
	handshake." It is also RECOMMENDED that clients abort the handshake		RECOMMENDED that clients abort the handshake if the server
	if the server acknowledges the SNI hostname with a different hostname		acknowledges the SNI hostname with a different hostname than the one
	than the one sent by the client.		sent by the client.
	3.8. Application-Layer Protocol Negotiation		3.8. Application-Layer Protocol Negotiation
	TLS implementations (both client- and server-side) MUST support the		TLS implementations (both client- and server-side) MUST support the
	Application-Layer Protocol Negotiation (ALPN) extension [RFC7301].		Application-Layer Protocol Negotiation (ALPN) extension [RFC7301].
	In order to prevent "cross-protocol" attacks resulting from failure		In order to prevent "cross-protocol" attacks resulting from failure
	to ensure that a message intended for use in one protocol cannot be		to ensure that a message intended for use in one protocol cannot be
	mistaken for a message for use in another protocol, servers should		mistaken for a message for use in another protocol, servers should
	strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]:		strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]:
	"In the event that the server supports no protocols that the client		"In the event that the server supports no protocols that the client
	advertises, then the server SHALL respond with a fatal		advertises, then the server SHALL respond with a fatal
	"no_application_protocol" alert." It is also RECOMMENDED that		no_application_protocol alert." It is also RECOMMENDED that clients
	clients abort the handshake if the server acknowledges the ALPN		abort the handshake if the server acknowledges the ALPN extension,
	extension, but does not select a protocol from the client list.		but does not select a protocol from the client list. Failure to do
	Failure to do so can result in attacks such those described in		so can result in attacks such those described in [ALPACA].
	[ALPACA].
	Protocol developers are strongly encouraged to register an ALPN		Protocol developers are strongly encouraged to register an ALPN
	identifier for their protocols. This applies to new protocols, as		identifier for their protocols. This applies to new protocols, as
	well as well-established protocols such as SMTP.		well as well-established protocols such as SMTP.
	3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3		3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3
	The 0-RTT early data feature is new in TLS 1.3. It provides improved		The 0-RTT early data feature is new in TLS 1.3. It provides improved
	latency when TLS connections are resumed, at the potential cost of		latency when TLS connections are resumed, at the potential cost of
	security. As a result, it requires special attention from		security. As a result, it requires special attention from
	skipping to change at page 15, line 8 ¶		skipping to change at page 14, line 43 ¶
	4.3. Cipher Suites for TLS 1.3		4.3. Cipher Suites for TLS 1.3
	This document does not specify any cipher suites for TLS 1.3.		This document does not specify any cipher suites for TLS 1.3.
	Readers are referred to Sec. 9.1 of [RFC8446] for cipher suite		Readers are referred to Sec. 9.1 of [RFC8446] for cipher suite
	recommendations.		recommendations.
	4.4. Limits on Key Usage		4.4. Limits on Key Usage
	All ciphers have an upper limit on the amount of traffic that can be		All ciphers have an upper limit on the amount of traffic that can be
	securely encrypted with any given key. In the case of AEAD cipher		securely protected with any given key. In the case of AEAD cipher
	suites, the limit is typically determined by the cipher's integrity		suites, two separate limits are maintained for each key:
	guarantees. When the amount of traffic for a particular connection
	has reached the limit, an implementation SHOULD perform a new
	handshake (or in TLS 1.3, a Key Update) to rotate the session key.
	For all AES-GCM cipher suites recommended for TLS 1.2 in this		1. Confidentiality limit (CL), i.e., the number of records that can
	document, the limit for one connection is 2^24.5 full-size records		be encrypted.
	(about 24 million). This is the same number as for TLS 1.3 with the
	equivalent cipher suites.
	// TODO: refer to {{I-D.irtf-cfrg-aead-limits}} once it has added the		2. Integrity limit (IL), i.e., the number of records that are
	// derivation for TLS 1.2, which is different from TLS 1.3.		allowed to fail authentication.
	// Different derivation, same numbers.
			The latter only applies to DTLS since TLS connections are torn down
			on the first decryption failure.
			When a sender is approaching CL, the implementation SHOULD initiate a
			new handshake (or in TLS 1.3, a Key Update) to rotate the session
			key.
			When a receiver has reached IL, the implementation SHOULD close the
			connection.
	For all TLS 1.3 cipher suites, readers are referred to Section 5.5 of		For all TLS 1.3 cipher suites, readers are referred to Section 5.5 of
	[RFC8446].		[RFC8446] for the values of CL and IL. For all DTLS 1.3 cipher
			suites, readers are referred to Section 4.5.3 of
			[I-D.ietf-tls-dtls13].
			For all AES-GCM cipher suites recommended for TLS 1.2 and DTLS 1.2 in
			this document, CL can be derived by plugging the corresponding
			parameters into the inequalities in Section 6.1 of
			[I-D.irtf-cfrg-aead-limits] that apply to random, partially implicit
			nonces, i.e., the nonce construction used in TLS 1.2. Although the
			obtained figures are slightly higher than those for TLS 1.3, it is
			RECOMMENDED that the same limit of 2^24.5 records is used for both
			versions.
			For all AES-GCM cipher suites recommended for DTLS 1.2, IL (obtained
			from the same inequalities referenced above) is 2^28.
	4.5. Public Key Length		4.5. Public Key Length
	When using the cipher suites recommended in this document, two public		When using the cipher suites recommended in this document, two public
	keys are normally used in the TLS handshake: one for the Diffie-		keys are normally used in the TLS handshake: one for the Diffie-
	Hellman key agreement and one for server authentication. Where a		Hellman key agreement and one for server authentication. Where a
	client certificate is used, a third public key is added.		client certificate is used, a third public key is added.
	With a key exchange based on modular exponential (MODP) Diffie-		With a key exchange based on modular exponential (MODP) Diffie-
	Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048		Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048
	skipping to change at page 20, line 6 ¶		skipping to change at page 20, line 6 ¶
	attacks such as [Joux2006]. (See [CVE] records: CVE-2016-0270, CVE-		attacks such as [Joux2006]. (See [CVE] records: CVE-2016-0270, CVE-
	2016-10213, CVE-2016-10212, CVE-2017-5933.)		2016-10213, CVE-2016-10212, CVE-2017-5933.)
	While this problem has been fixed in TLS 1.3, which enforces a		While this problem has been fixed in TLS 1.3, which enforces a
	deterministic method to generate nonces from record sequence numbers		deterministic method to generate nonces from record sequence numbers
	and shared secrets for all of its AEAD cipher suites (including AES-		and shared secrets for all of its AEAD cipher suites (including AES-
	GCM), TLS 1.2 implementations could still choose their own		GCM), TLS 1.2 implementations could still choose their own
	(potentially insecure) nonce generation methods.		(potentially insecure) nonce generation methods.
	It is therefore RECOMMENDED that TLS 1.2 implementations use the		It is therefore RECOMMENDED that TLS 1.2 implementations use the
	64-bit sequence number to populate the "nonce_explicit" part of the		64-bit sequence number to populate the nonce_explicit part of the GCM
	GCM nonce, as described in the first two paragraphs of Section 5.3 of		nonce, as described in the first two paragraphs of Section 5.3 of
	[RFC8446]. Note that this recommendation updates Section 3 of		[RFC8446]. Note that this recommendation updates Section 3 of
	[RFC5288]: "The nonce_explicit MAY be the 64-bit sequence number."		[RFC5288]: "The nonce_explicit MAY be the 64-bit sequence number."
	We note that at the time of writing there are no cipher suites		We note that at the time of writing there are no cipher suites
	defined for nonce reuse resistant algorithms such as AES-GCM-SIV		defined for nonce reuse resistant algorithms such as AES-GCM-SIV
	[RFC8452].		[RFC8452].
	6.3. Forward Secrecy		6.3. Forward Secrecy
	Forward secrecy (also called "perfect forward secrecy" or "PFS" and		Forward secrecy (also called "perfect forward secrecy" or "PFS" and
	skipping to change at page 24, line 8 ¶		skipping to change at page 24, line 8 ¶
	and Orit Levin as the working group chairs and Pete Resnick as the		and Orit Levin as the working group chairs and Pete Resnick as the
	sponsoring Area Director.		sponsoring Area Director.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-httpbis-semantics]		[I-D.ietf-httpbis-semantics]
	Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Semantics", Work in Progress, Internet-Draft, draft-ietf-		Semantics", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-semantics-18, 18 August 2021,		httpbis-semantics-19, 12 September 2021,
	<https://www.ietf.org/archive/id/draft-ietf-httpbis-		<https://www.ietf.org/archive/id/draft-ietf-httpbis-
	semantics-18.txt>.		semantics-19.txt>.
	[I-D.ietf-tls-dtls13]		[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", Work in Progress, Internet-Draft, draft-ietf-tls-		1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
	dtls13-43, 30 April 2021,		dtls13-43, 30 April 2021,
	<https://www.ietf.org/archive/id/draft-ietf-tls-		<https://www.ietf.org/archive/id/draft-ietf-tls-
	dtls13-43.txt>.		dtls13-43.txt>.
	[I-D.ietf-tls-oldversions-deprecate]		[I-D.ietf-tls-oldversions-deprecate]
	skipping to change at page 25, line 49 ¶		skipping to change at page 26, line 5 ¶
	[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,		[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
	DOI 10.17487/RFC7465, February 2015,		DOI 10.17487/RFC7465, February 2015,
	<https://www.rfc-editor.org/info/rfc7465>.		<https://www.rfc-editor.org/info/rfc7465>.
	[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher		[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
	Suite Value (SCSV) for Preventing Protocol Downgrade		Suite Value (SCSV) for Preventing Protocol Downgrade
	Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,		Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
	<https://www.rfc-editor.org/info/rfc7507>.		<https://www.rfc-editor.org/info/rfc7507>.
			[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
			Langley, A., and M. Ray, "Transport Layer Security (TLS)
			Session Hash and Extended Master Secret Extension",
			RFC 7627, DOI 10.17487/RFC7627, September 2015,
			<https://www.rfc-editor.org/info/rfc7627>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	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>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,		[RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,
	DOI 10.17487/RFC8740, February 2020,		DOI 10.17487/RFC8740, February 2020,
	skipping to change at page 31, line 18 ¶		skipping to change at page 31, line 29 ¶
	<https://www.rfc-editor.org/info/rfc8452>.		<https://www.rfc-editor.org/info/rfc8452>.
	[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early		[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
	Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September		Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
	2018, <https://www.rfc-editor.org/info/rfc8470>.		2018, <https://www.rfc-editor.org/info/rfc8470>.
	[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure		[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
	QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,		QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
	<https://www.rfc-editor.org/info/rfc9001>.		<https://www.rfc-editor.org/info/rfc9001>.
	[SESSION-HASH]
	Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
	Langley, A., and M. Ray, "Transport Layer Security (TLS)
	Session Hash and Extended Master Secret Extension",
	RFC 7627, DOI 10.17487/RFC7627, September 2015,
	<https://www.rfc-editor.org/info/rfc7627>.
	[Smith2013]		[Smith2013]
	Smith, B., "Proposal to Change the Default TLS		Smith, B., "Proposal to Change the Default TLS
	Ciphersuites Offered by Browsers.", 2013,		Ciphersuites Offered by Browsers.", 2013,
	<https://briansmith.org/browser-ciphersuites-01.html>.		<https://briansmith.org/browser-ciphersuites-01.html>.
	[Soghoian2011]		[Soghoian2011]
	Soghoian, C. and S. Stamm, "Certified Lies: Detecting and		Soghoian, C. and S. Stamm, "Certified Lies: Detecting and
	Defeating Government Interception Attacks Against SSL",		Defeating Government Interception Attacks Against SSL",
	SSRN Electronic Journal, DOI 10.2139/ssrn.1591033, 2010,		SSRN Electronic Journal, DOI 10.2139/ssrn.1591033, 2010,
	<https://doi.org/10.2139/ssrn.1591033>.		<https://doi.org/10.2139/ssrn.1591033>.
	skipping to change at page 32, line 33 ¶		skipping to change at page 32, line 33 ¶
	- Added TLS 1.3 at a SHOULD level.		- Added TLS 1.3 at a SHOULD level.
	- Similar changes to DTLS, pending publication of DTLS 1.3.		- Similar changes to DTLS, pending publication of DTLS 1.3.
	- Specific guidance for multiplexed protocols.		- Specific guidance for multiplexed protocols.
	- MUST-level implementation requirement for ALPN, and more		- MUST-level implementation requirement for ALPN, and more
	specific SHOULD-level guidance for ALPN and SNI.		specific SHOULD-level guidance for ALPN and SNI.
			- Limits on key usage.
	- New attacks since [RFC7457]: ALPACA, Raccoon, Logjam, "Nonce-		- New attacks since [RFC7457]: ALPACA, Raccoon, Logjam, "Nonce-
	Disrespecting Adversaries"		Disrespecting Adversaries".
	* Differences specific to TLS 1.2:		* Differences specific to TLS 1.2:
	- Fallback SCSV as a MUST for TLS 1.2.		- Fallback SCSV as a MUST for TLS 1.2.
	- SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2.		- SHOULD-level guidance on AES-GCM nonce generation.
	- SHOULD NOT use static DH keys or reuse ephemeral DH keys across		- SHOULD NOT use static DH keys or reuse ephemeral DH keys across
	multiple connections.		multiple connections.
	- 2048-bit DH now a MUST, ECDH minimal curve size is 224, vs. 192		- 2048-bit DH now a MUST, ECDH minimal curve size is 224, vs. 192
	previously.		previously.
			- Support for extended_master_secret is a SHOULD. Also removed
			other, more complicated, related mitigations.
	* Differences specific to TLS 1.3:		* Differences specific to TLS 1.3:
	- New TLS 1.3 capabilities: 0-RTT.		- New TLS 1.3 capabilities: 0-RTT.
	- Removed capabilities: renegotiation, compression.		- Removed capabilities: renegotiation, compression.
	- Added mention of TLS Encrypted Client Hello, but no		- Added mention of TLS Encrypted Client Hello, but no
	recommendation to use until it is finalized.		recommendation to use until it is finalized.
	- SHOULD-level requirement for forward secrecy in TLS 1.3 session		- SHOULD-level requirement for forward secrecy in TLS 1.3 session
	resumption.		resumption.
	- Generic SHOULD-level guidance to avoid 0-RTT unless it is		- Generic SHOULD-level guidance to avoid 0-RTT unless it is
	documented for the particular protocol.		documented for the particular protocol.
	Appendix B. Document History		Appendix B. Document History
	// Note to RFC Editor: please remove before publication.		// Note to RFC Editor: please remove before publication.
	B.1. draft-ietf-uta-rfc7525bis-02		B.1. draft-ietf-uta-rfc7525bis-03
			* Cipher integrity and confidentiality limits.
			* Require extended_master_secret.
			B.2. draft-ietf-uta-rfc7525bis-02
	* Adjusted text about ALPN support in application protocols		* Adjusted text about ALPN support in application protocols
	* Incorporated text from draft-ietf-tls-md5-sha1-deprecate		* Incorporated text from draft-ietf-tls-md5-sha1-deprecate
	B.2. draft-ietf-uta-rfc7525bis-01		B.3. draft-ietf-uta-rfc7525bis-01
	* Many more changes, including:		* Many more changes, including:
	- SHOULD-level requirement for forward secrecy in TLS 1.3 session		- SHOULD-level requirement for forward secrecy in TLS 1.3 session
	resumption.		resumption.
	- Removed TLS 1.2 capabilities: renegotiation, compression.		- Removed TLS 1.2 capabilities: renegotiation, compression.
	- Specific guidance for multiplexed protocols.		- Specific guidance for multiplexed protocols.
	skipping to change at page 34, line 5 ¶		skipping to change at page 34, line 13 ¶
	documented for the particular protocol.		documented for the particular protocol.
	- SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2.		- SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2.
	- SHOULD NOT use static DH keys or reuse ephemeral DH keys across		- SHOULD NOT use static DH keys or reuse ephemeral DH keys across
	multiple connections.		multiple connections.
	- 2048-bit DH now a MUST, ECDH minimal curve size is 224, up from		- 2048-bit DH now a MUST, ECDH minimal curve size is 224, up from
	192.		192.
	B.3. draft-ietf-uta-rfc7525bis-00		B.4. draft-ietf-uta-rfc7525bis-00
	* Renamed: WG document.		* Renamed: WG document.
	* Started populating list of changes from RFC 7525.		* Started populating list of changes from RFC 7525.
	* General rewording of abstract and intro for revised version.		* General rewording of abstract and intro for revised version.
	* Protocol versions, fallback.		* Protocol versions, fallback.
	* Reference to ECHO.		* Reference to ECHO.
	B.4. draft-sheffer-uta-rfc7525bis-00		B.5. draft-sheffer-uta-rfc7525bis-00
	* Renamed, since the BCP number does not change.		* Renamed, since the BCP number does not change.
	* Added an empty "Differences from RFC 7525" section.		* Added an empty "Differences from RFC 7525" section.
	B.5. draft-sheffer-uta-bcp195bis-00		B.6. draft-sheffer-uta-bcp195bis-00
	* Initial release, the RFC 7525 text as-is, with some minor		* Initial release, the RFC 7525 text as-is, with some minor
	editorial changes to the references.		editorial changes to the references.
	Authors' Addresses		Authors' Addresses
	Yaron Sheffer		Yaron Sheffer
	Intuit		Intuit
	Email: yaronf.ietf@gmail.com		Email: yaronf.ietf@gmail.com
End of changes. 30 change blocks.
	69 lines changed or deleted		90 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/