draft-rescorla-tcpinc-tls-option-05.txt		draft-rescorla-tcpinc-tls-option.txt
	TCPING E. Rescorla		TCPING E. Rescorla
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track October 19, 2015		Intended status: Standards Track October 21, 2015
	Expires: April 21, 2016		Expires: April 23, 2016
	TCP Use TLS Option		TCP Use TLS Option
	draft-rescorla-tcpinc-tls-option-05		draft-rescorla-tcpinc-tls-option-latest
	Abstract		Abstract
	This document defines the use of TLS [RFC5246] with the TCP-ENO		This document defines the use of TLS [RFC5246] with the TCP-ENO
	option [I-D.bittau-tcpinc-tcpeno].		option [I-D.bittau-tcpinc-tcpeno].
	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.
	skipping to change at page 1, line 31		skipping to change at page 1, line 31
	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 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 April 21, 2016.		This Internet-Draft will expire on April 23, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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		(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
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. TLS Profile . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. TCP-ENO Binding . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. TLS 1.3 Profile . . . . . . . . . . . . . . . . . . . . . 4		3.1. Suboption Definition . . . . . . . . . . . . . . . . . . 3
	3.1.1. Handshake Modes . . . . . . . . . . . . . . . . . . . 4		3.2. Session ID . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1.2. Basic 1-RTT Handshake . . . . . . . . . . . . . . . . 5		3.3. Channel Close . . . . . . . . . . . . . . . . . . . . . . 4
	3.1.3. Hello Retry Request [6.3.1.3] . . . . . . . . . . . . 8		4. TLS Profile . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1.4. Zero-RTT Exchange . . . . . . . . . . . . . . . . . . 9		4.1. TLS 1.3 Profile . . . . . . . . . . . . . . . . . . . . . 5
	3.1.5. Key Schedule . . . . . . . . . . . . . . . . . . . . 10		4.1.1. Handshake Modes . . . . . . . . . . . . . . . . . . . 5
	3.1.6. Record Protection . . . . . . . . . . . . . . . . . . 11		4.1.2. Basic 1-RTT Handshake . . . . . . . . . . . . . . . . 6
	3.2. TLS 1.2 Profile . . . . . . . . . . . . . . . . . . . . . 11		4.1.3. Hello Retry Request [6.3.1.3] . . . . . . . . . . . . 10
	3.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 12		4.1.4. Zero-RTT Exchange . . . . . . . . . . . . . . . . . . 10
	3.4. Session ID . . . . . . . . . . . . . . . . . . . . . . . 12		4.1.5. Key Schedule . . . . . . . . . . . . . . . . . . . . 12
	3.5. Cryptographic Algorithms . . . . . . . . . . . . . . . . 12		4.1.6. Record Protection . . . . . . . . . . . . . . . . . . 13
	4. Suboption Definition . . . . . . . . . . . . . . . . . . . . 12		4.2. TLS 1.2 Profile . . . . . . . . . . . . . . . . . . . . . 13
	5. Transport Integrity . . . . . . . . . . . . . . . . . . . . . 12		4.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 14
	6. Implementation Options . . . . . . . . . . . . . . . . . . . 13		4.4. Cryptographic Algorithms . . . . . . . . . . . . . . . . 14
	7. NAT/Firewall considerations . . . . . . . . . . . . . . . . . 13		5. Transport Integrity . . . . . . . . . . . . . . . . . . . . . 14
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6. API Considerations . . . . . . . . . . . . . . . . . . . . . 15
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 14		7. Implementation Considerations . . . . . . . . . . . . . . . . 15
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. NAT/Firewall considerations . . . . . . . . . . . . . . . . . 15
	10.1. Normative References . . . . . . . . . . . . . . . . . . 14		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	10.2. Informative References . . . . . . . . . . . . . . . . . 16		10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
			11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
			11.1. Normative References . . . . . . . . . . . . . . . . . . 16
			11.2. Informative References . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this		RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this
	draft is maintained in GitHub. Suggested changes should be submitted		draft is maintained in GitHub. Suggested changes should be submitted
	as pull requests at https://github.com/ekr/tcpinc-tls. Instructions		as pull requests at https://github.com/ekr/tcpinc-tls. Instructions
	are on that page as well.		are on that page as well.
	The TCPINC WG is chartered to define protocols to provide ubiquitous,		The TCPINC WG is chartered to define protocols to provide ubiquitous,
	transparent security for TCP connections. The WG is specifying The		transparent security for TCP connections. The WG is specifying The
	skipping to change at page 3, line 8		skipping to change at page 3, line 16
	The basic idea behind this draft is simple. The SYN and SYN/ACK		The basic idea behind this draft is simple. The SYN and SYN/ACK
	messages carry the TCP-ENO options indicating the willingness to do		messages carry the TCP-ENO options indicating the willingness to do
	TLS. If both sides want to do TLS, then a TLS handshake is started		TLS. If both sides want to do TLS, then a TLS handshake is started
	and once that completes, the data is TLS protected prior to being		and once that completes, the data is TLS protected prior to being
	sent over TCP. Otherwise, the application data is sent as usual.		sent over TCP. Otherwise, the application data is sent as usual.
	Client Server		Client Server
	SYN + TCP-ENO [TLS]->		SYN + TCP-ENO [TLS]->
	<- SYN/ACK + TCP-ENO [ENO]		<- SYN/ACK + TCP-ENO [TLS]
	ACK ->		ACK + TCP-ENO ->
	<---------------- TLS Handshake --------------->		<---------------- TLS Handshake --------------->
	<--------- Application Data over TLS ---------->		<--------- Application Data over TLS ---------->
	Figure 1: Negotiating TLS with TCP-TLS		Figure 1
	Client Server		Client Server
	SYN + TCP-ENO [TLS] ->		SYN + TCP-ENO [TLS] ->
	<- SYN/ACK		<- SYN/ACK
	ACK ->		ACK ->
	<--------- Application Data over TLS ---------->		<--------- Application Data over TCP ---------->
	Figure 2: Fall back to TCP		Figure 2: Fall back to TCP
	If use of TLS is negotiated, the data sent over TCP simply is TLS		If use of TLS is negotiated, the data sent over TCP simply is TLS
	data in compliance with TLS 1.2 [RFC5246] or TLS 1.3		data in compliance with TLS 1.2 [RFC5246] or TLS 1.3
	[I-D.ietf-tls-tls13].		[I-D.ietf-tls-tls13].
	Once the TLS handshake has completed, all application data SHALL be		Once the TLS handshake has completed, all application data SHALL be
	sent over that negotiated TLS channel. Application data MUST NOT be		sent over that negotiated TLS channel. Application data MUST NOT be
	sent prior to the TLS handshake.		sent prior to the TLS handshake.
	If the TLS handshake fails for non-cryptographic reasons such as		If the TLS handshake fails, the endpoint MUST tear down the TCP
	failure to negotiate a compatible cipher or the like, endpoints		connection and MUST NOT send plaintext data over the connection.
	SHOULD behave as if the the TCP-TLS option was not present. This is
	obviously not the conventional behavior for TLS failure, but as the
	entire idea here is to be opportunistic and the attacker can simply
	suppress the TCP-TLS option entirely, this provides the maximum
	robustness against broken intermediaries. If the TLS handshake fails
	for cryptographic reasons that indicate damage to the datastream
	(e.g., a decryption failure or a Finished failure) then the endpoints
	SHOULD signal a connection failure, as this suggests that there is a
	middlebox modifying the data and there is a reasonable chance that
	the state is now corrupted.
	3. TLS Profile		3. TCP-ENO Binding
			3.1. Suboption Definition
			TCP-ENO suboption with cs value set to [TBD]. Specifically, this
			means that the SYN contains a 1-byte suboption indicating support for
			this specification.
			bit 7 6 5 4 3 2 1 0
			+---+---+---+---+---+---+---+---+
			| 0 | TBD |
			+---+---+---+---+---+---+---+---+
			[[OPEN ISSUE: It would be nice to indicate the desire to have 0-RTT,
			but that would require a variable length suboption, which seems
			perhaps excessive. Maybe that's the right answer anyway.]]
			The SYN/ACK can be in one of two forms:
			o A 1-byte suboption as in the SYN.
			o A variable-length suboption. In this case, the remainder of the
			option contains a nonce to be used for 0-RTT (see Section 4.1.4.
			This nonce MUST be globally unique. Servers MUST NOT use this
			form of the suboption unless explicitly configured (see
			Section 6). [[OPEN ISSUE: I just thought this up recently, so
			it's possible it's totally half-baked and won't work. In
			particular, am I chewing up too much option space?]]
			The ACK simply contains the bare TCP-ENO suboption.
			3.2. Session ID
			TCP-ENO Section 4.1 defines a session ID feature (not to be confused
			with TLS Session IDs). When the protocol in use is TLS, the session
			ID is computed via a TLS Exporter [RFC5705] using the Exporter Label
			[[TBD]] and without a context value (the TCP-ENO transcript is
			incorporated via the TCPENOTranscript extension).
			3.3. Channel Close
			Because TLS security is provided in the TCP transport stream rather
			than at the segment level, the FIN is not an authenticated indicator
			of end of data. Instead implementations following this specification
			MUST send a TLS close_notify alert prior to sending a FIN and MUST
			raise an error if a FIN or RST is receive prior to receiving a
			close_notify.
			4. TLS Profile
	The TLS Profile defined in this document is intended to be a		The TLS Profile defined in this document is intended to be a
	compromise between two separate use cases. For the straight TCPINC		compromise between two separate use cases. For the straight TCPINC
	use case of ubiquitous transport encryption, we desire that		use case of ubiquitous transport encryption, we desire that
	implementations solely implement TLS 1.3 [I-D.ietf-tls-tls13] or		implementations solely implement TLS 1.3 [I-D.ietf-tls-tls13] or
	greater. However, we also want to allow the use of TCP-ENO as a		greater. However, we also want to allow the use of TCP-ENO as a
	signal for applications to do out-of-band negotiation of TLS, and		signal for applications to do out-of-band negotiation of TLS, and
	those applications are likely to already have support for TLS 1.2		those applications are likely to already have support for TLS 1.2
	[RFC5246]. In order to accomodate both cases, we specify a wire		[RFC5246]. In order to accomodate both cases, we specify a wire
	encoding that allows for negotiation of multiple TLS versions		encoding that allows for negotiation of multiple TLS versions
	(Section 4) but encourage implementations to implement only TLS 1.3.		(Section 3.1) but encourage implementations to implement only TLS
	Implementations which also implement TLS 1.2 MUST implement the		1.3. Implementations which also implement TLS 1.2 MUST implement the
	profile described in Section 3.2		profile described in Section 4.2
	3.1. TLS 1.3 Profile		4.1. TLS 1.3 Profile
	TLS 1.3 is the preferred version of TLS for this specification. In		TLS 1.3 is the preferred version of TLS for this specification. In
	order to facilitate implementation, this section provides a non-		order to facilitate implementation, this section provides a non-
	normative description of the parts of TLS 1.3 which are relevant to		normative description of the parts of TLS 1.3 which are relevant to
	TCPINC and defines a baseline of algorithms and modes which MUST be		TCPINC and defines a normative baseline of algorithms and modes which
	supported. Other modes, cipher suites, key exchange algorithms,		MUST be supported. Other modes, cipher suites, key exchange
	certificate formats as defined in [I-D.ietf-tls-tls13] MAY also be		algorithms, certificate formats as defined in [I-D.ietf-tls-tls13]
	used and that document remains the normative reference for TLS 1.3.		MAY also be used and that document remains the normative reference
	Bracketed references (e.g., [S. 1.2.3.4] refer to the corresponding		for TLS 1.3. Bracketed references (e.g., [S. 1.2.3.4] refer to the
	section in that document.) In order to match TLS terminology, we use		corresponding section in that document.) In order to match TLS
	the term "client" to indicate the TCP-ENO "A" role (See		terminology, we use the term "client" to indicate the TCP-ENO "A"
	[I-D.bittau-tcpinc-tcpeno]; Section 3.1) and "server" to indicate the		role (See [I-D.bittau-tcpinc-tcpeno]; Section 3.1) and "server" to
	"B" role.		indicate the "B" role.
	3.1.1. Handshake Modes		4.1.1. Handshake Modes
	TLS 1.3 as used in TCPINC supports two handshake modes, both based on		TLS 1.3 as used in TCPINC supports two handshake modes, both based on
	ECDHE key exchange.		Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.
	o A 1-RTT mode which is used when the client has no information		o A 1-RTT mode which is used when the client has no information
	about the server's keying material (see Figure 1)		about the server's keying material (see Figure 3)
	o A 0-RTT mode which is used when the client and server have		o A 0-RTT mode which is used when the client and server have
	connected previous and which allows the client to send data on the		connected previous and which allows the client to send data on the
	first flight (see Figure 2		first flight (see Figure 4)
	In both case, the server is expected to have an ECDSA signing key		In both case, the server is expected to have an Elliptic-Curve
	which may either be a freshly-generated key or a long-term key		Digital Signature Algorithm (ECDSA) signing key which may either be a
	(allowing TOFU-style applications). The key need not be associated		freshly-generated key or a long-term key (allowing Trust-On-First-Use
	with any certificate and can simply be a bare key.		(TOFU) style applications). The key need not be associated with any
			certificate and can simply be a bare key.
	Full TLS 1.3 includes support for additional modes based on pre-		Full TLS 1.3 includes support for additional modes based on pre-
	shared keys, but TCPINC implementations MAY opt to omit them.		shared keys, but TCPINC implementations MAY opt to omit them.
	Implementations MUST implement the 1-RTT mode and SHOULD implement		Implementations MUST implement the 1-RTT mode and SHOULD implement
	the 0-RTT mode.		the 0-RTT mode.
	Client Server		Client Server
	ClientHello		ClientHello
	+ ClientKeyShare -------->		+ ClientKeyShare
			+ TCPENOTranscript ------->
	ServerHello		ServerHello
	ServerKeyShare		ServerKeyShare
	{EncryptedExtensions}		{EncryptedExtensions}
	{ServerConfiguration*}		{ServerConfiguration*}
	{Certificate}		{Certificate}
	{CertificateVerify}		{CertificateVerify}
	<-------- {Finished}		<-------- {Finished}
			<-------- [Application Data]
	{Finished} -------->		{Finished} -------->
	[Application Data] <-------> [Application Data]		[Application Data] <-------> [Application Data]
	* Indicates optional or situation-dependent		* Indicates optional or situation-dependent
	messages that are not always sent.		messages that are not always sent.
	{} Indicates messages protected using keys		{} Indicates messages protected using keys
	derived from the ephemeral secret.		derived from the ephemeral secret.
	[] Indicates messages protected using keys		[] Indicates messages protected using keys
	derived from the master secret.		derived from the master secret.
	Figure 1: Message flow for full TLS Handshake		Figure 3: Message flow for full TLS Handshake
	Note: Although these diagrams indicate a message called		Note: Although these diagrams indicate a message called
	"Certificate", this message MAY either contain a bare public key or		"Certificate", this message MAY either contain a bare public key or
	an X.509 certificate (this is intended to support the out-of-band use		an X.509 certificate (this is intended to support the out-of-band use
	case indicated above). Implementations MUST support bare public keys		case indicated above). Implementations MUST support bare public keys
	and MAY support X.509 certificates.		and MAY support X.509 certificates.
	3.1.2. Basic 1-RTT Handshake		4.1.2. Basic 1-RTT Handshake
	3.1.2.1. Client's First Flight		4.1.2.1. Client's First Flight
	3.1.2.1.1. Sending		4.1.2.1.1. Sending
	In order to initiate the TLS handshake, the client sends a		In order to initiate the TLS handshake, the client sends a
	"ClientHello" message [S. 6.3.1.1].		"ClientHello" message [S. 6.3.1.1].
	struct {		struct {
	ProtocolVersion client_version = { 3, 4 }; /* TLS v1.3 */		ProtocolVersion client_version = { 3, 4 }; /* TLS v1.3 */
	Random random;		Random random;
	uint8 session_id_len_RESERVED; /* Must be zero */		uint8 session_id_len_RESERVED; /* Must be zero */
	CipherSuite cipher_suites<2..2^16-2>;		CipherSuite cipher_suites<2..2^16-2>;
	uint8 compression_methods_len_RESERVED; /* Must be zero */		uint8 compression_methods_len_RESERVED; /* Must be zero */
	skipping to change at page 6, line 35		skipping to change at page 7, line 45
	ClientKeyShare [S. 6.3.2.3]		ClientKeyShare [S. 6.3.2.3]
	Zero or more ECDHE shares drawn from the groups in NamedGroup.		Zero or more ECDHE shares drawn from the groups in NamedGroup.
	This SHOULD contain either a P-256 key or an X25519 key.		This SHOULD contain either a P-256 key or an X25519 key.
	The client MUST also include a ServerCertTypeExtension containing		The client MUST also include a ServerCertTypeExtension containing
	type "Raw Public Key" [RFC7250], indicating its willingness to accept		type "Raw Public Key" [RFC7250], indicating its willingness to accept
	a raw public key rather than an X.509 certificate in the server's		a raw public key rather than an X.509 certificate in the server's
	Certificate message.		Certificate message.
	3.1.2.1.2. Receiving		The client MUST include a TCPENOTranscript extension containing the
			TCP-ENO options that were used to negotiate ENO.
			4.1.2.2. The TCPENOTranscript
			TCPENOTranscript TLS Extension is used to carry the TCP ENO
			negotiation transcript. The body of the extension simply includes
			the TCP-ENO negotiation transcript as defined in TCP-ENO Section 3.4.
			This serves two purposes:
			o It binds the TCP-ENO negotiation into the TLS handshake.
			o In 0-RTT mode (see Section 4.1.4) it allows the server to provide
			an anti-replay nonce which is then mixed into the TLS handshake.
			The server MUST validate that the TCPENOTranscript extension matches
			the transcript. If not, it MUST fail the handshake with a fatal
			"handshake_failure" exception.
			4.1.2.2.1. Receiving
	Upon receiving the client's ClientHello, the server selects a		Upon receiving the client's ClientHello, the server selects a
	ciphersuite and ECDHE group out of the lists provided by the client		ciphersuite and ECDHE group out of the lists provided by the client
	in the cipher_suites list and the NamedGroup extension. If the		in the cipher_suites list and the NamedGroup extension. If the
	client supplied an appropriate ClientKeyShare for that group, then		client supplied an appropriate ClientKeyShare for that group, then
	the server responds with a ServerHello (see {{server-first-flight).		the server responds with a ServerHello (see Section 4.1.2.3).
	Otherwise, it replies with a HelloRetryRequest (Section 3.1.3),		Otherwise, it replies with a HelloRetryRequest (Section 4.1.3),
	indicating that the client needs to re-send the ClientHello with an		indicating that the client needs to re-send the ClientHello with an
	appropriate key share; because all TCPINC implementations are		appropriate key share; because all TCPINC implementations are
	required to support P-256, this should not happen unless P-256 is		required to support P-256, this should not happen unless P-256 is
	deprecated by a subsequent specification.		deprecated by a subsequent specification.
	3.1.2.2. Server's First Flight		4.1.2.3. Server's First Flight
	3.1.2.2.1. Sending		4.1.2.3.1. Sending
	The server respond's to the client's first flight with a sequence of		The server responds to the client's first flight with a sequence of
	messages:		messages:
	ServerHello [6.3.1.2]		ServerHello [6.3.1.2]
	Contains a nonce and the cipher suite that the server has selected		Contains a nonce and the cipher suite that the server has selected
	out of the client's list. The server MUST support the extensions		out of the client's list. The server MUST support the extensions
	listed in Section 3.1.2.1.1 and MUST also ignore any extensions it		listed in Section 4.1.2.1.1 and MUST also ignore any extensions it
	does not recognize; this implies that the server can implement		does not recognize; this implies that the server can implement
	solely the extensions listed in Section 3.1.2.1.1.		solely the extensions listed in Section 4.1.2.1.1.
	ServerKeyShare [6.3.3]		ServerKeyShare [6.3.3]
	Contains the server's ECDHE share for one of the groups offered in		Contains the server's ECDHE share for one of the groups offered in
	the client's ClientKeyShare message. All messages after		the client's ClientKeyShare message. All messages after
	ServerKeyShare are encrypted using keys derived from the		ServerKeyShare are encrypted using keys derived from the
	ClientKeyShare and ServerKeyShare.		ClientKeyShare and ServerKeyShare.
	EncryptedExtensions [6.3.4]		EncryptedExtensions [6.3.4]
	Responses to the extensions offered by the client. In this case,		Responses to the extensions offered by the client. In this case,
	the only relevant extension is the ServerCertTypeExtension.		the only relevant extension is the ServerCertTypeExtension.
	skipping to change at page 7, line 40		skipping to change at page 9, line 16
	The server's certificate. If the client offered a "Raw Public		The server's certificate. If the client offered a "Raw Public
	Key" type in ServerCertTypeExtension this message SHALL contain a		Key" type in ServerCertTypeExtension this message SHALL contain a
	SubjectPublicKeyInfo value for the server's key as specified in		SubjectPublicKeyInfo value for the server's key as specified in
	[RFC7250]. Otherwise, it SHALL contain one or more X.509		[RFC7250]. Otherwise, it SHALL contain one or more X.509
	Certificates, as specified in [I-D.ietf-tls-tls13], Section 6.3.5.		Certificates, as specified in [I-D.ietf-tls-tls13], Section 6.3.5.
	In either case, this message MUST contain a key which is		In either case, this message MUST contain a key which is
	consistent with the client's SignatureAlgorithms and NamedGroup		consistent with the client's SignatureAlgorithms and NamedGroup
	extensions.		extensions.
	ServerConfiguration [6.3.7]		ServerConfiguration [6.3.7]
	A server configuration value for use in 0-RTT (see Section 3.1.4).		A server configuration value for use in 0-RTT (see Section 4.1.4).
	CertificateVerify [6.3.8]		CertificateVerify [6.3.8]
	A signature over the handshake transcript using the key provided		A signature over the handshake transcript using the key provided
	in the certificate message.		in the certificate message.
	Finished [6.3.9]		Finished [6.3.9]
	A MAC over the entire handshake transcript up to this point.		A MAC over the entire handshake transcript up to this point.
	Once the server has sent the Finished message, it can immediately		Once the server has sent the Finished message, it can immediately
	generate the application traffic keys and start sending application		generate the application traffic keys and start sending application
	traffic to the client.		traffic to the client.
	3.1.2.3. Receiving		4.1.2.4. Receiving
	Upon receiving the server's first flight, the client proceeds as		Upon receiving the server's first flight, the client proceeds as
	follows:		follows:
	o Read the ServerHello message to determine the cryptographic		o Read the ServerHello message to determine the cryptographic
	parameters.		parameters.
	o Read the ServerKeyShare message and use that in combination with		o Read the ServerKeyShare message and use that in combination with
	the ClientKeyShare to compute the keys which are used to encrypt		the ClientKeyShare to compute the keys which are used to encrypt
	the rest of the handshake.		the rest of the handshake.
	skipping to change at page 8, line 35		skipping to change at page 10, line 11
	o Read the server's CertificateVerify message and verify the		o Read the server's CertificateVerify message and verify the
	server's signature over the handshake transcript. If the		server's signature over the handshake transcript. If the
	signature does not verify, the client terminates the handshake		signature does not verify, the client terminates the handshake
	with an alert (Section 6.1.2).		with an alert (Section 6.1.2).
	o Read the server's Finished message and verify the finished MAC		o Read the server's Finished message and verify the finished MAC
	based on the DH shared secret. If the MAC does not verify, the		based on the DH shared secret. If the MAC does not verify, the
	client terminates the handshake with an alert.		client terminates the handshake with an alert.
	3.1.2.4. Client's Second Flight		4.1.2.5. Client's Second Flight
	Finally, the client sends a Finished message which contains a MAC		Finally, the client sends a Finished message which contains a MAC
	over the handshake transcript (except for the server's Finished).		over the handshake transcript (except for the server's Finished).
	[[TODO: In the upcoming draft of TLS 1.3, the client's Finished will		[[TODO: In the upcoming draft of TLS 1.3, the client's Finished will
	likely include the server's Finished.]] Once the client has		likely include the server's Finished.]] Once the client has
	transmitted the Finished, it can begin sending encrypted traffic to		transmitted the Finished, it can begin sending encrypted traffic to
	the server.		the server.
	The server reads the client's Finished message and verifies the MAC.		The server reads the client's Finished message and verifies the MAC.
	If the MAC does not verify, the client terminates the handshake with		If the MAC does not verify, the client terminates the handshake with
	an alert.		an alert.
	3.1.3. Hello Retry Request [6.3.1.3]		4.1.3. Hello Retry Request [6.3.1.3]
	Because there are a small number of recommended groups, the		Because there are a small number of recommended groups, the
	ClientKeyShare will generally contain a key share for a group that		ClientKeyShare will generally contain a key share for a group that
	the server supports. However, it is possible that the client will		the server supports. However, it is possible that the client will
	not send such a key share, but there may be another group that the		not send such a key share, but there may be another group that the
	client and server jointly support. In that case, the server MUST		client and server jointly support. In that case, the server MUST
	send a HelloRetryRequest indicating the desired group:		send a HelloRetryRequest indicating the desired group:
	struct {		struct {
	ProtocolVersion server_version;		ProtocolVersion server_version;
	CipherSuite cipher_suite;		CipherSuite cipher_suite;
	NamedGroup selected_group;		NamedGroup selected_group;
	Extension extensions<0..2^16-1>;		Extension extensions<0..2^16-1>;
	} HelloRetryRequest;		} HelloRetryRequest;
	In response to the HelloRetryRequest the client re-sends its		In response to the HelloRetryRequest the client re-sends its
	ClientHello but with the addition of the group indicated in		ClientHello but with the addition of the group indicated in
	"selected_group".		"selected_group".
	3.1.4. Zero-RTT Exchange		4.1.4. Zero-RTT Exchange
	TLS 1.3 allows the server to send its first application data message		TLS 1.3 allows the server to send its first application data message
	to the client immediately upon receiving the client's first handshake		to the client immediately upon receiving the client's first handshake
	message (which the client can send upon receiving the server's SYN/		message (which the client can send upon receiving the server's SYN/
	ACK). However, in the basic handshake, the client is required to		ACK). However, in the basic handshake, the client is required to
	wait for the server's first flight before it can send to the server.		wait for the server's first flight before it can send to the server.
	TLS 1.3 also includes a "Zero-RTT" feature which allows the client to		TLS 1.3 also includes a "Zero-RTT" feature which allows the client to
	send data on its first flight to the server.		send data on its first flight to the server.
	In order to enable this feature, in an initial handshake the server		In order to enable this feature, in an initial handshake the server
	sends a ServerConfiguration message which contains the server's semi-		sends a ServerConfiguration message which contains the server's semi-
	static (EC)DH key which can be used for a future handshake:		static (EC)DH key which can be used for a future handshake:
	struct {		struct {
	opaque configuration_id<1..2^16-1>;		opaque configuration_id<1..2^16-1>;
	uint32 expiration_date;		uint32 expiration_date;
	skipping to change at page 9, line 45		skipping to change at page 11, line 24
	uint32 expiration_date;		uint32 expiration_date;
	NamedGroup group;		NamedGroup group;
	opaque server_key<1..2^16-1>;		opaque server_key<1..2^16-1>;
	EarlyDataType early_data_type;		EarlyDataType early_data_type;
	ConfigurationExtension extensions<0..2^16-1>;		ConfigurationExtension extensions<0..2^16-1>;
	} ServerConfiguration;		} ServerConfiguration;
	The group and server_key fields contain the server's (EC)DH key and		The group and server_key fields contain the server's (EC)DH key and
	the early_data_type field is used to indicate what data can be sent		the early_data_type field is used to indicate what data can be sent
	in zero-RTT. Because client authentication is forbidden in TCPINC-		in zero-RTT. Because client authentication is forbidden in TCPINC-
	uses of TLS 1.3 (see Section 3.3), the only valid value here is		uses of TLS 1.3 (see Section 4.3), the only valid value here is
	"early_data", indicating that the client can send data in 0-RTT.		"early_data", indicating that the client can send data in 0-RTT.
	When a ServerConfiguration is available, the client can send an		In a future connection, a client MAY send 0-RTT data only if the
	EarlyDataIndication extension in its ClientHello and then start		following three conditions obtain:
	sending data immediately, as shown below.
			o It has been specifically configured to do so (see Section 6).
			o A ServerConfiguration is available.
			o The server supplied a nonce in its SYN/ACK suboption [[TODO: Work
			out how to make this work with TFO if at all.]]
			In this case, the client sends an EarlyDataIndication extension in
			its ClientHello and can start sending data immediately, as shown
			below.
	Client Server		Client Server
	ClientHello		ClientHello
	+ ClientKeyShare		+ ClientKeyShare
	+ EarlyDataIndication		+ EarlyDataIndication
			+ TCPENOTranscript
	(EncryptedExtensions)		(EncryptedExtensions)
	(Application Data) -------->		(Application Data) -------->
	ServerHello		ServerHello
	+ EarlyDataIndication		+ EarlyDataIndication
	ServerKeyShare		ServerKeyShare
	{EncryptedExtensions}		{EncryptedExtensions}
	{ServerConfiguration*}		{ServerConfiguration*}
	{Certificate}		{Certificate}
	{CertificateVerify}		{CertificateVerify}
	<-------- {Finished}		<-------- {Finished}
			<-------- [Application Data]
	{Finished} -------->		{Finished} -------->
	[Application Data] <-------> [Application Data]		[Application Data] <-------> [Application Data]
	() Indicates messages protected using keys		() Indicates messages protected using keys
	derived from the static secret.		derived from the static secret.
	Figure 2: Message flow for a zero round trip handshake		Figure 4: Message flow for a zero round trip handshake
	IMPORTANT NOTE: TLS 1.3 Zero-RTT data is inherently replayable (see		IMPORTANT NOTE: TLS 1.3 Zero-RTT does not provide PFS and therefore
	the note in [I-D.ietf-tls-tls13] Section 6.2.2). If only passive		MUST only be used when explicitly configured.
	threat models are relevant, this issue becomes less important.
	However, if applications are performing an external channel binding
	using the session id to prevent active attack, then care must be
	taken to prevent this form of attack. See Section 6.2.2 of
	[I-D.ietf-tls-tls13] for more information on this topic. [[OPEN
	ISSUE: can we use data from the TCP SYN as anti-replay stuff.]]
	3.1.5. Key Schedule		Note: TLS 1.3 Zero-RTT data is inherently replayable (see the note in
			[I-D.ietf-tls-tls13] Section 6.2.2). However, because the client and
			server have already exchanged data in the _TCP_ handshake, this data
			can be used to provide anti-replay for a 0-RTT mode TLS handshake via
			the TCPENOTranscript extension.
			4.1.5. Key Schedule
	TLS 1.3 derives its traffic keys from two input keying material		TLS 1.3 derives its traffic keys from two input keying material
	values:		values:
	Ephemeral Secret (ES): A secret which is derived from ClientKeyShare		Ephemeral Secret (ES): A secret which is derived from ClientKeyShare
	and ServerKeyShare.		and ServerKeyShare.
	Static Secret (SS): A secret which which is derived from		Static Secret (SS): A secret which which is derived from
	ClientKeyShare and either ServerKeyShare (in the 1-RTT case) or the		ClientKeyShare and either ServerKeyShare (in the 1-RTT case) or the
	public key in the ServerConfiguration (in the 0-RTT case).		public key in the ServerConfiguration (in the 0-RTT case).
	The handshake is encrypted under keys derived from ES. The ordinary		The handshake is encrypted under keys derived from ES. The ordinary
	traffic keys are derived from the combination of ES and SS. The		traffic keys are derived from the combination of ES and SS. The
	0-RTT traffic keys are derived solely from ES and therefore have		0-RTT traffic keys are derived solely from ES and therefore have
	limited forward security. All key derivation is done using HKDF		limited forward security. All key derivation is done using the HKDF
	[RFC5869].		key-derivation algorithm [RFC5869].
	3.1.6. Record Protection		4.1.6. Record Protection
	Once the TLS handshake has completed, all data is protected as a		Once the TLS handshake has completed, all data is protected as a
	series of TLS Records.		series of TLS Records.
	struct {		struct {
	ContentType opaque_type = application_data(23); /* see fragment.type */		ContentType opaque_type = application_data(23); /* see fragment.type */
	ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */		ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */
	uint16 length;		uint16 length;
	aead-ciphered struct {		aead-ciphered struct {
	opaque content[TLSPlaintext.length];		opaque content[TLSPlaintext.length];
	ContentType type;		ContentType type;
	uint8 zeros[length_of_padding];		uint8 zeros[length_of_padding];
	} fragment;		} fragment;
	} TLSCiphertext;		} TLSCiphertext;
	Each record is encrypted with an AEAD cipher with the following		Each record is encrypted with an Authenticated Encryption with
	parameters:		Additional Data (AEAD) cipher with the following parameters:
	o The AEAD nonce is constructed by generating a per-connection nonce		o The AEAD nonce is constructed by generating a per-connection nonce
	mask of length max(8 bytes, N_MIN) for the AEAD algorithm (see		mask of length max(8 bytes, N_MIN) for the AEAD algorithm (N_MIN
	[RFC5116] Section 4) and XORing it with the record sequence number		is the minimum nonce size defined in [RFC5116] Section 4) and
	(left-padded with zeroed).		XORing it with the sequence number of the TLS record (left-padded
			with zeroes).
	o The additional data is the sequence number + the TLS version		o The additional data is the sequence number + the TLS version
	number.		number.
	The record data MAY BE padded with zeros to the right. Because the		The record data MAY BE padded with zeros to the right. Because the
	content type value is always non-zero, the padding is removed by		content type byte value is always non-zero, the padding is removed by
	removing bytes from the right until a non-zero byte is encountered.		removing bytes from the right until a non-zero byte is encountered.
	3.2. TLS 1.2 Profile		4.2. TLS 1.2 Profile
	Implementations MUST implement and require the TLS Extended Master		Implementations MUST implement and require the TLS Extended Master
	Secret Extension [I-D.ietf-tls-session-hash] and MUST NOT negotiate		Secret Extension [I-D.ietf-tls-session-hash] and MUST NOT negotiate
	versions of TLS prior to TLS 1.2. Implementations MUST NOT negotiate		versions of TLS prior to TLS 1.2. Implementations MUST NOT negotiate
	non-AEAD cipher suites and MUST use only PFS cipher suites with a key		non-AEAD cipher suites and MUST use only PFS cipher suites with a key
	of at least 2048 bits (finite field) or 256 bites (elliptic curve).		of at least 2048 bits (finite field) or 256 bites (elliptic curve).
	TLS 1.2 implementations MUST NOT initiate renegotiation and MUST		TLS 1.2 implementations MUST NOT initiate renegotiation and MUST
	respond to renegotiation with a fatal "no_renegotiation" alert.		respond to renegotiation with a fatal "no_renegotiation" alert.
	3.3. Deprecated Features		4.3. Deprecated Features
	When TLS is used with TCPINC, a number of TLS features MUST NOT be		When TLS is used with TCPINC, a number of TLS features MUST NOT be
	used, including:		used, including:
	o TLS certificate-based client authentication		o TLS certificate-based client authentication
	o Session resumption [????]		o Session resumption
	3.4. Session ID
	TCP-ENO Section 4.1 defines a session ID feature (not to be confused		These features have only minimal advantage in this context and
	with TLS Session IDs). When the protocol in use is TLS, the session		interfere with offering a reduced profile.
	ID is computed via a TLS Exporter [RFC5705] using the Exporter Label
	[[TBD]] and with the "context" input being the TCP-ENO negotiation
	transcript defined in [I-D.bittau-tcpinc-tcpeno] Section 3.4.
	3.5. Cryptographic Algorithms		4.4. Cryptographic Algorithms
	Implementations of this specification MUST implement the following		Implementations of this specification MUST implement the following
	cipher suite:		cipher suite:
	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256		TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
	These cipher suites MUST support both digital signatures and key		These cipher suites MUST support both digital signatures and key
	exchange with secp256r1 (NIST P-256) and SHOULD support key agrement		exchange with secp256r1 (NIST P-256) and SHOULD support key agrement
	with X25519 [I-D.irtf-cfrg-curves].		with X25519 [I-D.irtf-cfrg-curves].
	Implementations of this specification SHOULD implement the following		Implementations of this specification SHOULD implement the following
	cipher suites:		cipher suites:
	TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305		TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
	TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384		TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
	4. Suboption Definition
	This document uses a one byte TCP-ENO suboption. See Section 8.
	5. Transport Integrity		5. Transport Integrity
	The basic operational mode defined by TCP-TLS protects only the		The basic operational mode defined by TCP-TLS protects only the
	application layer content, but not the TCP segment metadata. Upon		application layer content, but not the TCP segment metadata. Upon
	receiving a packet, implementations MUST first check the TCP checksum		receiving a packet, implementations MUST first check the TCP checksum
	and discard corrupt packets without presenting them to TLS. If the		and discard corrupt packets without presenting them to TLS. If the
	TCP checksum passes but TLS integrity fails, the connection MUST be		TCP checksum passes but TLS integrity fails, the connection MUST be
	torn down.		torn down.
	Thus, TCP-TLS provides automatic security for the content, but not		Thus, TCP-TLS provides automatic security for the content, but not
	protection against DoS-style attacks. For instance, attackers will		protection against DoS-style attacks. For instance, attackers will
	be able to inject RST packets, bogus application segments, etc.,		be able to inject RST packets, bogus application segments, etc.,
	regardless of whether TLS authentication is used. Because the		regardless of whether TLS authentication is used. Because the
	application data is TLS protected, this will not result in the		application data is TLS protected, this will not result in the
	application receiving bogus data, but it will constitute a DoS on the		application receiving bogus data, but it will constitute a DoS on the
	connection.		connection.
	This attack could be countered by using TCP-TLS in combination with		This attack could be countered by using TCP-TLS in combination with
	TCP-AO [RFC5925], using ALPN to negotiate the use of AO. [[OPEN		TCP-AO [RFC5925], using Application-Layer Protocol Negotiation (ALPN)
	ISSUE: Is this something we want? Maybe in a separate		[RFC7301] to negotiate the use of AO. [[OPEN ISSUE: Is this
	specification.]]		something we want? Maybe in a separate specification.]]
	6. Implementation Options		6. API Considerations
			Needed here:
			o How to configure 0-RTT and send 0-RTT data (some sort of sockopt).
			o When is the session-id available (post-connect() completion).
			o How to indicate that the certificate should be validated.
			7. Implementation Considerations
	There are two primary implementation options for TCP-TLS:		There are two primary implementation options for TCP-TLS:
	o Implement all of TCP-TLS in the operating system kernel.		o Implement all of TCP-TLS in the operating system kernel.
	o Implement just the TCP-TLS negotiation option in the operating		o Implement just the TCP-TLS negotiation option in the operating
	system kernel with an interface to tell the application that TCP-		system kernel with an interface to tell the application that TCP-
	TLS has been negotiated and therefore that the application must		TLS has been negotiated and therefore that the application must
	negotiate TLS.		negotiate TLS.
	The former option obviously achieves easier deployment for		The former option obviously achieves easier deployment for
	applications, which don't have to do anything, but is more effort for		applications, which don't have to do anything, but is more effort for
	kernel developers and requires a wider interface to the kernel to		kernel developers and requires a wider interface to the kernel to
	configure the TLS stack. The latter option is inherently more		configure the TLS stack. The latter option is inherently more
	flexible but does not provide as immediate transparent deployment.		flexible but does not provide as immediate transparent deployment.
	It is also possible for systems to offer both options.		It is also possible for systems to offer both options.
	7. NAT/Firewall considerations		8. NAT/Firewall considerations
	If use of TLS is negotiated, the data sent over TCP simply is TLS		If use of TLS is negotiated, the data sent over TCP simply is TLS
	data in compliance with {{RFC5246}. Thus it is extremely likely to		data in compliance with [RFC5246]. Thus it is extremely likely to
	pass through NATs, firewalls, etc. The only kind of middlebox that		pass through NATs, firewalls, etc. The only kind of middlebox that
	is likely to cause a problem is one which does protocol enforcement		is likely to cause a problem is one which does protocol enforcement
	that blocks TLS on arbitrary (non-443) ports but _also_ passes		that blocks TLS on arbitrary (non-443) ports but _also_ passes
	unknown TCP options. Although no doubt such devices do exist,		unknown TCP options. Although no doubt such devices do exist,
	because this is a common scenario, a client machine should be able to		because this is a common scenario, a client machine should be able to
	probe to determine if it is behind such a device relatively readily.		probe to determine if it is behind such a device relatively readily.
	8. IANA Considerations		9. IANA Considerations
	IANA [shall register/has registered] the TCP-ENO suboption XX for		IANA [shall register/has registered] the TCP-ENO suboption XX for
	TCP-TLS.		TCP-TLS.
	IANA [shall register/has registered] the ALPN code point "tcpao" to		IANA [shall register/has registered] the ALPN code point "tcpao" to
	indicate the use of TCP-TLS with TCP-AO.		indicate the use of TCP-TLS with TCP-AO.
	9. Security Considerations		10. Security Considerations
	The mechanisms in this document are inherently vulnerable to active		The mechanisms in this document are inherently vulnerable to active
	attack because an attacker can remove the TCP-TLS option, thus		attack because an attacker can remove the TCP-TLS option, thus
	downgrading you to ordinary TCP. Even when TCP-AO is used, all that		downgrading you to ordinary TCP. Even when TCP-AO is used, all that
	is being provided is continuity of authentication from the initial		is being provided is continuity of authentication from the initial
	handshake. If some sort of external authentication mechanism was		handshake. If some sort of external authentication mechanism was
	provided or certificates are used, then you might get some protection		provided or certificates are used, then you might get some protection
	against active attack.		against active attack.
	Once the TCP-TLS option has been negotiated, then the connection is		Once the TCP-TLS option has been negotiated, then the connection is
	skipping to change at page 14, line 32		skipping to change at page 16, line 32
	while data integrity is provided, the connection is not resistant to		while data integrity is provided, the connection is not resistant to
	DoS attacks intended to terminate it.		DoS attacks intended to terminate it.
	If TCP-AO is used, then any bogus packets injected by an attacker		If TCP-AO is used, then any bogus packets injected by an attacker
	will be rejected by the TCP-AO integrity check and therefore will		will be rejected by the TCP-AO integrity check and therefore will
	never reach the TLS layer. Thus, in this case, the connection is		never reach the TLS layer. Thus, in this case, the connection is
	also resistant to DoS attacks, provided that endpoints require		also resistant to DoS attacks, provided that endpoints require
	integrity protection for RST packets. If endpoints accept		integrity protection for RST packets. If endpoints accept
	unauthenticated RST, then no DoS protection is provided.		unauthenticated RST, then no DoS protection is provided.
	10. References		11. References
	10.1. Normative References		11.1. Normative References
	[I-D.bittau-tcpinc-tcpeno]		[I-D.bittau-tcpinc-tcpeno]
	Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres,		Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres,
	D., and E. Smith, "TCP-ENO: Encryption Negotiation		D., and E. Smith, "TCP-ENO: Encryption Negotiation
	Option", draft-bittau-tcpinc-tcpeno-02 (work in progress),		Option", draft-bittau-tcpinc-tcpeno-02 (work in progress),
	September 2015.		September 2015.
	[I-D.ietf-tls-applayerprotoneg]		[I-D.ietf-tls-applayerprotoneg]
	Friedl, S., Popov, A., Langley, A., and S. Emile,		Friedl, S., Popov, A., Langley, A., and S. Emile,
	"Transport Layer Security (TLS) Application Layer Protocol		"Transport Layer Security (TLS) Application Layer Protocol
	skipping to change at page 16, line 5		skipping to change at page 18, line 5
	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP		[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, DOI 10.17487/RFC5925,		Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
	June 2010, <http://www.rfc-editor.org/info/rfc5925>.		June 2010, <http://www.rfc-editor.org/info/rfc5925>.
	[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,		[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
	Weiler, S., and T. Kivinen, "Using Raw Public Keys in		Weiler, S., and T. Kivinen, "Using Raw Public Keys in
	Transport Layer Security (TLS) and Datagram Transport		Transport Layer Security (TLS) and Datagram Transport
	Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,		Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
	June 2014, <http://www.rfc-editor.org/info/rfc7250>.		June 2014, <http://www.rfc-editor.org/info/rfc7250>.
	10.2. Informative References		11.2. Informative References
	[I-D.bittau-tcp-crypt]		[I-D.bittau-tcp-crypt]
	Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres,		Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres,
	D., and Q. Slack, "Cryptographic protection of TCP Streams		D., and Q. Slack, "Cryptographic protection of TCP Streams
	(tcpcrypt)", draft-bittau-tcp-crypt-04 (work in progress),		(tcpcrypt)", draft-bittau-tcp-crypt-04 (work in progress),
	February 2014.		February 2014.
	[I-D.ietf-tls-falsestart]		[I-D.ietf-tls-falsestart]
	Langley, A., Modadugu, N., and B. Moeller, "Transport		Langley, A., Modadugu, N., and B. Moeller, "Transport
	Layer Security (TLS) False Start", draft-ietf-tls-		Layer Security (TLS) False Start", draft-ietf-tls-
	skipping to change at page 16, line 27		skipping to change at page 18, line 27
	[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings		[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
	for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,		for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
	<http://www.rfc-editor.org/info/rfc5929>.		<http://www.rfc-editor.org/info/rfc5929>.
	[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words		[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
	for Use in RFCs to Indicate Requirement Levels", RFC 6919,		for Use in RFCs to Indicate Requirement Levels", RFC 6919,
	DOI 10.17487/RFC6919, April 2013,		DOI 10.17487/RFC6919, April 2013,
	<http://www.rfc-editor.org/info/rfc6919>.		<http://www.rfc-editor.org/info/rfc6919>.
			[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
			"Transport Layer Security (TLS) Application-Layer Protocol
			Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
			July 2014, <http://www.rfc-editor.org/info/rfc7301>.
	Author's Address		Author's Address
	Eric Rescorla		Eric Rescorla
	Mozilla		Mozilla
	EMail: ekr@rtfm.com		EMail: ekr@rtfm.com
End of changes. 64 change blocks.
	131 lines changed or deleted		215 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/