< draft-ietf-uta-tls13-iot-profile-00.txt		draft-ietf-uta-tls13-iot-profile-01.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 5 June 2020		Intended status: Standards Track 22 February 2021
	Expires: 7 December 2020		Expires: 26 August 2021
	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-00		draft-ietf-uta-tls13-iot-profile-01
	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.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 7 December 2020.		This Internet-Draft will expire on 26 August 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		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 . . . . . . . . . . . . . . . . . . . 4
	7. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 4		7. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 4
	8. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 4		8. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	9. Random Number Generation . . . . . . . . . . . . . . . . . . 4		9. Random Number Generation . . . . . . . . . . . . . . . . . . 5
	10. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 5		10. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 5
	11. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 5		11. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 5
	12. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 5		12. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 5
	13. Key Length Recommendations . . . . . . . . . . . . . . . . . 5		13. Key Length Recommendations . . . . . . . . . . . . . . . . . 5
	14. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . . . 5		14. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . . . 5
	15. Certificate Profile . . . . . . . . . . . . . . . . . . . . . 6		15. Certificate Profile . . . . . . . . . . . . . . . . . . . . . 6
	15.1. Compression . . . . . . . . . . . . . . . . . . . . . . 6		15.1. All Certificates . . . . . . . . . . . . . . . . . . . . 6
	16. Security Considerations . . . . . . . . . . . . . . . . . . . 6		15.1.1. Version . . . . . . . . . . . . . . . . . . . . . . 6
	17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		15.1.2. Serial Number . . . . . . . . . . . . . . . . . . . 6
	18. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		15.1.3. Signature . . . . . . . . . . . . . . . . . . . . . 6
	18.1. Normative References . . . . . . . . . . . . . . . . . . 7		15.1.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . 6
	18.2. Informative References . . . . . . . . . . . . . . . . . 8		15.1.5. Validity . . . . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		15.1.6. subjectPublicKeyInfo . . . . . . . . . . . . . . . . 7
			15.2. Root CA Certificate . . . . . . . . . . . . . . . . . . 7
			15.3. Intermediate CA Certificate . . . . . . . . . . . . . . 7
			15.4. End Entity Certificate . . . . . . . . . . . . . . . . . 7
			15.4.1. Client Certificate Subject . . . . . . . . . . . . . 8
			16. Certificate Revocation Checks . . . . . . . . . . . . . . . . 8
			16.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . 8
			17. Security Considerations . . . . . . . . . . . . . . . . . . . 9
			18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
			19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
			20. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
			20.1. Normative References . . . . . . . . . . . . . . . . . . 9
			20.2. Informative References . . . . . . . . . . . . . . . . . 10
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	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 6, line 23 ¶		skipping to change at page 6, line 26 ¶
	| TBD | x | | | | Early-Data | empty | 0 | (none) | x |		| TBD | x | | | | Early-Data | empty | 0 | (none) | x |
	+-----+---+---+---+---+-------------+--------+--------+---------+---+		+-----+---+---+---+---+-------------+--------+--------+---------+---+
	C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable,		C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable,
	E=Encrypt and Integrity Protect (when using OSCORE)		E=Encrypt and Integrity Protect (when using OSCORE)
	Figure 1: Early-Data Option		Figure 1: Early-Data Option
	15. Certificate Profile		15. Certificate Profile
	This section is intended for discussing updates to the certificate		This section contains updates and clarifications to the certificate
	profile defined in [RFC7925]. Initial set of things to consider:		profile defined in [RFC7925]. The content of Table 1 of [RFC7925]
			has been split by certificate "type" in order to clarify exactly what
			requirements and recommendations apply to which entity in the PKI
			hierarchy.
	* pathLenConstraint		15.1. All Certificates
	Question: should also we move the ASN.1 schema from Appendix B of		15.1.1. Version
	[I-D.raza-ace-cbor-certificates] here and let it have it by
	reference?
	15.1. Compression		Certificates MUST be of type X.509 v3.
	The compression methods defined in		15.1.2. Serial Number
	[I-D.ietf-tls-certificate-compression] do not seem to deal
	effectively with [RFC7925] profiled certificates: zlib compresses the
	example cert by 9%, but other certificates and compression algorithms
	do in many cases increase the overall size. On the other hand,
	[I-D.raza-ace-cbor-certificates] provides a more efficient scheme,
	yielding to compression rates higher than 50% (see Section 3 of
	[I-D.mattsson-cose-cbor-cert-compress]).
	Question: should we RECOMMEND CBOR compression? How is that		CAs SHALL generate non-sequential Certificate serial numbers greater
	negotiated?		than zero (0) containing at least 64 bits of output from a CSPRNG
			(cryptographically secure pseudo-random number generator).
	16. Security Considerations		15.1.3. Signature
			The signature MUST be ecdsa-with-SHA256 or stronger [RFC5758].
			15.1.4. Issuer
			Contains the DN of the issuing CA.
			15.1.5. Validity
			No maximum validity period is mandated. Validity values are
			expressed as UTCTime in notBefore and notAfter fields, as mandated in
			[RFC5280].
			In many cases it is necessary to indicate that a certificate does not
			expire. This is likely to be the case for manufacturer-provisioned
			certificates. RFC 5280 provides a simple solution to convey the fact
			that a certificate has no well-defined expiration date by setting the
			notAfter to the GeneralizedTime value of 99991231235959Z.
			Some devices might not have a reliable source of time and for those
			devices it is also advisable to use certificates with no expiration
			date and to let a device management solution manage the lifetime of
			all the certificates used by the device. While this approach does
			not utilize certificates to its widest extent, it is a solution that
			extends the capabilities offered by a raw public key approach.
			15.1.6. subjectPublicKeyInfo
			The SubjectPublicKeyInfo structure indicates the algorithm and any
			associated parameters for the ECC public key. This profile uses the
			id-ecPublicKey algorithm identifier for ECDSA signature keys, as
			defined and specified in [RFC5480].
			15.2. Root CA Certificate
			* basicConstraints MUST be present and MUST be marked critical. The
			cA field MUST be set true. The pathLenConstraint field SHOULD NOT
			be present.
			* keyUsage MUST be present and MUST be marked critical. Bit
			position for keyCertSign MUST be set.
			* extendedKeyUsage MUST NOT be present.
			15.3. Intermediate CA Certificate
			* basicConstraints MUST be present and MUST be marked critical. The
			cA field MUST be set true. The pathLenConstraint field MAY be
			present.
			* keyUsage MUST be present and MUST be marked critical. Bit
			position for keyCertSign MUST be set.
			* extendedKeyUsage MUST NOT be present.
			15.4. End Entity Certificate
			* extendedKeyUsage MUST be present and contain at least one of id-
			kp-serverAuth or id-kp-clientAuth.
			* keyUsage MAY be present and contain one of digitalSignature or
			keyAgreement.
			* Domain names MUST NOT be encoded in the subject commonName,
			instead they MUST be encoded in a subjectAltName of type DNS-ID.
			Domain names MUST NOT contain wildcard ("*") characters.
			subjectAltName MUST NOT contain multiple names.
			15.4.1. Client Certificate Subject
			The requirement in Section 4.4.2 of [RFC7925] to only use EUI-64 for
			client certificates is lifted.
			If the EUI-64 format is used to identify the subject of a client
			certificate, it MUST be encoded in a subjectAltName of type DNS-ID as
			a string of the form "HH-HH-HH-HH-HH-HH-HH-HH" where 'H' is one of
			the symbols '0'-'9' or 'A'-'F'.
			16. Certificate Revocation Checks
			The considerations in Section 4.4.3 of [RFC7925] hold.
			Since the publication of RFC 7925 the need for firmware update
			mechanisms has been reinforced and the work on standardizing a secure
			and interoperable firmware update mechanism has made substantial
			progress, see [I-D.ietf-suit-architecture]. RFC 7925 recommends to
			use a software / firmware update mechanism to provision devices with
			new trust anchors.
			The use of device management protocols for IoT devices, which often
			include an onboarding or bootstrapping mechanism, has also seen
			considerable uptake in deployed devices and these protocols, some of
			which are standardized, allow provision of certificates on a regular
			basis. This enables a deployment model where IoT device utilize end-
			entity certificates with shorter lifetime making certificate
			revocation protocols, like OCSP and CRLs, less relevant.
			Hence, instead of performing certificate revocation checks on the IoT
			device itself this specification recommends to delegate this task to
			the IoT device operator and to take the necessary action to allow IoT
			devices to remain operational.
			16.1. Open Issues
			A list of open issues can be found at https://github.com/thomas-
			fossati/draft-tls13-iot/issues
			17. Security Considerations
	This entire document is about security.		This entire document is about security.
	17. IANA Considerations		18. Acknowledgements
			We would like to thank Ben Kaduk and John Mattsson.
			19. 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 7, line 29 ¶		skipping to change at page 9, line 37 ¶
	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
	18. References		20. References
	18.1. Normative References		20.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-38, 29 May 2020, <http://www.ietf.org/internet-		dtls13-40, 20 January 2021, <http://www.ietf.org/internet-
	drafts/draft-ietf-tls-dtls13-38.txt>.		drafts/draft-ietf-tls-dtls13-40.txt>.
	[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>.
			[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
			Housley, R., and W. Polk, "Internet X.509 Public Key
			Infrastructure Certificate and Certificate Revocation List
			(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
			<https://www.rfc-editor.org/info/rfc5280>.
			[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
			"Elliptic Curve Cryptography Subject Public Key
			Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
			<https://www.rfc-editor.org/info/rfc5480>.
			[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
			Polk, "Internet X.509 Public Key Infrastructure:
			Additional Algorithms and Identifiers for DSA and ECDSA",
			RFC 5758, DOI 10.17487/RFC5758, January 2010,
			<https://www.rfc-editor.org/info/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/info/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/info/rfc8174>.
	skipping to change at page 8, line 21 ¶		skipping to change at page 10, line 44 ¶
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/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/info/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/info/rfc8470>.
	18.2. Informative References		20.2. Informative References
	[I-D.ietf-tls-certificate-compression]		[I-D.ietf-suit-architecture]
	Ghedini, A. and V. Vasiliev, "TLS Certificate		Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
	Compression", Work in Progress, Internet-Draft, draft-		Firmware Update Architecture for Internet of Things", Work
	ietf-tls-certificate-compression-10, 6 January 2020,		in Progress, Internet-Draft, draft-ietf-suit-architecture-
	<http://www.ietf.org/internet-drafts/draft-ietf-tls-		15, 17 January 2021, <http://www.ietf.org/internet-drafts/
	certificate-compression-10.txt>.		draft-ietf-suit-architecture-15.txt>.
	[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. Wood, "TLS
	Encrypted Client Hello", Work in Progress, Internet-Draft,		Encrypted Client Hello", Work in Progress, Internet-Draft,
	draft-ietf-tls-esni-07, 1 June 2020, <http://www.ietf.org/		draft-ietf-tls-esni-09, 16 December 2020,
	internet-drafts/draft-ietf-tls-esni-07.txt>.		<http://www.ietf.org/internet-drafts/draft-ietf-tls-esni-
			09.txt>.
	[I-D.mattsson-cose-cbor-cert-compress]
	Mattsson, J., Selander, G., Raza, S., Hoglund, J., and M.
	Furuhed, "CBOR Object Signing and Encryption (COSE):
	Headers for Carrying CBOR Compressed Certificates", Work
	in Progress, Internet-Draft, draft-mattsson-cose-cbor-
	cert-compress-00, 9 March 2020, <http://www.ietf.org/
	internet-drafts/draft-mattsson-cose-cbor-cert-compress-
	00.txt>.
	[I-D.raza-ace-cbor-certificates]
	Raza, S., Hoglund, J., Selander, G., Mattsson, J., and M.
	Furuhed, "CBOR Profile of X.509 Certificates", Work in
	Progress, Internet-Draft, draft-raza-ace-cbor-
	certificates-04, 9 March 2020, <http://www.ietf.org/
	internet-drafts/draft-raza-ace-cbor-certificates-04.txt>.
	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. 22 change blocks.
	62 lines changed or deleted		179 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/