draft-ietf-tls-ctls-04.txt		draft-ietf-tls-ctls-05.txt
	TLS Working Group E. Rescorla		TLS Working Group E. Rescorla
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track R. Barnes		Intended status: Standards Track R. Barnes
	Expires: 28 April 2022 Cisco		Expires: 8 September 2022 Cisco
	H. Tschofenig		H. Tschofenig
	Arm Limited		Arm Limited
	25 October 2021		7 March 2022
	Compact TLS 1.3		Compact TLS 1.3
	draft-ietf-tls-ctls-04		draft-ietf-tls-ctls-05
	Abstract		Abstract
	This document specifies a "compact" version of TLS 1.3. It is		This document specifies a "compact" version of TLS 1.3. It is
	isomorphic to TLS 1.3 but saves space by trimming obsolete material,		isomorphic to TLS 1.3 but saves space by trimming obsolete material,
	tighter encoding, a template-based specialization technique, and		tighter encoding, a template-based specialization technique, and
	alternative cryptographic techniques. cTLS is not directly		alternative cryptographic techniques. cTLS is not directly
	interoperable with TLS 1.3, but it should eventually be possible for		interoperable with TLS 1.3, but it should eventually be possible for
	a cTLS/TLS 1.3 server to exist and successfully interoperate.		a cTLS/TLS 1.3 server to exist and successfully interoperate.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 28 April 2022.		This Internet-Draft will expire on 8 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		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 Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3		2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
	2.1. Template-based Specialization . . . . . . . . . . . . . . 3		2.1. Template-based Specialization . . . . . . . . . . . . . . 3
	2.1.1. Requirements on TLS Implementations . . . . . . . . . 6		2.1.1. Requirements on TLS Implementations . . . . . . . . . 7
	2.1.2. Predefined Extensions . . . . . . . . . . . . . . . . 7		2.1.2. Predefined Extensions . . . . . . . . . . . . . . . . 7
	2.1.3. Known Certificates . . . . . . . . . . . . . . . . . 8		2.1.3. Known Certificates . . . . . . . . . . . . . . . . . 8
	2.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 9		2.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 9
	2.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 10		2.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 10
	3. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 11		3. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 11
	3.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 11		3.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 11
	3.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 11		3.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 12
	3.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 12		3.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 12
	4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12		4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7. Normative References . . . . . . . . . . . . . . . . . . . . 13		6.1. Adding a ContentType . . . . . . . . . . . . . . . . . . 13
	Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 14		6.2. Template Keys . . . . . . . . . . . . . . . . . . . . . . 13
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16		7. Normative References . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 15
			Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	DISCLAIMER: This is a work-in-progress draft of cTLS and has not yet		DISCLAIMER: This is a work-in-progress draft of cTLS and has not yet
	seen significant security analysis, so could contain major errors.		seen significant security analysis, so could contain major errors.
	It should not be used as a basis for building production systems.		It should not be used as a basis for building production systems.
	This document specifies a "compact" version of TLS 1.3 [RFC8446]. It		This document specifies a "compact" version of TLS 1.3 [RFC8446]. It
	is isomorphic to TLS 1.3 but designed to take up minimal bandwidth.		is isomorphic to TLS 1.3 but designed to take up minimal bandwidth.
	The space reduction is achieved by five basic techniques:		The space reduction is achieved by five basic techniques:
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	list with the specified value. The server_hello.cipher_suite		list with the specified value. The server_hello.cipher_suite
	field is omitted and reconstructed in the transcript as the		field is omitted and reconstructed in the transcript as the
	specified value.		specified value.
	dhGroup (string): specifies a single DH group to use for key		dhGroup (string): specifies a single DH group to use for key
	establishment. The group is listed by the code point name in		establishment. The group is listed by the code point name in
	[RFC8446], Section 4.2.7. (e.g., x25519). This implies a literal		[RFC8446], Section 4.2.7. (e.g., x25519). This implies a literal
	"supported_groups" extension consisting solely of this group.		"supported_groups" extension consisting solely of this group.
	signatureAlgorithm (string): specifies a single signature scheme to		signatureAlgorithm (string): specifies a single signature scheme to
	use for authentication. The group is listed by the code point		use for authentication. The signature algorithm is listed by the
	name in [RFC8446], Section 4.2.7. (e.g., ed25519). This implies a		code point name in [RFC8446], Section 4.2.3. (e.g.,
	literal "signature_algorithms" extension consisting solely of this		ecdsa_secp256r1_sha256). This implies a literal
	group.		"signature_algorithms" extension consisting solely of this group.
	random (integer): indicates that the ClientHello.Random and		random (integer): indicates that the ClientHello.Random and
	ServerHello.Random values are truncated to the given length. When		ServerHello.Random values are truncated to the given length. When
	the transcript is reconstructed, the Random is padded to the right		the transcript is reconstructed, the Random is padded to the right
	with 0s and the anti-downgrade mechanism in [RFC8446],		with 0s and the anti-downgrade mechanism in [RFC8446],
	Section 4.1.3 is disabled. IMPORTANT: Using short Random values		Section 4.1.3 is disabled. IMPORTANT: Using short Random values
	can lead to potential attacks. The Random length MUST be less		can lead to potential attacks. The Random length MUST be less
	than or equal to 32 bytes.		than or equal to 32 bytes.
	[[Open Issue: Karthik Bhargavan suggested the idea of hashing		[[Open Issue: Karthik Bhargavan suggested the idea of hashing
	skipping to change at page 6, line 49 ¶		skipping to change at page 6, line 49 ¶
	truncated to the given length. When the transcript is		truncated to the given length. When the transcript is
	reconstructed, the remainder of the Finished value is filled in by		reconstructed, the remainder of the Finished value is filled in by
	the receiving side.		the receiving side.
	[[OPEN ISSUE: How short should we allow this to be? TLS 1.3 uses the		[[OPEN ISSUE: How short should we allow this to be? TLS 1.3 uses the
	native hash and TLS 1.2 used 12 bytes. More analysis is needed to		native hash and TLS 1.2 used 12 bytes. More analysis is needed to
	know the minimum safe Finished size. See [RFC8446]; Section E.1 for		know the minimum safe Finished size. See [RFC8446]; Section E.1 for
	more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/		more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/
	TugB5ddJu3nYg7chcyeIyUqWSbA.]]		TugB5ddJu3nYg7chcyeIyUqWSbA.]]
			optional (object): contains keys that are not required to be
			understood by the client. Server operators MUST NOT place a key
			in this section unless the server is able to determine whether the
			key is in use based on the client data it receives. A key MUST
			NOT appear in both the main template and the optional section.
	2.1.1. Requirements on TLS Implementations		2.1.1. Requirements on TLS Implementations
	To be compatible with the specializations described in this section,		To be compatible with the specializations described in this section,
	a TLS stack needs to provide the following features:		a TLS stack needs to provide the following features:
	* If specialization of extensions is to be used, then the TLS stack		* If specialization of extensions is to be used, then the TLS stack
	MUST order each vector of Extension values in ascending order		MUST order each vector of Extension values in ascending order
	according to the ExtensionType. This allows for a deterministic		according to the ExtensionType. This allows for a deterministic
	reconstruction of the extension list.		reconstruction of the extension list.
	skipping to change at page 9, line 16 ¶		skipping to change at page 9, line 21 ¶
	whether a given cert_data value is compressed or uncompressed. Known		whether a given cert_data value is compressed or uncompressed. Known
	certificates objects SHOULD be constructed in such a way as to avoid		certificates objects SHOULD be constructed in such a way as to avoid
	a uncompressed object being mistaken for compressed one and		a uncompressed object being mistaken for compressed one and
	erroneously decompressed. For X.509, it is sufficient for the first		erroneously decompressed. For X.509, it is sufficient for the first
	byte of the compressed value (key) to have a value other than 0x30,		byte of the compressed value (key) to have a value other than 0x30,
	since every X.509 certificate starts with this byte.		since every X.509 certificate starts with this byte.
	2.2. Record Layer		2.2. Record Layer
	The only cTLS records that are sent in plaintext are handshake		The only cTLS records that are sent in plaintext are handshake
	records (ClientHello and ServerHello/HRR). The content type is		records (ClientHello and ServerHello/HRR) and alerts. cTLS alerts are
	therefore constant (it is always handshake), so we instead set the		the same as TLS alerts and use the same content types. For handshake
	content_type field to a fixed cTLS-specific value to distinguish cTLS		records, we set the content_type field to a fixed cTLS-specific value
	plaintext records from encrypted records, TLS/DTLS records, and other		to distinguish cTLS plaintext records from encrypted records, TLS/
	protocols using the same 5-tuple.		DTLS records, and other protocols using the same 5-tuple.
	The profile_id field allows the client and server to agree on which
	compression profile should be used for this session (see
	Section 2.1). This field MUST be set to zero if and only if no
	compression profile is used. Non-zero values are negotiated out of
	band between the client and server, as part of the specification of
	the compression profile.
	struct {		struct {
	ContentType content_type = ctls_handshake;		ContentType content_type = ctls_handshake;
	opaque profile_id<0..2^8-1>;		opaque fragment<0..2^16-1>;
	opaque fragment<0..V>;
	} CTLSPlaintext;		} CTLSPlaintext;
	[[OPEN ISSUE: The profile_id is needed in the ClientHello to inform		[[OPEN ISSUE: The profile_id is needed in the ClientHello to inform
	the server what compression profile to use. For a ServerHello this		the server what compression profile to use. For a ServerHello this
	field is not required. Should we make this field optional?]]		field is not required. Should we make this field optional?]]
	Encrypted records use DTLS 1.3 record framing, comprising a		Encrypted records use DTLS [I-D.draft-ietf-tls-dtls] 1.3 record
	configuration octet followed by optional connection ID, sequence		framing, comprising a configuration octet followed by optional
	number, and length fields.		connection ID, sequence number, and length fields. The encryption
			process and additional data are also as described in DTLS.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|0|0|1|C|S|L|E E|		|0|0|1|C|S|L|E E|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Connection ID | Legend:		| Connection ID | Legend:
	| (if any, |		| (if any, |
	/ length as / C - Connection ID (CID) present		/ length as / C - Connection ID (CID) present
	| negotiated) | S - Sequence number length		| negotiated) | S - Sequence number length
	+-+-+-+-+-+-+-+-+ L - Length present		+-+-+-+-+-+-+-+-+ L - Length present
	skipping to change at page 10, line 39 ¶		skipping to change at page 10, line 39 ¶
	As with DTLS, the length field MAY be omitted by clearing the L bit,		As with DTLS, the length field MAY be omitted by clearing the L bit,
	which means that the record consumes the entire rest of the data in		which means that the record consumes the entire rest of the data in
	the lower level transport. In this case it is not possible to have		the lower level transport. In this case it is not possible to have
	multiple DTLSCiphertext format records without length fields in the		multiple DTLSCiphertext format records without length fields in the
	same datagram. In stream-oriented transports (e.g., TCP), the length		same datagram. In stream-oriented transports (e.g., TCP), the length
	field MUST be present. For use over other transports length		field MUST be present. For use over other transports length
	information may be inferred from the underlying layer.		information may be inferred from the underlying layer.
	Normal DTLS does not provide a mechanism for suppressing the sequence		Normal DTLS does not provide a mechanism for suppressing the sequence
	number field entirely. In cases where a sequence number is not		number field entirely. When a reliable, ordered transport (e.g.,
	required (e.g., when a reliable transport is in use), a cTLS		TCP) is in use, the S bit in the configuration octet MUST be cleared
	implementation may suppress it by setting the suppressSequenceNumber		and the sequence number MUST be omitted. When an unreliable
	flag in the compression profile being used (see Section 2.1). When		transport is in use, the S bit has its usual meaning and the sequence
	this flag is enabled, the S bit in the configuration octet MUST be		number MUST be included.
	cleared.
	2.3. Handshake Layer		2.3. Handshake Layer
	The cTLS handshake framing is same as the TLS 1.3 handshake framing,		The cTLS handshake framing is same as the TLS 1.3 handshake framing,
	except for two changes:		except for two changes:
	* The length field is omitted.		* The length field is omitted.
	* The HelloRetryRequest message is a true handshake message instead		* The HelloRetryRequest message is a true handshake message instead
	of a specialization of ServerHello.		of a specialization of ServerHello.
	skipping to change at page 11, line 39 ¶		skipping to change at page 11, line 39 ¶
	been modified for space reduction and cleaned up to remove pre-TLS		been modified for space reduction and cleaned up to remove pre-TLS
	1.3 baggage.		1.3 baggage.
	3.1. ClientHello		3.1. ClientHello
	The cTLS ClientHello is defined as follows.		The cTLS ClientHello is defined as follows.
	opaque Random[RandomLength]; // variable length		opaque Random[RandomLength]; // variable length
	struct {		struct {
			opaque profile_id<0..2^8-1>;
	Random random;		Random random;
	CipherSuite cipher_suites<1..V>;		CipherSuite cipher_suites<1..2^16-1>;
	Extension extensions<1..V>;		Extension extensions<1..2^16-1>;
	} ClientHello;		} ClientHello;
			The client uses the profile_id field to inform the server about the
			compression profile being used (see Section 2.1). This field MUST be
			set to a zero-length value and only if no compression profile is
			used. Non zero-length values are agreed out of band between the
			client and server, as part of the specification of the compression
			profile.
	3.2. ServerHello		3.2. ServerHello
	We redefine ServerHello in the following way.		We redefine ServerHello in the following way.
	struct {		struct {
	Random random;		Random random;
	CipherSuite cipher_suite;		CipherSuite cipher_suite;
	Extension extensions<1..V>;		Extension extensions<1..2^16-1>;
	} ServerHello;		} ServerHello;
	3.3. HelloRetryRequest		3.3. HelloRetryRequest
	The HelloRetryRequest has the following format.		The HelloRetryRequest has the following format.
	struct {		struct {
	CipherSuite cipher_suite;		CipherSuite cipher_suite;
	Extension extensions<2..V>;		Extension extensions<2..2^16-1>;
	} HelloRetryRequest;		} HelloRetryRequest;
	The HelloRetryRequest is the same as the ServerHello above but		The HelloRetryRequest is the same as the ServerHello above but
	without the unnecessary sentinel Random value.		without the unnecessary sentinel Random value.
	4. Examples		4. Examples
	This section provides some example specializations.		This section provides some example specializations.
	For this example we use TLS 1.3 only with AES_GCM, X25519, ALPN h2,		For this example we use TLS 1.3 only with AES_GCM, X25519, ALPN h2,
	short random values, and everything else is ordinary TLS 1.3.		short random values, and everything else is ordinary TLS 1.3.
	{		{
	"Version" : 0x0304		"profile" : 1,
	"Profile" : 1,		"version" : 772,
	"Version" : 772,		"random": 16,
	"Random": 16,		"cipherSuite" : "TLS_AES_128_GCM_SHA256",
	"CipherSuite" : "TLS_AES_128_GCM_SHA256",		"dhGroup": "X25519",
	"DHGroup": "X25519",		"clientHelloExtensions": {
	"Extensions": {
	"named_groups": 29,		"named_groups": 29,
	"application_layer_protocol_negotiation" : "030016832",		"application_layer_protocol_negotiation" : "030016832",
	"..." : null		"..." : null
	}		}
	}		}
	Version 772 corresponds to the hex representation 0x0304, named group		Version 772 corresponds to the hex representation 0x0304, named group
	"29" (0x001D) represents X25519.		"29" (0x001D) represents X25519.
	[[OPEN ISSUE: Should we have a registry of well-known profiles?]]		[[OPEN ISSUE: Should we have a registry of well-known profiles?]]
	skipping to change at page 13, line 11 ¶		skipping to change at page 13, line 22 ¶
	which requires some analysis, especially as it looks like a potential		which requires some analysis, especially as it looks like a potential
	source of identity misbinding. This is, however, entirely separable		source of identity misbinding. This is, however, entirely separable
	from the rest of the specification.		from the rest of the specification.
	Transcript expansion also needs some analysis and we need to		Transcript expansion also needs some analysis and we need to
	determine whether we need an extension to indicate that cTLS is in		determine whether we need an extension to indicate that cTLS is in
	use and with which profile.		use and with which profile.
	6. IANA Considerations		6. IANA Considerations
			6.1. Adding a ContentType
	This document requests that a code point be allocated from the "TLS		This document requests that a code point be allocated from the "TLS
	ContentType registry. This value must be in the range 0-31		ContentType registry. This value must be in the range 0-31
	(inclusive). The row to be added in the registry has the following		(inclusive). The row to be added in the registry has the following
	form:		form:
	+=======+=============+=========+===========+		+=======+================+=========+===========+
	| Value | Description | DTLS-OK | Reference |		| Value | Description | DTLS-OK | Reference |
	+=======+=============+=========+===========+		+=======+================+=========+===========+
	| TBD | ctls | N | RFCXXXX |		| TBD | ctls | Y | RFCXXXX |
	+-------+-------------+---------+-----------+		+-------+----------------+---------+-----------+
			| TBD | ctls_handshake | Y | RFCXXXX |
			+-------+----------------+---------+-----------+
	Table 1		Table 1
	[[ RFC EDITOR: Please replace the value TBD with the value assigned		[[ RFC EDITOR: Please replace the value TBD with the value assigned
	by IANA, and the value XXXX to the RFC number assigned for this		by IANA, and the value XXXX to the RFC number assigned for this
	document. ]]		document. ]]
	[[OPEN ISSUE: Should we require standards action for all profile IDs		[[OPEN ISSUE: Should we require standards action for all profile IDs
	that would fit in 2 octets.]]		that would fit in 2 octets.]]
			6.2. Template Keys
			This document requests that IANA open a new registry entitled "cTLS
			Template Keys", on the Transport Layer Security (TLS) Parameters
			page, with a "Specification Required" registration policy and the
			following initial contents:
			+=======================+============+=================+
			| Key | JSON Type | Reference |
			+=======================+============+=================+
			| profile | number | (This document) |
			+-----------------------+------------+-----------------+
			| version | number | (This document) |
			+-----------------------+------------+-----------------+
			| cipherSuite | string | (This document) |
			+-----------------------+------------+-----------------+
			| dhGroup | string | (This document) |
			+-----------------------+------------+-----------------+
			| signatureAlgorithm | string | (This document) |
			+-----------------------+------------+-----------------+
			| random | number | (This document) |
			+-----------------------+------------+-----------------+
			| mutualAuth | true/false | (This document) |
			+-----------------------+------------+-----------------+
			| extension_order | object | (This document) |
			+-----------------------+------------+-----------------+
			| clientHelloExtensions | object | (This document) |
			+-----------------------+------------+-----------------+
			| serverHelloExtensions | object | (This document) |
			+-----------------------+------------+-----------------+
			| encryptedExtensions | object | (This document) |
			+-----------------------+------------+-----------------+
			| certRequestExtensions | object | (This document) |
			+-----------------------+------------+-----------------+
			| knownCertificates | object | (This document) |
			+-----------------------+------------+-----------------+
			| finishedSize | number | (This document) |
			+-----------------------+------------+-----------------+
			| optional | object | (This document) |
			+-----------------------+------------+-----------------+
			Table 2
	7. Normative References		7. Normative References
			[I-D.draft-ietf-tls-dtls]
			"*** BROKEN REFERENCE ***".
	[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>.
	[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
	skipping to change at page 15, line 10 ¶		skipping to change at page 16, line 10 ¶
	==================================		==================================
	Total 1158 232 22		Total 1158 232 22
	The following compression profile was used in this example:		The following compression profile was used in this example:
	{		{
	"profile": 1,		"profile": 1,
	"version": 772,		"version": 772,
	"cipherSuite": "TLS_AES_128_CCM_8_SHA256",		"cipherSuite": "TLS_AES_128_CCM_8_SHA256",
	"dhGroup": "X25519",		"dhGroup": "X25519",
	"signatureAlgorithm": "ECDSA_P256_SHA256",		"signatureAlgorithm": "ecdsa_secp256r1_sha256",
	"finishedSize": 8,		"finishedSize": 8,
	"clientHelloExtensions": {		"clientHelloExtensions": {
	"server_name": "000e00000b6578616d706c652e636f6d",		"server_name": "000e00000b6578616d706c652e636f6d",
	},		},
	"certificateRequestExtensions": {		"certificateRequestExtensions": {
	"certificate_request_context": 0,		"certificate_request_context": 0,
	"signature_algorithms": "00020403"		"signature_algorithms": "00020403"
	},		},
	"mutualAuth": true,		"mutualAuth": true,
	"extension-order": {		"extension-order": {
	"clientHelloExtensions": {		"clientHelloExtensions": [
	Key_share		"key_share"
	},		],
	"ServerHelloExtensions": {		"ServerHelloExtensions": [
	Key_share		"key_share"
	},		],
	},		},
	"knownCertificates": {		"knownCertificates": {
	"61": "3082...",		"61": "3082...",
	"62": "3082...",		"62": "3082...",
	"63": "...",		"63": "...",
	"64": "...",		"64": "...",
	...		...
	}		}
	}		}
	skipping to change at page 16, line 36 ¶		skipping to change at page 17, line 36 ¶
	0f // CertificateVerify		0f // CertificateVerify
	4064 // Signature.length		4064 // Signature.length
	3045...f60e // Signature		3045...f60e // Signature
	14 // Finished		14 // Finished
	35e9c34eec2c5dc1 // VerifyData		35e9c34eec2c5dc1 // VerifyData
	Acknowledgments		Acknowledgments
	We would like to thank Karthikeyan Bhargavan, Owen Friel, Sean		We would like to thank Karthikeyan Bhargavan, Owen Friel, Sean
	Turner, Martin Thomson and Chris Wood.		Turner, Benjamin Schwartz, Martin Thomson, and Chris Wood.
	Authors' Addresses		Authors' Addresses
	Eric Rescorla		Eric Rescorla
	Mozilla		Mozilla
	Email: ekr@rtfm.com		Email: ekr@rtfm.com
	Richard Barnes		Richard Barnes
	Cisco		Cisco
	Email: rlb@ipv.sx		Email: rlb@ipv.sx
	Hannes Tschofenig		Hannes Tschofenig
	Arm Limited		Arm Limited
	Email: hannes.tschofenig@arm.com		Email: hannes.tschofenig@arm.com
End of changes. 33 change blocks.
	70 lines changed or deleted		124 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/