< draft-ietf-uta-tls13-iot-profile-01.txt		draft-ietf-uta-tls13-iot-profile-02.txt >
	UTA H. Tschofenig		UTA H. Tschofenig
	Internet-Draft T. Fossati		Internet-Draft T. Fossati
	Updates: 7925 (if approved) Arm Limited		Updates: 7925 (if approved) Arm Limited
	Intended status: Standards Track 22 February 2021		Intended status: Standards Track 12 July 2021
	Expires: 26 August 2021		Expires: 13 January 2022
	TLS/DTLS 1.3 Profiles for the Internet of Things		TLS/DTLS 1.3 Profiles for the Internet of Things
	draft-ietf-uta-tls13-iot-profile-01		draft-ietf-uta-tls13-iot-profile-02
	Abstract		Abstract
	This document is a companion to RFC 7925 and defines TLS/DTLS 1.3		This document is a companion to RFC 7925 and defines TLS/DTLS 1.3
	profiles for Internet of Things devices. It also updates RFC 7925		profiles for Internet of Things devices. It also updates RFC 7925
	with regards to the X.509 certificate profile.		with regards to the X.509 certificate profile.
	Discussion Venues		Discussion Venues
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Source for this draft and an issue tracker can be found at		Source for this draft and an issue tracker can be found at
	https://github.com/thomas-fossati/draft-tls13-iot		https://github.com/thomas-fossati/draft-tls13-iot.
	(https://github.com/thomas-fossati/draft-tls13-iot).
	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 26 August 2021.		This Internet-Draft will expire on 13 January 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3		1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
	2. Credential Types . . . . . . . . . . . . . . . . . . . . . . 3		2. Credential Types . . . . . . . . . . . . . . . . . . . . . . 3
	3. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4		3. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Session Resumption . . . . . . . . . . . . . . . . . . . . . 4		4. Session Resumption . . . . . . . . . . . . . . . . . . . . . 4
	5. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 4		5. Compression . . . . . . . . . . . . . . . . . . . . . . . . 4
	6. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 4		6. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 5
	7. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 4		7. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 5
	8. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 4		8. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	9. Random Number Generation . . . . . . . . . . . . . . . . . . 5		9. Random Number Generation . . . . . . . . . . . . . . . . . . 5
	10. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 5		10. Server Name Indication . . . . . . . . . . . . . . . . . . . 5
	11. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 5		11. Maximum Fragment Length Negotiation . . . . . . . . . . . . 5
	12. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 5		12. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 6
	13. Key Length Recommendations . . . . . . . . . . . . . . . . . 5		13. Key Length Recommendations . . . . . . . . . . . . . . . . . 6
	14. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . . . 5		14. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . . . 6
	15. Certificate Profile . . . . . . . . . . . . . . . . . . . . . 6		15. Certificate Profile . . . . . . . . . . . . . . . . . . . . . 7
	15.1. All Certificates . . . . . . . . . . . . . . . . . . . . 6		15.1. All Certificates . . . . . . . . . . . . . . . . . . . . 7
	15.1.1. Version . . . . . . . . . . . . . . . . . . . . . . 6		15.1.1. Version . . . . . . . . . . . . . . . . . . . . . . 7
	15.1.2. Serial Number . . . . . . . . . . . . . . . . . . . 6		15.1.2. Serial Number . . . . . . . . . . . . . . . . . . . 7
	15.1.3. Signature . . . . . . . . . . . . . . . . . . . . . 6		15.1.3. Signature . . . . . . . . . . . . . . . . . . . . . 7
	15.1.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . 6		15.1.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . 7
	15.1.5. Validity . . . . . . . . . . . . . . . . . . . . . . 7		15.1.5. Validity . . . . . . . . . . . . . . . . . . . . . 7
	15.1.6. subjectPublicKeyInfo . . . . . . . . . . . . . . . . 7		15.1.6. subjectPublicKeyInfo . . . . . . . . . . . . . . . 8
	15.2. Root CA Certificate . . . . . . . . . . . . . . . . . . 7		15.2. Root CA Certificate . . . . . . . . . . . . . . . . . . 8
	15.3. Intermediate CA Certificate . . . . . . . . . . . . . . 7		15.3. Intermediate CA Certificate . . . . . . . . . . . . . . 8
	15.4. End Entity Certificate . . . . . . . . . . . . . . . . . 7		15.4. End Entity Certificate . . . . . . . . . . . . . . . . . 8
	15.4.1. Client Certificate Subject . . . . . . . . . . . . . 8		15.4.1. Client Certificate Subject . . . . . . . . . . . . . 9
	16. Certificate Revocation Checks . . . . . . . . . . . . . . . . 8		16. Certificate Revocation Checks . . . . . . . . . . . . . . . . 9
	16.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . 8		17. Certificate Overhead . . . . . . . . . . . . . . . . . . . . 9
	17. Security Considerations . . . . . . . . . . . . . . . . . . . 9		17.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . 10
	18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		18. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	20. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	20.1. Normative References . . . . . . . . . . . . . . . . . . 9		21. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	20.2. Informative References . . . . . . . . . . . . . . . . . 10		21.1. Normative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		21.2. Informative References . . . . . . . . . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	This document defines a profile of DTLS 1.3 [I-D.ietf-tls-dtls13] and		This document defines a profile of DTLS 1.3 [I-D.ietf-tls-dtls13] and
	TLS 1.3 [RFC8446] that offers communication security services for IoT		TLS 1.3 [RFC8446] that offers communication security services for IoT
	applications and is reasonably implementable on many constrained		applications and is reasonably implementable on many constrained
	devices. Profile thereby means that available configuration options		devices. Profile thereby means that available configuration options
	and protocol extensions are utilized to best support the IoT		and protocol extensions are utilized to best support the IoT
	environment.		environment.
	skipping to change at page 3, line 52 ¶		skipping to change at page 3, line 52 ¶
	A compliant implementation supporting authentication based on		A compliant implementation supporting authentication based on
	certificates and raw public keys MUST support digital signatures with		certificates and raw public keys MUST support digital signatures with
	ecdsa_secp256r1_sha256. A compliant implementation MUST support the		ecdsa_secp256r1_sha256. A compliant implementation MUST support the
	key exchange with secp256r1 (NIST P-256) and SHOULD support key		key exchange with secp256r1 (NIST P-256) and SHOULD support key
	exchange with X25519.		exchange with X25519.
	A plain PSK-based TLS/DTLS client or server MUST implement the		A plain PSK-based TLS/DTLS client or server MUST implement the
	following extensions:		following extensions:
	* supported_versions		* Supported Versions,
	* cookie		* Cookie,
	* server_name		* Server Name Indication (SNI),
	* pre_shared_key		* Pre-Shared Key,
	* psk_key_exchange_modes		* PSK Key Exchange Modes, and
			* Application-Layer Protocol Negotiation (ALPN).
			The SNI extension is discussed in this document and the justification
			for implementing and using the ALPN extension can be found in
			[I-D.ietf-uta-rfc7525bis].
	For TLS/DTLS clients and servers implementing raw public keys and/or		For TLS/DTLS clients and servers implementing raw public keys and/or
	certificates the guidance for mandatory-to-implement extensions		certificates the guidance for mandatory-to-implement extensions
	described in Section 9.2 of [RFC8446] MUST be followed.		described in Section 9.2 of [RFC8446] MUST be followed.
	3. Error Handling		3. Error Handling
	TLS 1.3 simplified the Alert protocol but the underlying challenge in		TLS 1.3 simplified the Alert protocol but the underlying challenge in
	an embedded context remains unchanged, namely what should an IoT		an embedded context remains unchanged, namely what should an IoT
	device do when it encounters an error situation. The classical		device do when it encounters an error situation. The classical
	approach used in a desktop environment where the user is prompted is		approach used in a desktop environment where the user is prompted is
	often not applicable with unattended devices. Hence, it is more		often not applicable with unattended devices. Hence, it is more
	important for a developer to find out from which error cases a device		important for a developer to find out from which error cases a device
	can recover from.		can recover from.
	4. Session Resumption		4. Session Resumption
	TLS 1.3 has built-in support for session resumption by utilizing PSK-		TLS 1.3 has built-in support for session resumption by utilizing PSK-
	based credentials established in an earlier exchange.		based credentials established in an earlier exchange.
	5. Compression		5. Compression
	TLS 1.3 does not have support for compression.		TLS 1.3 does not have support for compression of application data
			traffic, as offered by previous versions of TLS. Applications are
			therefore responsible for transmitting payloads that are either
			compressed or use a more efficient encoding otherwise.
	6. Perfect Forward Secrecy		With regards to the handshake itself, various strategies have been
			applied to reduce the size of the exchanged payloads. TLS and DTLS
			1.3 use less overhead, depending on the type of key confirmations,
			when compared to previous versions of the protocol. Additionally,
			the work on Compact TLS (cTLS) [I-D.ietf-tls-ctls] has taken
			compression of the handshake a step further by utilizing out-of-band
			knowledge between the communication parties to reduce the amount of
			data to be transmitted at each individual handshake, among applying
			other techniques.
			6. Perfect Forward Secrecy
	TLS 1.3 allows the use of PFS with all ciphersuites since the support		TLS 1.3 allows the use of PFS with all ciphersuites since the support
	for it is negotiated independently.		for it is negotiated independently.
	7. Keep-Alive		7. Keep-Alive
	The discussion in Section 10 of [RFC7925] is applicable.		The discussion in Section 10 of [RFC7925] is applicable.
	8. Timeouts		8. Timeouts
	The recommendation in Section 11 of [RFC7925] is applicable. In		The recommendation in Section 11 of [RFC7925] is applicable. In
	particular this document RECOMMENDED to use an initial timer value of		particular this document RECOMMENDED to use an initial timer value of
	9 seconds with exponential back off up to no less then 60 seconds.		9 seconds with exponential back off up to no less then 60 seconds.
	Question: DTLS 1.3 now offers per-record retransmission and therefore		9. Random Number Generation
	introduces much less congestion risk associated with spurious
	retransmissions. Hence, should we relax the 9s initial timeout?
	9. Random Number Generation
	The discussion in Section 12 of [RFC7925] is applicable with one		The discussion in Section 12 of [RFC7925] is applicable with one
	exception: the ClientHello and the ServerHello messages in TLS 1.3 do		exception: the ClientHello and the ServerHello messages in TLS 1.3 do
	not contain gmt_unix_time component anymore.		not contain gmt_unix_time component anymore.
	10. Server Name Indication (SNI)		10. Server Name Indication
	This specification mandates the implementation of the SNI extension.		This specification mandates the implementation of the Server Name
	Where privacy requirements require it, the encrypted SNI extension		Indication (SNI) extension. Where privacy requirements require it,
	[I-D.ietf-tls-esni] prevents an on-path attacker to determine the		the Encrypted Client Hello extension [I-D.ietf-tls-esni] prevents an
	domain name the client is trying to connect to. Note, however, that		on-path attacker to determine the domain name the client is trying to
	the extension is still at an experimental state.		connect to.
	11. Maximum Fragment Length Negotiation		Note: To avoid leaking DNS lookups from network inspection altogether
			further protocols are needed, including DoH [RFC8484] and DPRIVE
			[RFC7858] [RFC8094]. Since the Encrypted Client Hello extension
			requires use of Hybrid Public Key Encryption (HPKE)
			[I-D.irtf-cfrg-hpke] and additional protocols require further
			protocol exchanges and cryptographic operations, there is a certain
			amount of overhead associated with this privacy property.
			11. Maximum Fragment Length Negotiation
	The Maximum Fragment Length Negotiation (MFL) extension has been		The Maximum Fragment Length Negotiation (MFL) extension has been
	superseded by the Record Size Limit (RSL) extension [RFC8449].		superseded by the Record Size Limit (RSL) extension [RFC8449].
	Implementations in compliance with this specification MUST implement		Implementations in compliance with this specification MUST implement
	the RSL extension and SHOULD use it to indicate their RAM		the RSL extension and SHOULD use it to indicate their RAM
	limitations.		limitations.
	12. Crypto Agility		12. Crypto Agility
	The recommendations in Section 19 of [RFC7925] are applicable.		The recommendations in Section 19 of [RFC7925] are applicable.
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 33 ¶
	(cryptographically secure pseudo-random number generator).		(cryptographically secure pseudo-random number generator).
	15.1.3. Signature		15.1.3. Signature
	The signature MUST be ecdsa-with-SHA256 or stronger [RFC5758].		The signature MUST be ecdsa-with-SHA256 or stronger [RFC5758].
	15.1.4. Issuer		15.1.4. Issuer
	Contains the DN of the issuing CA.		Contains the DN of the issuing CA.
	15.1.5. Validity		15.1.5. Validity
	No maximum validity period is mandated. Validity values are		No maximum validity period is mandated. Validity values are
	expressed as UTCTime in notBefore and notAfter fields, as mandated in		expressed in notBefore and notAfter fields, as described in
	[RFC5280].		Section 4.1.2.5 of [RFC5280]. In particular, values MUST be
			expressed in Greenwich Mean Time (Zulu) and MUST include seconds even
			where the number of seconds is zero.
			Note that the validity period is defined as the period of time from
			notBefore through notAfter, inclusive. This means that a
			hypothetical certificate with a notBefore date of 9 June 2021 at
			03:42:01 and a notAfter date of 7 September 2021 at 03:42:01 becomes
			valid at the beginning of the :01 second, and only becomes invalid at
			the :02 second, a period that is 90 days plus 1 second. So for a
			90-day, notAfter must actually be 03:42:00.
	In many cases it is necessary to indicate that a certificate does not		In many cases it is necessary to indicate that a certificate does not
	expire. This is likely to be the case for manufacturer-provisioned		expire. This is likely to be the case for manufacturer-provisioned
	certificates. RFC 5280 provides a simple solution to convey the fact		certificates. RFC 5280 provides a simple solution to convey the fact
	that a certificate has no well-defined expiration date by setting the		that a certificate has no well-defined expiration date by setting the
	notAfter to the GeneralizedTime value of 99991231235959Z.		notAfter to the GeneralizedTime value of 99991231235959Z.
	Some devices might not have a reliable source of time and for those		Some devices might not have a reliable source of time and for those
	devices it is also advisable to use certificates with no expiration		devices it is also advisable to use certificates with no expiration
	date and to let a device management solution manage the lifetime of		date and to let a device management solution manage the lifetime of
	all the certificates used by the device. While this approach does		all the certificates used by the device. While this approach does
	not utilize certificates to its widest extent, it is a solution that		not utilize certificates to its widest extent, it is a solution that
	extends the capabilities offered by a raw public key approach.		extends the capabilities offered by a raw public key approach.
	15.1.6. subjectPublicKeyInfo		15.1.6. subjectPublicKeyInfo
	The SubjectPublicKeyInfo structure indicates the algorithm and any		The SubjectPublicKeyInfo structure indicates the algorithm and any
	associated parameters for the ECC public key. This profile uses the		associated parameters for the ECC public key. This profile uses the
	id-ecPublicKey algorithm identifier for ECDSA signature keys, as		id-ecPublicKey algorithm identifier for ECDSA signature keys, as
	defined and specified in [RFC5480].		defined and specified in [RFC5480].
	15.2. Root CA Certificate		15.2. Root CA Certificate
	* basicConstraints MUST be present and MUST be marked critical. The		* basicConstraints MUST be present and MUST be marked critical. The
	cA field MUST be set true. The pathLenConstraint field SHOULD NOT		cA field MUST be set true. The pathLenConstraint field SHOULD NOT
	skipping to change at page 8, line 46 ¶		skipping to change at page 9, line 39 ¶
	which are standardized, allow provision of certificates on a regular		which are standardized, allow provision of certificates on a regular
	basis. This enables a deployment model where IoT device utilize end-		basis. This enables a deployment model where IoT device utilize end-
	entity certificates with shorter lifetime making certificate		entity certificates with shorter lifetime making certificate
	revocation protocols, like OCSP and CRLs, less relevant.		revocation protocols, like OCSP and CRLs, less relevant.
	Hence, instead of performing certificate revocation checks on the IoT		Hence, instead of performing certificate revocation checks on the IoT
	device itself this specification recommends to delegate this task to		device itself this specification recommends to delegate this task to
	the IoT device operator and to take the necessary action to allow IoT		the IoT device operator and to take the necessary action to allow IoT
	devices to remain operational.		devices to remain operational.
	16.1. Open Issues		17. Certificate Overhead
			In a public key-based key exchange, certificates and public keys are
			a major contributor to the size of the overall handshake. For
			example, in a regular TLS 1.3 handshake with minimal ECC certificates
			and no intermediate CA utilizing the secp256r1 curve with mutual
			authentication, around 40% of the entire handshake payload is
			consumed by the two exchanged certificates.
			Hence, it is not surprising that there is a strong desire to reduce
			the size of certificates and certificate chains. This has lead to
			various standardization efforts. Here is a brief summary of what
			options an implementer has to reduce the bandwidth requirements of a
			public key-based key exchange:
			* Use elliptic curve cryptography (ECC) instead of RSA-based
			certificate due to the smaller certificate size.
			* Avoid deep and complex CA hierarchies to reduce the number of
			intermediate CA certificates that need to be transmitted.
			* Pay attention to the amount of information conveyed inside
			certificates.
			* Use session resumption to reduce the number of times a full
			handshake is needed. Use Connection IDs
			[I-D.ietf-tls-dtls-connection-id], when possible, to enable long-
			lasting connections.
			* Use the TLS cached info [RFC7924] extension to avoid sending
			certificates with every full handshake.
			* Use client certificate URLs [RFC6066] instead of full certificates
			for clients.
			* Use certificate compression as defined in
			[I-D.ietf-tls-certificate-compression].
			* Use alternative certificate formats, where possible, such as raw
			public keys [RFC7250] or CBOR-encoded certificates
			[I-D.ietf-cose-cbor-encoded-cert].
			The use of certificate handles, as introduced in cTLS
			[I-D.ietf-tls-ctls], is a form of caching or compressing certificates
			as well.
			Whether to utilize any of the above extensions or a combination of
			them depends on the anticipated deployment environment, the
			availability of code, and the constraints imposed by already deployed
			infrastructure (e.g., CA infrastructure, tool support).
			17.1. Open Issues
	A list of open issues can be found at https://github.com/thomas-		A list of open issues can be found at https://github.com/thomas-
	fossati/draft-tls13-iot/issues		fossati/draft-tls13-iot/issues
	17. Security Considerations		18. Security Considerations
	This entire document is about security.		This entire document is about security.
	18. Acknowledgements		19. Acknowledgements
	We would like to thank Ben Kaduk and John Mattsson.		We would like to thank Ben Kaduk and John Mattsson.
	19. IANA Considerations		20. IANA Considerations
	IANA is asked to add the Option defined in Figure 2 to the CoAP		IANA is asked to add the Option defined in Figure 2 to the CoAP
	Option Numbers registry.		Option Numbers registry.
	+--------+------------+-----------+		+--------+------------+-----------+
	| Number | Name | Reference |		| Number | Name | Reference |
	+--------+------------+-----------+		+--------+------------+-----------+
	| TBD | Early-Data | RFCThis |		| TBD | Early-Data | RFCThis |
	+--------+------------+-----------+		+--------+------------+-----------+
	skipping to change at page 9, line 37 ¶		skipping to change at page 11, line 24 ¶
	CoAP Response Code registry.		CoAP Response Code registry.
	+--------+-------------+-----------+		+--------+-------------+-----------+
	| Code | Description | Reference |		| Code | Description | Reference |
	+--------+-------------+-----------+		+--------+-------------+-----------+
	| 4.25 | Too Early | RFCThis |		| 4.25 | Too Early | RFCThis |
	+--------+-------------+-----------+		+--------+-------------+-----------+
	Figure 3: Too Early Response Code		Figure 3: Too Early Response Code
	20. References		21. References
	20.1. Normative References		21.1. Normative References
	[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-40, 20 January 2021, <http://www.ietf.org/internet-		dtls13-43, 30 April 2021,
	drafts/draft-ietf-tls-dtls13-40.txt>.		<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
			dtls13-43>.
	[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/rfc/rfc2119>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/rfc/rfc5280>.
	[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,		[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
	"Elliptic Curve Cryptography Subject Public Key		"Elliptic Curve Cryptography Subject Public Key
	Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,		Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
	<https://www.rfc-editor.org/info/rfc5480>.		<https://www.rfc-editor.org/rfc/rfc5480>.
	[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.		[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
	Polk, "Internet X.509 Public Key Infrastructure:		Polk, "Internet X.509 Public Key Infrastructure:
	Additional Algorithms and Identifiers for DSA and ECDSA",		Additional Algorithms and Identifiers for DSA and ECDSA",
	RFC 5758, DOI 10.17487/RFC5758, January 2010,		RFC 5758, DOI 10.17487/RFC5758, January 2010,
	<https://www.rfc-editor.org/info/rfc5758>.		<https://www.rfc-editor.org/rfc/rfc5758>.
	[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer		[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
	Security (TLS) / Datagram Transport Layer Security (DTLS)		Security (TLS) / Datagram Transport Layer Security (DTLS)
	Profiles for the Internet of Things", RFC 7925,		Profiles for the Internet of Things", RFC 7925,
	DOI 10.17487/RFC7925, July 2016,		DOI 10.17487/RFC7925, July 2016,
	<https://www.rfc-editor.org/info/rfc7925>.		<https://www.rfc-editor.org/rfc/rfc7925>.
	[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/rfc/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/rfc/rfc8446>.
	[RFC8449] Thomson, M., "Record Size Limit Extension for TLS",		[RFC8449] Thomson, M., "Record Size Limit Extension for TLS",
	RFC 8449, DOI 10.17487/RFC8449, August 2018,		RFC 8449, DOI 10.17487/RFC8449, August 2018,
	<https://www.rfc-editor.org/info/rfc8449>.		<https://www.rfc-editor.org/rfc/rfc8449>.
	[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/rfc/rfc8470>.
	20.2. Informative References		21.2. Informative References
			[I-D.ietf-cose-cbor-encoded-cert]
			Raza, S., Höglund, J., Selander, G., Mattsson, J. P., and
			M. Furuhed, "CBOR Encoded X.509 Certificates (C509
			Certificates)", Work in Progress, Internet-Draft, draft-
			ietf-cose-cbor-encoded-cert-01, 25 May 2021,
			<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
			cbor-encoded-cert-01>.
	[I-D.ietf-suit-architecture]		[I-D.ietf-suit-architecture]
	Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A		Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
	Firmware Update Architecture for Internet of Things", Work		Firmware Update Architecture for Internet of Things", Work
	in Progress, Internet-Draft, draft-ietf-suit-architecture-		in Progress, Internet-Draft, draft-ietf-suit-architecture-
	15, 17 January 2021, <http://www.ietf.org/internet-drafts/		16, 27 January 2021,
	draft-ietf-suit-architecture-15.txt>.		<https://datatracker.ietf.org/doc/html/draft-ietf-suit-
			architecture-16>.
			[I-D.ietf-tls-certificate-compression]
			Ghedini, A. and V. Vasiliev, "TLS Certificate
			Compression", Work in Progress, Internet-Draft, draft-
			ietf-tls-certificate-compression-10, 6 January 2020,
			<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
			certificate-compression-10>.
			[I-D.ietf-tls-ctls]
			Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS
			1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
			ctls-02, 5 May 2021,
			<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
			ctls-02>.
			[I-D.ietf-tls-dtls-connection-id]
			Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus,
			"Connection Identifiers for DTLS 1.2", Work in Progress,
			Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22
			June 2021, <https://datatracker.ietf.org/doc/html/draft-
			ietf-tls-dtls-connection-id-13>.
	[I-D.ietf-tls-esni]		[I-D.ietf-tls-esni]
	Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS		Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
	Encrypted Client Hello", Work in Progress, Internet-Draft,		Encrypted Client Hello", Work in Progress, Internet-Draft,
	draft-ietf-tls-esni-09, 16 December 2020,		draft-ietf-tls-esni-12, 7 July 2021,
	<http://www.ietf.org/internet-drafts/draft-ietf-tls-esni-		<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
	09.txt>.		esni-12>.
			[I-D.ietf-uta-rfc7525bis]
			Sheffer, Y., Holz, R., Saint-Andre, P., and T. Fossati,
			"Recommendations for Secure Use of Transport Layer
			Security (TLS) and Datagram Transport Layer Security
			(DTLS)", Work in Progress, Internet-Draft, draft-ietf-uta-
			rfc7525bis-01, 7 July 2021,
			<https://datatracker.ietf.org/doc/html/draft-ietf-uta-
			rfc7525bis-01>.
			[I-D.irtf-cfrg-hpke]
			Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood,
			"Hybrid Public Key Encryption", Work in Progress,
			Internet-Draft, draft-irtf-cfrg-hpke-10, 7 July 2021,
			<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
			hpke-10>.
			[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
			Extensions: Extension Definitions", RFC 6066,
			DOI 10.17487/RFC6066, January 2011,
			<https://www.rfc-editor.org/rfc/rfc6066>.
			[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
			Weiler, S., and T. Kivinen, "Using Raw Public Keys in
			Transport Layer Security (TLS) and Datagram Transport
			Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
			June 2014, <https://www.rfc-editor.org/rfc/rfc7250>.
			[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
			and P. Hoffman, "Specification for DNS over Transport
			Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
			2016, <https://www.rfc-editor.org/rfc/rfc7858>.
			[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
			(TLS) Cached Information Extension", RFC 7924,
			DOI 10.17487/RFC7924, July 2016,
			<https://www.rfc-editor.org/rfc/rfc7924>.
			[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
			Transport Layer Security (DTLS)", RFC 8094,
			DOI 10.17487/RFC8094, February 2017,
			<https://www.rfc-editor.org/rfc/rfc8094>.
			[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
			(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
			<https://www.rfc-editor.org/rfc/rfc8484>.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Arm Limited		Arm Limited
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	Thomas Fossati		Thomas Fossati
	Arm Limited		Arm Limited
End of changes. 37 change blocks.
	85 lines changed or deleted		239 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/