draft-ietf-tls-ctls-00.txt		draft-ietf-tls-ctls-01.txt
	TLS Working Group E. Rescorla		TLS Working Group E. Rescorla
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Informational R. Barnes		Intended status: Informational R. Barnes
	Expires: 28 October 2020 Cisco		Expires: 6 May 2021 Cisco
	H. Tschofenig		H. Tschofenig
	Arm Limited		Arm Limited
	26 April 2020		2 November 2020
	Compact TLS 1.3		Compact TLS 1.3
	draft-ietf-tls-ctls-00		draft-ietf-tls-ctls-01
	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, and a template-based specialization technique. cTLS		tighter encoding, and a template-based specialization technique. cTLS
	is not directly interoperable with TLS 1.3, but it should eventually		is not directly interoperable with TLS 1.3, but it should eventually
	be possible for a cTLS/TLS 1.3 server to exist and successfully		be possible for a cTLS/TLS 1.3 server to exist and successfully
	interoperate.		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 October 2020.		This Internet-Draft will expire on 6 May 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (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 14 ¶		skipping to change at page 2, line 14 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3		2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
	3. Common Primitives . . . . . . . . . . . . . . . . . . . . . . 3		3. Common Primitives . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Varints . . . . . . . . . . . . . . . . . . . . . . . . . 3		3.1. Varints . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 5		3.3. Handshake Layer . . . . . . . . . . . . . . . . . . . . . 6
	4. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 6		4. Handshake Messages . . . . . . . . . . . . . . . . . . . . . 7
	4.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 7
	4.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 6		4.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 7		4.3. HelloRetryRequest . . . . . . . . . . . . . . . . . . . . 7
	5. Template-Based Specialization . . . . . . . . . . . . . . . . 7		5. Template-Based Specialization . . . . . . . . . . . . . . . . 8
	5.1. Specifying a Specialization . . . . . . . . . . . . . . . 8		5.1. Specifying a Specialization . . . . . . . . . . . . . . . 8
	5.1.1. Requirements on the TLS Implementation . . . . . . . 10		5.1.1. Requirements on the TLS Implementation . . . . . . . 10
	5.1.2. Predefined Extensions . . . . . . . . . . . . . . . . 10		5.1.2. Predefined Extensions . . . . . . . . . . . . . . . . 11
	5.1.3. Known Certificates . . . . . . . . . . . . . . . . . 11		5.1.3. Known Certificates . . . . . . . . . . . . . . . . . 12
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	9. Normative References . . . . . . . . . . . . . . . . . . . . 13		9. Normative References . . . . . . . . . . . . . . . . . . . . 14
	Appendix A. Sample Transcripts . . . . . . . . . . . . . . . . . 13		Appendix A. Sample Transcripts . . . . . . . . . . . . . . . . . 15
	A.1. ECDHE and Mutual Certificate-based Authentication . . . . 14		A.1. ECDHE and Mutual Certificate-based Authentication . . . . 15
	A.2. PSK . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		A.2. PSK . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	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 four basic techniques:		The space reduction is achieved by four basic techniques:
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	3. Common Primitives		3. Common Primitives
	3.1. Varints		3.1. Varints
	cTLS makes use of variable-length integers in order to allow a wide		cTLS makes use of variable-length integers in order to allow a wide
	integer range while still providing for a minimal encoding. The		integer range while still providing for a minimal encoding. The
	width of the integer is encoded in the first two bits of the field as		width of the integer is encoded in the first two bits of the field as
	follows, with xs indicating bits that form part of the integer.		follows, with xs indicating bits that form part of the integer.
	+----------------------------+----------------+		+============================+================+
	| Bit pattern | Length (bytes) |		| Bit pattern | Length (bytes) |
	+============================+================+		+============================+================+
	| 0xxxxxxx | 1 |		| 0xxxxxxx | 1 |
	+----------------------------+----------------+		+----------------------------+----------------+
	+----------------------------+----------------+		+----------------------------+----------------+
	| 10xxxxxx xxxxxxxx | 2 |		| 10xxxxxx xxxxxxxx | 2 |
	+----------------------------+----------------+		+----------------------------+----------------+
	+----------------------------+----------------+		+----------------------------+----------------+
	| 11xxxxxx xxxxxxxx xxxxxxxx | 3 |		| 11xxxxxx xxxxxxxx xxxxxxxx | 3 |
	+----------------------------+----------------+		+----------------------------+----------------+
	Table 1		Table 1
	Thus, one byte can be used to carry values up to 127.		Thus, one byte can be used to carry values up to 127.
	In the TLS syntax variable integers are denoted as "varint" and a		In the TLS syntax variable integers are denoted as "varint" and a
	vector with a top range of a varint is denoted as:		vector with a top range of a varint is denoted as:
	opaque foo<1..V>;		opaque foo<1..V>;
	cTLS replaces all integers in TLS with varints, including:		cTLS uses the varint encoding for all multi-byte integers in TLS,
			including:
	* Values of uint8, uint16, uint24, uint32, and uint64
	* Vector length prefixes		* Values of type uint16, uint24, uint32, uint64
	* Enum / code point values		* Array and vector entries of these types
	We do not show the structures which only change in this way.		* Encoded lengths for vectors that allow more than 255 entries
	This allows implementations' encoding and decoding logic to implement		* Enums that allow more than 255 entries
	cTLS simply by having a mode in which integers always use the varint
	encoding. Note that if implementations treat opaque data in the same
	way as "uint8" values, they MUST NOT convert the bytes of an opaque
	value to varints.
	As an example, suppose we are given the following struct:		Values of type uint8, opaque values, and one-byte enums are not
			affected. We do not show the structures which only change in this
			way.
	struct {		3.2. Record Layer
	uint32 FieldA;
	opaque FieldB<0..2^16-1>;
	} ExampleStruct;
	Encoding a value of this type with values FieldA=0x0A and		The only cTLS records that are sent in plaintext are handshake
	FieldB=0x0B0B0B0B0B would result in the following octet strings in		records (ClientHello and ServerHello/HRR). The content type is
	"normal" (RFC 8446) and "compact" modes, respectively:		therefore constant (it is always "handshake"), so we instead set the
			"content_type" field to a fixed cTLS-specific value to distinguish
			cTLS plaintext records from encrypted records, TLS/DTLS records, and
			other protocols using the same 5-tuple.
	Normal: 0000000A00050B0B0B0B0B		The "profile_id" field allows the client and server to agree on which
	Compact: 0A050B0B0B0B0B		compression profile should be used for this session (see Section 5).
			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.
	3.2. Record Layer		struct {
			ContentType content_type = ctls_handshake;
			varint profile_id;
			opaque fragment<0..V>;
			} CTLSPlaintext;
	The cTLS Record Layer assumes that records are externally framed		[[OPEN ISSUE: The profile_id is needed in the ClientHello to inform
	(i.e., that the length is already known because it is carried in a		the server what compression profile to use. For a ServerHello this
	UDP datagram or the like). Depending on how this was carried, you		field is not required. Should we make this field optional?]]
	might need another byte or two for that framing. Thus, only the type
	byte need be carried and TLSPlaintext becomes:
	struct {		Encrypted records use DTLS 1.3 record framing, comprising a
	ContentType type;		configuration octet followed by optional connection ID, sequence
	opaque fragment[TLSPlaintext.length];		number, and length fields.
	} TLSPlaintext;
	In addition, because the epoch is known in advance, the dummy content		0 1 2 3 4 5 6 7
	type is not needed for the ciphertext, so TLSCiphertext becomes:		+-+-+-+-+-+-+-+-+
			|0|0|1|C|S|L|E E|
			+-+-+-+-+-+-+-+-+
			| Connection ID | Legend:
			| (if any, |
			/ length as / C - Connection ID (CID) present
			| negotiated) | S - Sequence number length
			+-+-+-+-+-+-+-+-+ L - Length present
			| 8 or 16 bit | E - Epoch
			|Sequence Number|
			| (if present) |
			+-+-+-+-+-+-+-+-+
			| 16 bit Length |
			| (if present) |
			+-+-+-+-+-+-+-+-+
	struct {		struct {
	opaque content[TLSPlaintext.length];		opaque unified_hdr[variable];
	ContentType type;		opaque encrypted_record[length];
	uint8 zeros[length_of_padding];		} CTLSCiphertext;
	} TLSInnerPlaintext;
	struct {		The presence and size of the connection ID field is negotiated as in
	opaque encrypted_record[TLSCiphertext.length];		DTLS.
	} TLSCiphertext;
	Note: The user is responsible for ensuring that the sequence numbers/		As with DTLS, the length field MAY be omitted by clearing the L bit,
	nonces are handled in the usual fashion.		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
			multiple DTLSCiphertext format records without length fields in the
			same datagram. In stream-oriented transports (e.g., TCP), the length
			field MUST be present. For use over other transports length
			information may be inferred from the underlying layer.
			Normal DTLS does not provide a mechanism for suppressing the sequence
			number field entirely. In cases where a sequence number is not
			required (e.g., when a reliable transport is in use), a cTLS
			implementation may suppress it by setting the
			"suppressSequenceNumber" flag in the compression profile being used
			(see Section 5.1). When this flag is enabled, the S bit in the
			configuration octet MUST be cleared.
	3.3. Handshake Layer		3.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:
	1. The length field is omitted		1. The length field is omitted
	2. The HelloRetryRequest message is a true handshake message instead		2. The HelloRetryRequest message is a true handshake message instead
	of a specialization of ServerHello.		of a specialization of ServerHello.
	skipping to change at page 8, line 4 ¶		skipping to change at page 8, line 36 ¶
	One way of thinking of this is as if specialization is a stateful		One way of thinking of this is as if specialization is a stateful
	compression layer between the handshake and the record layer:		compression layer between the handshake and the record layer:
	+---------------+---------------+---------------+		+---------------+---------------+---------------+
	| Handshake | Application | Alert |		| Handshake | Application | Alert |
	+---------------+---------------+---------------+ +---------+		+---------------+---------------+---------------+ +---------+
	| cTLS Compression Layer |<---| Profile |		| cTLS Compression Layer |<---| Profile |
	+---------------+---------------+---------------+ +---------+		+---------------+---------------+---------------+ +---------+
	| cTLS Record Layer / Application |		| cTLS Record Layer / Application |
	+---------------+---------------+---------------+		+---------------+---------------+---------------+
	Specializations are defined by a "compression profile" that specifies		Specializations are defined by a "compression profile" that specifies
	what features are to be optimized out of the handshake. In the		what features are to be optimized out of the handshake. In the
	following subsections, we define the structure of these profiles, and		following subsections, we define the structure of these profiles, and
	how they are used in compressing and decompressing handshake		how they are used in compressing and decompressing handshake
	messages.		messages.
	[[OPEN ISSUE: Do we want to have an explicit cTLS extension
	indicating that cTLS is in use and which specialization is in use?
	This goes back to whether we want the use of cTLS to be explicit.]]
	5.1. Specifying a Specialization		5.1. Specifying a Specialization
	A compression profile defining of a specialized version of TLS is		A compression profile defining of a specialized version of TLS is
	defined using a JSON dictionary. Each axis of specialization is a		defined using a JSON dictionary. Each axis of specialization is a
	key in the dictionary. [[OPEN ISSUE: If we ever want to serialize		key in the dictionary. [[OPEN ISSUE: If we ever want to serialize
	this, we'll want to use a list instead.]].		this, we'll want to use a list instead.]].
	For example, the following specialization describes a protocol with a		For example, the following specialization describes a protocol with a
	single fixed version (TLS 1.3) and a single fixed cipher suite		single fixed version (TLS 1.3) and a single fixed cipher suite
	(TLS_AES_128_GCM_SHA256). On the wire, ClientHello.cipher_suites,		(TLS_AES_128_GCM_SHA256). On the wire, ClientHello.cipher_suites,
	ServerHello.cipher_suites, and the supported_versions extensions in		ServerHello.cipher_suites, and the supported_versions extensions in
	the ClientHello and ServerHello would be omitted.		the ClientHello and ServerHello would be omitted.
	{		{
			"profileID": 33,
	"version" : 772,		"version" : 772,
	"cipherSuite" : "TLS_AES_128_GCM_SHA256"		"cipherSuite" : "TLS_AES_128_GCM_SHA256"
	}		}
	cTLS allows specialization along the following axes:		cTLS allows specialization along the following axes:
			profileID (integer): The identifier for this profile, to be sent in
			the "profile_id" field of CTLSPlaintext records. This value MUST
			NOT be zero. If this value is not present, the default
			"profile_id" is 1.
			suppressSequenceNumber (boolean): If present and set to true, the
			sequence number field is omitted from encrypted record headers.
	version (integer): indicates that both sides agree to the single TLS		version (integer): indicates that both sides agree to the single TLS
	version specified by the given integer value (772 == 0x0304 for		version specified by the given integer value (772 == 0x0304 for
	TLS 1.3). The supported_versions extension is omitted from		TLS 1.3). The supported_versions extension is omitted from
	ClientHello.extensions and reconstructed in the transcript as a		ClientHello.extensions and reconstructed in the transcript as a
	single-valued list with the specified value. The		single-valued list with the specified value. The
	supported_versions extension is omitted from		supported_versions extension is omitted from
	ClientHello.extensions and reconstructed in the transcript with		ClientHello.extensions and reconstructed in the transcript with
	the specified value.		the specified value.
	cipherSuite (string): indicates that both sides agree to the single		cipherSuite (string): indicates that both sides agree to the single
	skipping to change at page 12, line 20 ¶		skipping to change at page 13, line 20 ¶
	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.
	6. Examples		6. Examples
	The following section provides some example specializations.		The following section provides some example specializations.
	TLS 1.3 only:		TLS 1.3 only:
	{		{
	"Version" : 0x0304		"version" : 0x0304
	}		}
	TLS 1.3 with AES_GCM and X25519 and ALPN h2, short random values, and		TLS 1.3 with AES_GCM and X25519 and ALPN h2, short random values, and
	everything else is ordinary TLS 1.3.		everything else is ordinary TLS 1.3.
	{		{
	"Version" : 772,		"version" : 772,
	"Random": 16,		"randomSize": 16,
	"CipherSuite" : "TLS_AES_128_GCM_SHA256",		"cipherSuite" : "TLS_AES_128_GCM_SHA256",
	"DHGroup": "X25519",		"dhGroup": "X25519",
	"Extensions": {		"clientHelloExtensions": {
	"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 14, line 11 ¶
	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.
	8. IANA Considerations		8. IANA Considerations
	This document has no IANA actions.		This document requests that a code point be allocated from the "TLS
			ContentType registry. This value must be in the range 0-31
			(inclusive). The row to be added in the registry has the following
			form:
			+=======+=============+=========+===========+
			| Value | Description | DTLS-OK | Reference |
			+=======+=============+=========+===========+
			| TBD | ctls | N | RFCXXXX |
			+-------+-------------+---------+-----------+
			Table 2
			[[ RFC EDITOR: Please replace the value TBD with the value assigned
			by IANA, and the value XXXX to the RFC number assigned for this
			document. ]]
			[[OPEN ISSUE: Should we require standards action for all profile IDs
			that would fit in 2 octets.]]
	9. Normative References		9. Normative References
	[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,
	skipping to change at page 15, line 29 ¶		skipping to change at page 17, line 17 ¶
	00 // CertificateRequestContext.length		00 // CertificateRequestContext.length
	00 // Extensions.length		00 // Extensions.length
	0b // Certificate		0b // Certificate
	00 // CertificateRequestContext		00 // CertificateRequestContext
	03 // CertificateList		03 // CertificateList
	01 // CertData.length		01 // CertData.length
	61 // CertData = 'a'		61 // CertData = 'a'
	00 // Extensions.length		00 // Extensions.length
	0f // CertificateVerify		0f // CertificateVerify
	0403 // SignatureAlgorithm		0403 // SignatureAlgorithm
	4047 3045...10ce // Signature		4047 // Signature.length
			3045...f60e // Signature
	14 // Finished		14 // Finished
	bfc9d66715bb2b04 // VerifyData		bfc9d66715bb2b04 // VerifyData
	Client Flight: 91 bytes = SIG(71) + MAC(8) + CERTID(1) + Overhead(11)		Client Flight: 91 bytes = SIG(71) + MAC(8) + CERTID(1) + Overhead(11)
	0b // Certificate		0b // Certificate
	00 // CertificateRequestContext		00 // CertificateRequestContext
	03 // CertificateList		03 // CertificateList
	01 // CertData.length		01 // CertData.length
	62 // CertData = 'b'		62 // CertData = 'b'
	00 // Extensions.length		00 // Extensions.length
	0f // CertificateVerify		0f // CertificateVerify
	0403 // SignatureAlgorithm		0403 // SignatureAlgorithm
	4047 3045...f60e // Signature.length		4047 // Signature.length
			3045...f60e // Signature
	14 // Finished		14 // Finished
	35e9c34eec2c5dc1 // VerifyData		35e9c34eec2c5dc1 // VerifyData
	A.2. PSK		A.2. PSK
	Compression Profile:		Compression Profile:
	{		{
	"version": 772,		"version": 772,
	"cipherSuite": "TLS_AES_128_CCM_8_SHA256",		"cipherSuite": "TLS_AES_128_CCM_8_SHA256",
End of changes. 33 change blocks.
	77 lines changed or deleted		130 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/