< draft-ietf-tcpinc-tcpcrypt-08.txt		draft-ietf-tcpinc-tcpcrypt-09.txt >
	Network Working Group A. Bittau		Network Working Group A. Bittau
	Internet-Draft Google		Internet-Draft Google
	Intended status: Experimental D. Giffin		Intended status: Experimental D. Giffin
	Expires: April 24, 2018 Stanford University		Expires: May 6, 2018 Stanford University
	M. Handley		M. Handley
	University College London		University College London
	D. Mazieres		D. Mazieres
	Stanford University		Stanford University
	Q. Slack		Q. Slack
	Sourcegraph		Sourcegraph
	E. Smith		E. Smith
	Kestrel Institute		Kestrel Institute
	October 21, 2017		November 2, 2017
	Cryptographic protection of TCP Streams (tcpcrypt)		Cryptographic protection of TCP Streams (tcpcrypt)
	draft-ietf-tcpinc-tcpcrypt-08		draft-ietf-tcpinc-tcpcrypt-09
	Abstract		Abstract
	This document specifies tcpcrypt, a TCP encryption protocol designed		This document specifies tcpcrypt, a TCP encryption protocol designed
	for use in conjunction with the TCP Encryption Negotiation Option		for use in conjunction with the TCP Encryption Negotiation Option
	(TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating		(TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating
	resegmentation, NATs, and other manipulations of the TCP header. The		resegmentation, NATs, and other manipulations of the TCP header. The
	protocol is self-contained and specifically tailored to TCP		protocol is self-contained and specifically tailored to TCP
	implementations, which often reside in kernels or other environments		implementations, which often reside in kernels or other environments
	in which large external software dependencies can be undesirable.		in which large external software dependencies can be undesirable.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	tcpcrypt connection.		tcpcrypt connection.
	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 http://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 April 24, 2018.		This Internet-Draft will expire on May 6, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	3.8. Re-Keying . . . . . . . . . . . . . . . . . . . . . . . . 13		3.8. Re-Keying . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.9. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . 14		3.9. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . 14
	4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 15		4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	4.1. Key-Exchange Messages . . . . . . . . . . . . . . . . . . 15		4.1. Key-Exchange Messages . . . . . . . . . . . . . . . . . . 15
	4.2. Encryption Frames . . . . . . . . . . . . . . . . . . . . 17		4.2. Encryption Frames . . . . . . . . . . . . . . . . . . . . 17
	4.2.1. Plaintext . . . . . . . . . . . . . . . . . . . . . . 17		4.2.1. Plaintext . . . . . . . . . . . . . . . . . . . . . . 17
	4.2.2. Associated Data . . . . . . . . . . . . . . . . . . . 18		4.2.2. Associated Data . . . . . . . . . . . . . . . . . . . 18
	4.2.3. Frame Nonce . . . . . . . . . . . . . . . . . . . . . 19		4.2.3. Frame Nonce . . . . . . . . . . . . . . . . . . . . . 19
	4.3. Constant Values . . . . . . . . . . . . . . . . . . . . . 19		4.3. Constant Values . . . . . . . . . . . . . . . . . . . . . 19
	5. Key-Agreement Schemes . . . . . . . . . . . . . . . . . . . . 19		5. Key-Agreement Schemes . . . . . . . . . . . . . . . . . . . . 19
	6. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 20		6. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 21
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 21		8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	8.1. Asymmetric Roles . . . . . . . . . . . . . . . . . . . . 23		8.1. Asymmetric Roles . . . . . . . . . . . . . . . . . . . . 24
	8.2. Verified Liveness . . . . . . . . . . . . . . . . . . . . 23		8.2. Verified Liveness . . . . . . . . . . . . . . . . . . . . 24
	8.3. Mandatory Key-Agreement Schemes . . . . . . . . . . . . . 24		8.3. Mandatory Key-Agreement Schemes . . . . . . . . . . . . . 25
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	11.1. Normative References . . . . . . . . . . . . . . . . . . 25		11.1. Normative References . . . . . . . . . . . . . . . . . . 26
	11.2. Informative References . . . . . . . . . . . . . . . . . 26		11.2. Informative References . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Requirements Language		1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Introduction		2. Introduction
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 12 ¶
	decryption is performed, the tag allows authentication of the		decryption is performed, the tag allows authentication of the
	encrypted data and of optional, associated plaintext data.		encrypted data and of optional, associated plaintext data.
	3.2. Protocol Negotiation		3.2. Protocol Negotiation
	Tcpcrypt depends on TCP-ENO [I-D.ietf-tcpinc-tcpeno] to negotiate		Tcpcrypt depends on TCP-ENO [I-D.ietf-tcpinc-tcpeno] to negotiate
	whether encryption will be enabled for a connection, and also which		whether encryption will be enabled for a connection, and also which
	key-agreement scheme to use. TCP-ENO negotiates the use of a		key-agreement scheme to use. TCP-ENO negotiates the use of a
	particular TCP encryption protocol or _TEP_ by including protocol		particular TCP encryption protocol or _TEP_ by including protocol
	identifiers in ENO suboptions. This document associates four TEP		identifiers in ENO suboptions. This document associates four TEP
	identifiers with the tcpcrypt protocol, as listed in Table 2. Each		identifiers with the tcpcrypt protocol, as listed in Table 4. Each
	identifier indicates the use of a particular key-agreement scheme,		identifier indicates the use of a particular key-agreement scheme,
	with an associated CPRF and length parameters. Future standards may		with an associated CPRF and length parameters. Future standards may
	associate additional TEP identifiers with tcpcrypt, following the		associate additional TEP identifiers with tcpcrypt, following the
	assignment policy specified by TCP-ENO.		assignment policy specified by TCP-ENO.
	An active opener that wishes to negotiate the use of tcpcrypt		An active opener that wishes to negotiate the use of tcpcrypt
	includes an ENO option in its SYN segment. That option includes		includes an ENO option in its SYN segment. That option includes
	suboptions with tcpcrypt TEP identifiers indicating the key-agreement		suboptions with tcpcrypt TEP identifiers indicating the key-agreement
	schemes it is willing to enable. The active opener MAY additionally		schemes it is willing to enable. The active opener MAY additionally
	include suboptions indicating support for encryption protocols other		include suboptions indicating support for encryption protocols other
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 25 ¶
	"v" bits in ENO suboptions, so if host A offers resumption with a		"v" bits in ENO suboptions, so if host A offers resumption with a
	particular TEP and host B replies with a non-resumption suboption		particular TEP and host B replies with a non-resumption suboption
	with the same TEP, that may become the negotiated TEP and fresh key		with the same TEP, that may become the negotiated TEP and fresh key
	agreement will be performed. That is, sending a resumption suboption		agreement will be performed. That is, sending a resumption suboption
	also implies willingness to perform fresh key agreement with the		also implies willingness to perform fresh key agreement with the
	indicated TEP.		indicated TEP.
	As required by TCP-ENO, once a host has both sent and received an ACK		As required by TCP-ENO, once a host has both sent and received an ACK
	segment containing a valid ENO option, encryption MUST be enabled and		segment containing a valid ENO option, encryption MUST be enabled and
	plaintext application data MUST NOT ever be exchanged on the		plaintext application data MUST NOT ever be exchanged on the
	connection. If the negotiated TEP is among those listed in Table 2,		connection. If the negotiated TEP is among those listed in Table 4,
	a host MUST follow the protocol described in this document.		a host MUST follow the protocol described in this document.
	3.3. Key Exchange		3.3. Key Exchange
	Following successful negotiation of a tcpcrypt TEP, all further		Following successful negotiation of a tcpcrypt TEP, all further
	signaling is performed in the Data portion of TCP segments. Except		signaling is performed in the Data portion of TCP segments. Except
	when resumption was negotiated (described below in Section 3.5), the		when resumption was negotiated (described below in Section 3.5), the
	two hosts perform key exchange through two messages, "Init1" and		two hosts perform key exchange through two messages, "Init1" and
	"Init2", at the start of the data streams of host A and host B,		"Init2", at the start of the data streams of host A and host B,
	respectively. These messages may span multiple TCP segments and need		respectively. These messages may span multiple TCP segments and need
	not end at a segment boundary. However, the segment containing the		not end at a segment boundary. However, the segment containing the
	last byte of an "Init1" or "Init2" message MUST have TCP's push flag		last byte of an "Init1" or "Init2" message MUST have TCP's push flag
	(PSH) set.		(PSH) set.
	The key exchange protocol, in abstract, proceeds as follows:		The key exchange protocol, in abstract, proceeds as follows:
	A -> B: Init1 = { INIT1_MAGIC, sym-cipher-list, N_A, PK_A }		A -> B: Init1 = { INIT1_MAGIC, sym_cipher_list, N_A, PK_A }
	B -> A: Init2 = { INIT2_MAGIC, sym-cipher, N_B, PK_B }		B -> A: Init2 = { INIT2_MAGIC, sym_cipher, N_B, PK_B }
	The concrete format of these messages is specified in Section 4.1.		The concrete format of these messages is specified in Section 4.1.
	The parameters are defined as follows:		The parameters are defined as follows:
	o "INIT1_MAGIC", "INIT2_MAGIC": constants defined in Table 1.		o "INIT1_MAGIC", "INIT2_MAGIC": constants defined in Table 1.
	o "sym-cipher-list": a list of symmetric ciphers (AEAD algorithms)		o "sym_cipher_list": a list of symmetric ciphers (AEAD algorithms)
	acceptable to host A. These are specified in Table 3.		acceptable to host A. These are specified in Table 5.
	o "sym-cipher": the symmetric cipher selected by host B from the		o "sym_cipher": the symmetric cipher selected by host B from the
	"sym-cipher-list" sent by host A.		"sym_cipher_list" sent by host A.
	o "N_A", "N_B": nonces chosen at random by hosts A and B,		o "N_A", "N_B": nonces chosen at random by hosts A and B,
	respectively.		respectively.
	o "PK_A", "PK_B": ephemeral public keys for hosts A and B,		o "PK_A", "PK_B": ephemeral public keys for hosts A and B,
	respectively. These, as well as their corresponding private keys,		respectively. These, as well as their corresponding private keys,
	are short-lived values that SHOULD be refreshed periodically. The		are short-lived values that SHOULD be refreshed periodically. The
	private keys SHOULD NOT ever be written to persistent storage.		private keys SHOULD NOT ever be written to persistent storage.
	The ephemeral secret ("ES") is the result of the key-agreement		The ephemeral secret ("ES") is the result of the key-agreement
	skipping to change at page 8, line 27 ¶		skipping to change at page 8, line 27 ¶
	In the first session derived from fresh key-agreement, keys "k_ab[j]"		In the first session derived from fresh key-agreement, keys "k_ab[j]"
	are used by host A to encrypt and host B to decrypt, while keys		are used by host A to encrypt and host B to decrypt, while keys
	"k_ba[j]" are used by host B to encrypt and host A to decrypt. In a		"k_ba[j]" are used by host B to encrypt and host A to decrypt. In a
	resumed session, as described more thoroughly below in Section 3.5,		resumed session, as described more thoroughly below in Section 3.5,
	each host uses the keys in the same way as it did in the original		each host uses the keys in the same way as it did in the original
	session, regardless of its role in the current session: for example,		session, regardless of its role in the current session: for example,
	if a host played role "A" in the first session, it will use keys		if a host played role "A" in the first session, it will use keys
	"k_ab[j]" to encrypt in each derived session.		"k_ab[j]" to encrypt in each derived session.
	The value "ae_keylen" depends on the authenticated-encryption		The value "ae_keylen" depends on the authenticated-encryption
	algorithm selected, and is given under "Key Length" in Table 3.		algorithm selected, and is given under "Key Length" in Table 5.
	After host B sends "Init2" or host A receives it, that host may		After host B sends "Init2" or host A receives it, that host may
	immediately begin transmitting protected application data as		immediately begin transmitting protected application data as
	described in Section 3.6.		described in Section 3.6.
	If host A receives "Init2" with a "sym-cipher" value that was not		If host A receives "Init2" with a "sym_cipher" value that was not
	present in the "sym-cipher-list" it previously transmitted in		present in the "sym_cipher_list" it previously transmitted in
	"Init1", it MUST abort the connection and raise an error condition		"Init1", it MUST abort the connection and raise an error condition
	distinct from the end-of-file condition.		distinct from the end-of-file condition.
	Throughout this document, to "abort the connection" means to issue		Throughout this document, to "abort the connection" means to issue
	the "Abort" command as described in [RFC0793], Section 3.8. That is,		the "Abort" command as described in [RFC0793], Section 3.8. That is,
	the TCP connection is destroyed, RESET is transmitted, and the local		the TCP connection is destroyed, RESET is transmitted, and the local
	user is alerted to the abort event.		user is alerted to the abort event.
	3.4. Session ID		3.4. Session ID
	skipping to change at page 12, line 14 ¶		skipping to change at page 12, line 14 ¶
	3.6. Data Encryption and Authentication		3.6. Data Encryption and Authentication
	Following key exchange (or its omission via session resumption), all		Following key exchange (or its omission via session resumption), all
	further communication in a tcpcrypt-enabled connection is carried out		further communication in a tcpcrypt-enabled connection is carried out
	within delimited _encryption frames_ that are encrypted and		within delimited _encryption frames_ that are encrypted and
	authenticated using the agreed keys.		authenticated using the agreed keys.
	This protection is provided via algorithms for Authenticated		This protection is provided via algorithms for Authenticated
	Encryption with Associated Data (AEAD). The particular algorithms		Encryption with Associated Data (AEAD). The particular algorithms
	that may be used are listed in Table 3, and additional algorithms may		that may be used are listed in Table 5, and additional algorithms may
	be specified according to the policy in Section 7. One algorithm is		be specified according to the policy in Section 7. One algorithm is
	selected during the negotiation described in Section 3.3.		selected during the negotiation described in Section 3.3.
	The format of an encryption frame is specified in Section 4.2. A		The format of an encryption frame is specified in Section 4.2. A
	sending host breaks its stream of application data into a series of		sending host breaks its stream of application data into a series of
	chunks. Each chunk is placed in the "data" portion of a "plaintext"		chunks. Each chunk is placed in the "data" portion of a "plaintext"
	value, which is then encrypted to yield a frame's "ciphertext" field.		value, which is then encrypted to yield a frame's "ciphertext" field.
	Chunks must be small enough that the ciphertext (whose length depends		Chunks must be small enough that the ciphertext (whose length depends
	on the AEAD cipher used, and is generally slightly longer than the		on the AEAD cipher used, and is generally slightly longer than the
	plaintext) has length less than 2^16 bytes.		plaintext) has length less than 2^16 bytes.
	skipping to change at page 15, line 31 ¶		skipping to change at page 15, line 31 ¶
	| INIT1_MAGIC |		| INIT1_MAGIC |
	| |		| |
	+-------+-------+-------+-------+		+-------+-------+-------+-------+
	4 5 6 7		4 5 6 7
	+-------+-------+-------+-------+		+-------+-------+-------+-------+
	| message_len |		| message_len |
	| = M |		| = M |
	+-------+-------+-------+-------+		+-------+-------+-------+-------+
	8 K + 8		8
	+--------+---------+---------+---...---+-----------+		+--------+-----+----+-----+----+---...---+-----+-----+
	|nciphers|sym- |sym- | |sym- |		|nciphers|sym_ |sym_ | |sym_ |
	| = K |cipher[0]|cipher[1]| |cipher[K-1]|		| = K |cipher[0] |cipher[1] | |cipher[K-1]|
	+--------+---------+---------+---...---+-----------+		+--------+-----+----+-----+----+---...---+-----+-----+
	K + 9 K + 9 + N_A_LEN		2*K + 9 2*K + 9 + N_A_LEN
	| |		| |
	v v		v v
	+-------+---...---+-------+-------+---...---+-------+		+-------+---...---+-------+-------+---...---+-------+
	| N_A | PK_A |		| N_A | PK_A |
	| | |		| | |
	+-------+---...---+-------+-------+---...---+-------+		+-------+---...---+-------+-------+---...---+-------+
	M - 1		M - 1
	+-------+---...---+-------+		+-------+---...---+-------+
	| ignored |		| ignored |
	| |		| |
	+-------+---...---+-------+		+-------+---...---+-------+
	The constant "INIT1_MAGIC" is defined in Table 1. The four-byte		The constant "INIT1_MAGIC" is defined in Table 1. The four-byte
	field "message_len" gives the length of the entire "Init1" message,		field "message_len" gives the length of the entire "Init1" message,
	encoded as a big-endian integer. The "nciphers" field contains an		encoded as a big-endian integer. The "nciphers" field contains an
	integer value that specifies the number of one-byte symmetric-cipher		integer value that specifies the number of two-byte symmetric-cipher
	identifiers that follow. The "sym-cipher" bytes identify		identifiers that follow. The "sym_cipher[i]" identifiers indicate
	cryptographic algorithms in Table 3. The length "N_A_LEN" and the		cryptographic algorithms in Table 5. The length "N_A_LEN" and the
	length of "PK_A" are both determined by the negotiated TEP, as		length of "PK_A" are both determined by the negotiated TEP, as
	described in Section 5.		described in Section 5.
	Implementations of this protocol MUST construct "Init1" such that the		Implementations of this protocol MUST construct "Init1" such that the
	field "ignored" has zero length; that is, they must construct the		field "ignored" has zero length; that is, they must construct the
	message such that its end, as determined by "message_len", coincides		message such that its end, as determined by "message_len", coincides
	with the end of the field "PK_A". When receiving "Init1", however,		with the end of the field "PK_A". When receiving "Init1", however,
	implementations MUST permit and ignore any bytes following "PK_A".		implementations MUST permit and ignore any bytes following "PK_A".
	The "Init2" message has the following encoding:		The "Init2" message has the following encoding:
	byte 0 1 2 3		byte 0 1 2 3
	+-------+-------+-------+-------+		+-------+-------+-------+-------+
	| INIT2_MAGIC |		| INIT2_MAGIC |
	| |		| |
	+-------+-------+-------+-------+		+-------+-------+-------+-------+
	4 5 6 7 8		4 5 6 7 8 9
	+-------+-------+-------+-------+-------+		+-------+-------+-------+-------+-------+-------+
	| message_len |sym- |		| message_len | sym_cipher |
	| = M |cipher |		| = M | |
	+-------+-------+-------+-------+-------+		+-------+-------+-------+-------+-------+-------+
	9 9 + N_B_LEN		10 10 + N_B_LEN
	| |		| |
	v v		v v
	+-------+---...---+-------+-------+---...---+-------+		+-------+---...---+-------+-------+---...---+-------+
	| N_B | PK_B |		| N_B | PK_B |
	| | |		| | |
	+-------+---...---+-------+-------+---...---+-------+		+-------+---...---+-------+-------+---...---+-------+
	M - 1		M - 1
	+-------+---...---+-------+		+-------+---...---+-------+
	| ignored |		| ignored |
	| |		| |
	+-------+---...---+-------+		+-------+---...---+-------+
	The constant "INIT2_MAGIC" is defined in Table 1. The four-byte		The constant "INIT2_MAGIC" is defined in Table 1. The four-byte
	field "message_len" gives the length of the entire "Init2" message,		field "message_len" gives the length of the entire "Init2" message,
	encoded as a big-endian integer. The "sym-cipher" value is a		encoded as a big-endian integer. The "sym_cipher" value is a
	selection from the symmetric-cipher identifiers in the previously-		selection from the symmetric-cipher identifiers in the previously-
	received "Init1" message. The length "N_B_LEN" and the length of		received "Init1" message. The length "N_B_LEN" and the length of
	"PK_B" are both determined by the negotiated TEP, as described in		"PK_B" are both determined by the negotiated TEP, as described in
	Section 5.		Section 5.
	Implementations of this protocol MUST construct "Init2" such that the		Implementations of this protocol MUST construct "Init2" such that the
	field "ignored" has zero length; that is, they must construct the		field "ignored" has zero length; that is, they must construct the
	message such that its end, as determined by "message_len", coincides		message such that its end, as determined by "message_len", coincides
	with the end of the "PK_B" field. When receiving "Init2", however,		with the end of the "PK_B" field. When receiving "Init2", however,
	implementations MUST permit and ignore any bytes following "PK_B".		implementations MUST permit and ignore any bytes following "PK_B".
	skipping to change at page 19, line 47 ¶		skipping to change at page 19, line 47 ¶
	| 0x15101a0e | INIT1_MAGIC |		| 0x15101a0e | INIT1_MAGIC |
	| 0x097105e0 | INIT2_MAGIC |		| 0x097105e0 | INIT2_MAGIC |
	| 0x44415441 | FRAME_NONCE_MAGIC |		| 0x44415441 | FRAME_NONCE_MAGIC |
	+------------+-------------------+		+------------+-------------------+
	Table 1: Constant values used in the protocol		Table 1: Constant values used in the protocol
	5. Key-Agreement Schemes		5. Key-Agreement Schemes
	The TEP negotiated via TCP-ENO indicates the use of one of the key-		The TEP negotiated via TCP-ENO indicates the use of one of the key-
	agreement schemes named in Table 2. For example,		agreement schemes named in Table 4. For example,
	"TCPCRYPT_ECDHE_P256" names the tcpcrypt protocol using ECDHE-P256		"TCPCRYPT_ECDHE_P256" names the tcpcrypt protocol using ECDHE-P256
	together with the CPRF and length parameters specified below.		together with the CPRF and length parameters specified below.
	All the TEPs specified in this document require the use of HKDF-		All the TEPs specified in this document require the use of HKDF-
	Expand-SHA256 as the CPRF, and these lengths for nonces and session		Expand-SHA256 as the CPRF, and these lengths for nonces and session
	keys:		keys:
	N_A_LEN: 32 bytes		N_A_LEN: 32 bytes
	N_B_LEN: 32 bytes		N_B_LEN: 32 bytes
	K_LEN: 32 bytes		K_LEN: 32 bytes
	skipping to change at page 20, line 43 ¶		skipping to change at page 20, line 43 ¶
	Implementations SHOULD encode these "pubkey" values in "compressed		Implementations SHOULD encode these "pubkey" values in "compressed
	format", and MUST accept values encoded in "compressed",		format", and MUST accept values encoded in "compressed",
	"uncompressed" or "hybrid" formats.		"uncompressed" or "hybrid" formats.
	Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 use the		Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 use the
	functions X25519 and X448, respectively, to perform the Diffie-Helman		functions X25519 and X448, respectively, to perform the Diffie-Helman
	protocol as described in [RFC7748]. When using these ciphers,		protocol as described in [RFC7748]. When using these ciphers,
	public-key values "PK_A" and "PK_B" are transmitted directly with no		public-key values "PK_A" and "PK_B" are transmitted directly with no
	length prefix: 32 bytes for Curve25519, and 56 bytes for Curve448.		length prefix: 32 bytes for Curve25519, and 56 bytes for Curve448.
	The TEP "TCPCRYPT_ECDHE_Curve25519" is mandatory to implement. This		Implementations are required to implement certain TEPs, according to
	means a tcpcrypt implementation MUST support at least this TEP,		Table 2. Note that system administrators may configure which TEPs a
	although system administrators need not enable it.		host will negotiate, independent of these requirements.
			+-------------+---------------------------+
			| Requirement | TEP |
			+-------------+---------------------------+
			| MUST | TCPCRYPT_ECDHE_Curve25519 |
			| SHOULD | TCPCRYPT_ECDHE_Curve448 |
			| MAY | TCPCRYPT_ECDHE_P256 |
			| MAY | TCPCRYPT_ECDHE_P521 |
			+-------------+---------------------------+
			Table 2: Requirements for implementation of TEPs
	6. AEAD Algorithms		6. AEAD Algorithms
	Specifiers and key-lengths for AEAD algorithms are given in Table 3.		Specifiers and key-lengths for AEAD algorithms are given in Table 5.
	The algorithms "AEAD_AES_128_GCM" and "AEAD_AES_256_GCM" are		The algorithms "AEAD_AES_128_GCM" and "AEAD_AES_256_GCM" are
	specified in [RFC5116]. The algorithm "AEAD_CHACHA20_POLY1305" is		specified in [RFC5116]. The algorithm "AEAD_CHACHA20_POLY1305" is
	specified in [RFC7539].		specified in [RFC7539].
			Implementations are required to support certain algorithms according
			to Table 3. Note that system administrators may configure which
			algorithms a host will negotiate, independent of these requirements.
			+-------------+------------------------+
			| Requirement | AEAD Algorithm |
			+-------------+------------------------+
			| MUST | AEAD_AES_128_GCM |
			| SHOULD | AEAD_AES_256_GCM |
			| SHOULD | AEAD_CHACHA20_POLY1305 |
			+-------------+------------------------+
			Table 3: Requirements for implementation of AEAD algorithms
	7. IANA Considerations		7. IANA Considerations
	Tcpcrypt's TEP identifiers will need to be incorporated in IANA's		Tcpcrypt's TEP identifiers will need to be incorporated in IANA's
	"TCP encryption protocol identifiers" registry under the		"TCP encryption protocol identifiers" registry under the
	"Transmission Control Protocol (TCP) Parameters" registry, as in the		"Transmission Control Protocol (TCP) Parameters" registry, as in the
	following table. The various key-agreement schemes used by these		following table. The various key-agreement schemes used by these
	tcpcrypt variants are defined in Section 5.		tcpcrypt variants are defined in Section 5.
	+-------+---------------------------+-----------+		+-------+---------------------------+-----------+
	| Value | Meaning | Reference |		| Value | Meaning | Reference |
	+-------+---------------------------+-----------+		+-------+---------------------------+-----------+
	| 0x21 | TCPCRYPT_ECDHE_P256 | [RFC-TBD] |		| 0x21 | TCPCRYPT_ECDHE_P256 | [RFC-TBD] |
	| 0x22 | TCPCRYPT_ECDHE_P521 | [RFC-TBD] |		| 0x22 | TCPCRYPT_ECDHE_P521 | [RFC-TBD] |
	| 0x23 | TCPCRYPT_ECDHE_Curve25519 | [RFC-TBD] |		| 0x23 | TCPCRYPT_ECDHE_Curve25519 | [RFC-TBD] |
	| 0x24 | TCPCRYPT_ECDHE_Curve448 | [RFC-TBD] |		| 0x24 | TCPCRYPT_ECDHE_Curve448 | [RFC-TBD] |
	+-------+---------------------------+-----------+		+-------+---------------------------+-----------+
	Table 2: TEP identifiers for use with tcpcrypt		Table 4: TEP identifiers for use with tcpcrypt
	In Section 4.1, this document defines "sym-cipher" specifiers for		In Section 4.1, this document defines "sym_cipher" specifiers for
	which IANA is to maintain a new "tcpcrypt AEAD Algorithm" registry		which IANA is to maintain a new "tcpcrypt AEAD Algorithm" registry
	under the "Transmission Control Protocol (TCP) Parameters" registry,		under the "Transmission Control Protocol (TCP) Parameters" registry,
	with initial values as given in the following table. The AEAD		with initial values as given in the following table. The AEAD
	algorithms named there are defined in Section 6. Future assignments		algorithms named there are defined in Section 6. Future assignments
	are to be made under the "RFC Required" policy detailed in [RFC8126],		are to be made under the "RFC Required" policy detailed in [RFC8126],
	relying on early allocation [RFC7120] to facilitate testing before an		relying on early allocation [RFC7120] to facilitate testing before an
	RFC is finalized.		RFC is finalized.
	+-------+------------------------+------------+-----------+		+--------+------------------------+------------+-----------+
	| Value | AEAD Algorithm | Key Length | Reference |		| Value | AEAD Algorithm | Key Length | Reference |
	+-------+------------------------+------------+-----------+		+--------+------------------------+------------+-----------+
	| 0x01 | AEAD_AES_128_GCM | 16 bytes | [RFC-TBD] |		| 0x0001 | AEAD_AES_128_GCM | 16 bytes | [RFC-TBD] |
	| 0x02 | AEAD_AES_256_GCM | 32 bytes | [RFC-TBD] |		| 0x0002 | AEAD_AES_256_GCM | 32 bytes | [RFC-TBD] |
	| 0x10 | AEAD_CHACHA20_POLY1305 | 32 bytes | [RFC-TBD] |		| 0x0010 | AEAD_CHACHA20_POLY1305 | 32 bytes | [RFC-TBD] |
	+-------+------------------------+------------+-----------+		+--------+------------------------+------------+-----------+
	Table 3: Authenticated-encryption algorithms corresponding to sym-		Table 5: Authenticated-encryption algorithms corresponding to
	cipher specifiers in Init1 and Init2 messages.		sym_cipher specifiers in Init1 and Init2 messages.
	8. Security Considerations		8. Security Considerations
	Public-key generation, public-key encryption, and shared-secret		Public-key generation, public-key encryption, and shared-secret
	generation all require randomness. Other tcpcrypt functions may also		generation all require randomness. Other tcpcrypt functions may also
	require randomness, depending on the algorithms and modes of		require randomness, depending on the algorithms and modes of
	operation selected. A weak pseudo-random generator at either host		operation selected. A weak pseudo-random generator at either host
	will compromise tcpcrypt's security. Many of tcpcrypt's		will compromise tcpcrypt's security. Many of tcpcrypt's
	cryptographic functions require random input, and thus any host		cryptographic functions require random input, and thus any host
	implementing tcpcrypt MUST have access to a cryptographically-secure		implementing tcpcrypt MUST have access to a cryptographically-secure
	skipping to change at page 24, line 29 ¶		skipping to change at page 25, line 22 ¶
	The IETF's appraisal of best current practice on this matter		The IETF's appraisal of best current practice on this matter
	[RFC7696] says, "Ideally, two independent sets of mandatory-to-		[RFC7696] says, "Ideally, two independent sets of mandatory-to-
	implement algorithms will be specified, allowing for a primary suite		implement algorithms will be specified, allowing for a primary suite
	and a secondary suite. This approach ensures that the secondary		and a secondary suite. This approach ensures that the secondary
	suite is widely deployed if a flaw is found in the primary one."		suite is widely deployed if a flaw is found in the primary one."
	To meet that ideal, it might appear natural to also mandate ECDHE		To meet that ideal, it might appear natural to also mandate ECDHE
	using P-256, as this scheme is well-studied, widely implemented, and		using P-256, as this scheme is well-studied, widely implemented, and
	sufficiently different from the Curve25519-based scheme that it is		sufficiently different from the Curve25519-based scheme that it is
	unlikely they will both suffer from a single cryptoanalytic advance.		unlikely they will both suffer from a single (non-quantum)
			cryptanalytic advance.
	However, implementing the Diffie-Hellman function using NIST elliptic		However, implementing the Diffie-Hellman function using NIST elliptic
	curves (including those specified for use with tcpcrypt, P-256 and		curves (including those specified for use with tcpcrypt, P-256 and
	P-521) appears to be very difficult to achieve without introducing		P-521) appears to be very difficult to achieve without introducing
	vulnerability to side-channel attacks [nist-ecc]. Although well-		vulnerability to side-channel attacks [nist-ecc]. Although well-
	trusted implementations are available as part of large cryptographic		trusted implementations are available as part of large cryptographic
	libraries, these may be difficult to extract for use in operating-		libraries, these may be difficult to extract for use in operating-
	system kernels where tcpcrypt is usually best implemented. In		system kernels where tcpcrypt is usually best implemented. In
	contrast, the characteristics of Curve25519 together with its recent		contrast, the characteristics of Curve25519 together with its recent
	popularity has led to many safe and efficient implementations,		popularity has led to many safe and efficient implementations,
	including some that fit naturally into the kernel environment.		including some that fit naturally into the kernel environment.
	[RFC7696] insists that, "The selected algorithms need to be resistant		[RFC7696] insists that, "The selected algorithms need to be resistant
	to side-channel attacks and also meet the performance, power, and		to side-channel attacks and also meet the performance, power, and
	code size requirements on a wide variety of platforms." On this		code size requirements on a wide variety of platforms." On this
	principle, tcpcrypt excludes the NIST curves from the set of		principle, tcpcrypt excludes the NIST curves from the set of
	mandatory-to-implement key-agreement algorithms.		mandatory-to-implement key-agreement algorithms.
			Lastly, this document encourages (via SHOULD) support for key-
			agreement with Curve448 as this scheme appears likely to admit safe
			and efficient implementations; but it does not absolutely require
			such support, as well-proven implementations may not yet be
			available.
	9. Acknowledgments		9. Acknowledgments
	We are grateful for contributions, help, discussions, and feedback		We are grateful for contributions, help, discussions, and feedback
	from the TCPINC working group, including Marcelo Bagnulo, David		from the TCPINC working group and from other IETF reviewers,
	Black, Bob Briscoe, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Yoav		including Marcelo Bagnulo, David Black, Bob Briscoe, Jana Iyengar,
	Nir, Christoph Paasch, Eric Rescorla, and Kyle Rose.		Stephen Kent, Tero Kivinen, Mirja Kuhlewind, Yoav Nir, Christoph
			Paasch, Eric Rescorla, Kyle Rose, and Dale Worley.
	This work was funded by gifts from Intel (to Brad Karp) and from		This work was funded by gifts from Intel (to Brad Karp) and from
	Google; by NSF award CNS-0716806 (A Clean-Slate Infrastructure for		Google; by NSF award CNS-0716806 (A Clean-Slate Infrastructure for
	Information Flow Control); by DARPA CRASH under contract		Information Flow Control); by DARPA CRASH under contract
	#N66001-10-2-4088; and by the Stanford Secure Internet of Things		#N66001-10-2-4088; and by the Stanford Secure Internet of Things
	Project.		Project.
	10. Contributors		10. Contributors
	Dan Boneh and Michael Hamburg were co-authors of the draft that		Dan Boneh and Michael Hamburg were co-authors of the draft that
	skipping to change at page 25, line 41 ¶		skipping to change at page 26, line 41 ¶
	[nist-dss]		[nist-dss]
	NIST, "FIPS PUB 186-4: Digital Signature Standard (DSS)",		NIST, "FIPS PUB 186-4: Digital Signature Standard (DSS)",
	2013.		2013.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, DOI 10.17487/RFC0793, September 1981,		RFC 793, DOI 10.17487/RFC0793, September 1981,
	<https://www.rfc-editor.org/info/rfc793>.		<https://www.rfc-editor.org/info/rfc793>.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
	DOI 10.17487/RFC2104, February 1997, <https://www.rfc-		DOI 10.17487/RFC2104, February 1997,
	editor.org/info/rfc2104>.		<https://www.rfc-editor.org/info/rfc2104>.
	[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, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated		[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
	Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,		Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
	<https://www.rfc-editor.org/info/rfc5116>.		<https://www.rfc-editor.org/info/rfc5116>.
	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand		[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,		Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010, <https://www.rfc-		DOI 10.17487/RFC5869, May 2010,
	editor.org/info/rfc5869>.		<https://www.rfc-editor.org/info/rfc5869>.
	[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code		[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
	Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January		Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
	2014, <https://www.rfc-editor.org/info/rfc7120>.		2014, <https://www.rfc-editor.org/info/rfc7120>.
	[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF		[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
	Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,		Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
	<https://www.rfc-editor.org/info/rfc7539>.		<https://www.rfc-editor.org/info/rfc7539>.
	[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves		[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
	skipping to change at page 26, line 41 ¶		skipping to change at page 27, line 41 ¶
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-tcpinc-api]		[I-D.ietf-tcpinc-api]
	Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres,		Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres,
	D., and E. Smith, "Interface Extensions for TCP-ENO and		D., and E. Smith, "Interface Extensions for TCP-ENO and
	tcpcrypt", draft-ietf-tcpinc-api-05 (work in progress),		tcpcrypt", draft-ietf-tcpinc-api-05 (work in progress),
	September 2017.		September 2017.
	[nist-ecc]		[nist-ecc]
	Bernstein, D. and T. Lange, "Failures in NIST's ECC		Bernstein, D. and T. Lange, "Failures in NIST's ECC
	standards", 2016, <https://cr.yp.to/newelliptic/nistecc-		standards", 2016,
	20160106.pdf>.		<https://cr.yp.to/newelliptic/nistecc-20160106.pdf>.
	[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -		[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122,		Communication Layers", STD 3, RFC 1122,
	DOI 10.17487/RFC1122, October 1989, <https://www.rfc-		DOI 10.17487/RFC1122, October 1989,
	editor.org/info/rfc1122>.		<https://www.rfc-editor.org/info/rfc1122>.
	[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm		[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
	Agility and Selecting Mandatory-to-Implement Algorithms",		Agility and Selecting Mandatory-to-Implement Algorithms",
	BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,		BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
	<https://www.rfc-editor.org/info/rfc7696>.		<https://www.rfc-editor.org/info/rfc7696>.
	[tcpcrypt]		[tcpcrypt]
	Bittau, A., Hamburg, M., Handley, M., Mazieres, D., and D.		Bittau, A., Hamburg, M., Handley, M., Mazieres, D., and D.
	Boneh, "The case for ubiquitous transport-level		Boneh, "The case for ubiquitous transport-level
	encryption", USENIX Security , 2010.		encryption", USENIX Security , 2010.
End of changes. 38 change blocks.
	75 lines changed or deleted		108 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/