< draft-fossati-tls-ext-header-00.txt		draft-fossati-tls-ext-header-01.txt >
	TLS Working Group T. Fossati		TLS Working Group T. Fossati
	Internet-Draft Nokia		Internet-Draft Nokia
	Updates: RFC5246, RFC6347 (if approved) N. Mavrogiannopoulos		Updates: 5246, 6347 (if approved) N. Mavrogiannopoulos
	Intended status: Standards Track RedHat		Intended status: Standards Track RedHat
	Expires: July 28, 2018 January 24, 2018		Expires: September 4, 2018 March 03, 2018
	Record Header Extensions for TLS and DTLS		Record Header Extensions for DTLS
	draft-fossati-tls-ext-header-00		draft-fossati-tls-ext-header-01
	Abstract		Abstract
	This document proposes a mechanism to extend the record header in TLS		This document proposes a mechanism to extend the record header in
	and DTLS. To that aim, the (D)TLS header is modified as follows: the		DTLS. To that aim, the DTLS header is modified as follows: the
	length field is trimmed to 15 bits, and the length's top bit is given		length field is trimmed to 15 bits, and the length's top bit is given
	the "record header extension indicator" semantics, allowing a sender		the "record header extension indicator" semantics, allowing a sender
	to signal that one or more record header extensions have been added		to signal that one or more record header extensions have been added
	to this record. We define the generic format of a record header		to this record. We define the generic format of a record header
	extension and the general rules associated with its handling. Any		extension and the general rules associated with its handling. Any
	details regarding syntax, semantics and negotiation of a specific		details regarding syntax, semantics and negotiation of a specific
	record header extension, are left to future documents.		record header extension, are left to future documents.
	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 http://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 July 28, 2018.		This Internet-Draft will expire on September 4, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 3		3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. Backwards Compatibility . . . . . . . . . . . . . . . . . 4		3.3. Backwards Compatibility . . . . . . . . . . . . . . . . . 4
	3.4. Use with Connection ID . . . . . . . . . . . . . . . . . 4		3.4. Use with Connection ID . . . . . . . . . . . . . . . . . 4
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5		5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.1. Normative References . . . . . . . . . . . . . . . . . . 6		8.1. Normative References . . . . . . . . . . . . . . . . . . 6
	8.2. Informative References . . . . . . . . . . . . . . . . . 6		8.2. Informative References . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Length Redefined		2. Length Redefined
	Both TLS ([RFC5246], [I-D.ietf-tls-tls13]) and DTLS ([RFC6347],		DTLS ([RFC6347], [I-D.ietf-tls-dtls13]) requires the size of record
	[I-D.ietf-tls-dtls13]) require the size of TLS record payloads to not		payloads to not exceed 2^14 bytes - plus a small amount that accounts
	exceed 2^14 bytes - plus a small amount that accounts for compression		for compression or AEAD expansion. This means that the first bit in
	or AEAD expansion. This means that the first bit in the length field		the length field of the DTLS record header is, in fact, unused.
	of the TLS record header is, in fact, unused.
	The proposal (Figure 1) is to shorten the length field to 15 bits and		The proposal (Figure 1) is to shorten the length field to 15 bits and
	use the top bit (E) to signify the presence / absence of a record		use the top bit (E) to signify the presence / absence of a record
	header extension.		header extension.
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| ContentType |		| ContentType |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Version |E| Length |		| ProtocolVersion | epoch |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| sequence_number |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |E| length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ (zero or more) Extension Header(s) ~		~ (zero or more) Extension Header(s) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Payload (including optional MAC and padding) |		| Payload (including optional MAC and padding) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Length redefined		Figure 1: Length redefined
	Length counts the bytes of Payload and of all record header		Length counts the bytes of Payload and of all record header
	extensions that are added to this record (possibly none).		extensions that are added to this record (possibly none).
	skipping to change at page 4, line 10 ¶		skipping to change at page 4, line 13 ¶
	o Value is the record header extension itself.		o Value is the record header extension itself.
	The fact that Type only allows 16 record header extension is a		The fact that Type only allows 16 record header extension is a
	precise design choice: the allocation pool size is severely		precise design choice: the allocation pool size is severely
	constrained so to raise the entry bar for any new record header		constrained so to raise the entry bar for any new record header
	extension.		extension.
	3.2. Negotiation		3.2. Negotiation
	A record header extension is allowed only if it has been negotiated		A record header extension is allowed only if it has been negotiated
	via a companion TLS extension.		via a companion DTLS extension.
	An endpoint MUST NOT send a record header extension that hasn't been		An endpoint MUST NOT send a record header extension that hasn't been
	successfully negotiated with the receiver.		successfully negotiated with the receiver.
	An endpoint that receives an unexpected record header extension MUST		An endpoint that receives an unexpected record header extension MUST
	abort the session.		abort the session.
	Record header extensions MUST NOT be sent during the initial		Record header extensions MUST NOT be sent during the initial
	handshake phase.		handshake phase.
	3.3. Backwards Compatibility		3.3. Backwards Compatibility
	A legacy endpoint that receives a record header extension will		A legacy endpoint that receives a record header extension will
	interpret it as an invalid length field ([RFC5246],		interpret it as an invalid length field ([RFC6347],
	[I-D.ietf-tls-tls13]) and abort the session accordingly.		[I-D.ietf-tls-dtls13]) and abort the session accordingly.
	Note that this is equivalent to the behaviour of an endpoint		Note that this is equivalent to the behaviour of an endpoint
	implementing this spec which receives a non-negotiated record header		implementing this spec which receives a non-negotiated record header
	extension.		extension.
	3.4. Use with Connection ID		3.4. Use with Connection ID
	A plausible use of this mechanism is with the CID extension defined		A plausible use of this mechanism is with the CID extension defined
	in [I-D.ietf-tls-dtls-connection-id].		in [I-D.ietf-tls-dtls-connection-id].
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 38 ¶
	ContentType(s), using an invalid length), an ad hoc record header		ContentType(s), using an invalid length), an ad hoc record header
	extension provides a cleaner approach that can be used with any TLS		extension provides a cleaner approach that can be used with any TLS
	version at a reasonable cost - an overhead of 2 bytes per record.		version at a reasonable cost - an overhead of 2 bytes per record.
	4. Security Considerations		4. Security Considerations
	An on-path active attacker could try and modify an existing record		An on-path active attacker could try and modify an existing record
	header extension, insert a new record header extension in an existing		header extension, insert a new record header extension in an existing
	session, or alter the result of the negotiation in order to add or		session, or alter the result of the negotiation in order to add or
	remove arbitrary record header extensions. Given the security		remove arbitrary record header extensions. Given the security
	properties of TLS, none of the above can be tried without being		properties of DTLS, none of the above can be tried without being
	fatally noticed by the endpoints.		fatally noticed by the endpoints.
	A passive on-path attacker could potentially extrapolate useful		A passive on-path attacker could potentially extrapolate useful
	knowledge about endpoints from the information encoded in a record		knowledge about endpoints from the information encoded in a record
	header extension (see also Section 5).		header extension (see also Section 5).
	5. Privacy Considerations		5. Privacy Considerations
	The extent and consequences of metadata leakage from endpoints to		The extent and consequences of metadata leakage from endpoints to
	path when using a certain record header extension SHALL be assessed		path when using a certain record header extension SHALL be assessed
	in the document that introduces this new record header extension. If		in the document that introduces this new record header extension. If
	needed, the document SHALL describe the relevant risk mitigations.		needed, the document SHALL describe the relevant risk mitigations.
	6. IANA Considerations		6. IANA Considerations
	This document defines a new IANA registry that, for each new record		This document defines a new IANA registry that, for each new record
	header extension, shall provide its Type code-point.		header extension, shall provide its Type code-point.
	7. Acknowledgements		7. Acknowledgements
	TODO		Thanks to Adam Langley and Yoav Nir for comments and discussions that
			have helped shaping this document.
			This work is partially supported by the European Commission under
			Horizon 2020 grant agreement no. 688421 Measurement and Architecture
			for a Middleboxed Internet (MAMI). This support does not imply
			endorsement.
	8. References		8. References
	8.1. Normative References		8.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", draft-ietf-tls-dtls13-22 (work in progress),		1.3", draft-ietf-tls-dtls13-22 (work in progress),
	November 2017.		November 2017.
	[I-D.ietf-tls-tls13]		[I-D.ietf-tls-tls13]
	Rescorla, E., "The Transport Layer Security (TLS) Protocol		Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", draft-ietf-tls-tls13-23 (work in progress),		Version 1.3", draft-ietf-tls-tls13-25 (work in progress),
	January 2018.		March 2018.
	[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-
	<https://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5246>.		editor.org/info/rfc5246>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <https://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-tls-dtls-connection-id]		[I-D.ietf-tls-dtls-connection-id]
	Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom,		Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom,
	"The Datagram Transport Layer Security (DTLS) Connection		"The Datagram Transport Layer Security (DTLS) Connection
End of changes. 18 change blocks.
	28 lines changed or deleted		37 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/