draft-ietf-tcpinc-tcpcrypt-04.txt   draft-ietf-tcpinc-tcpcrypt-05.txt 
Network Working Group A. Bittau Network Working Group A. Bittau
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track D. Boneh Intended status: Experimental D. Boneh
Expires: July 23, 2017 D. Giffin Expires: August 19, 2017 D. Giffin
M. Hamburg M. Hamburg
Stanford University Stanford University
M. Handley M. Handley
University College London University College London
D. Mazieres D. Mazieres
Q. Slack Q. Slack
Stanford University Stanford University
E. Smith E. Smith
Kestrel Institute Kestrel Institute
January 19, 2017 February 15, 2017
Cryptographic protection of TCP Streams (tcpcrypt) Cryptographic protection of TCP Streams (tcpcrypt)
draft-ietf-tcpinc-tcpcrypt-04 draft-ietf-tcpinc-tcpcrypt-05
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) [I-D.ietf-tcpinc-tcpeno]. Tcpcrypt coexists with (TCP-ENO) [I-D.ietf-tcpinc-tcpeno]. Tcpcrypt coexists with
middleboxes by tolerating resegmentation, NATs, and other middleboxes by tolerating resegmentation, NATs, and other
manipulations of the TCP header. The protocol is self-contained and manipulations of the TCP header. The protocol is self-contained and
specifically tailored to TCP implementations, which often reside in specifically tailored to TCP implementations, which often reside in
kernels or other environments in which large external software kernels or other environments in which large external software
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 July 23, 2017. This Internet-Draft will expire on August 19, 2017.
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 (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
skipping to change at page 20, line 47 skipping to change at page 20, line 47
particular, tcpcrypt does not protect against active eavesdroppers particular, tcpcrypt does not protect against active eavesdroppers
unless applications authenticate the session ID. If it can be unless applications authenticate the session ID. If it can be
established that the session IDs computed at each end of the established that the session IDs computed at each end of the
connection match, then tcpcrypt guarantees that no man-in-the-middle connection match, then tcpcrypt guarantees that no man-in-the-middle
attacks occurred unless the attacker has broken the underlying attacks occurred unless the attacker has broken the underlying
cryptographic primitives (e.g., ECDH). A proof of this property for cryptographic primitives (e.g., ECDH). A proof of this property for
an earlier version of the protocol has been published [tcpcrypt]. an earlier version of the protocol has been published [tcpcrypt].
To gain middlebox compatibility, tcpcrypt does not protect TCP To gain middlebox compatibility, tcpcrypt does not protect TCP
headers. Hence, the protocol is vulnerable to denial-of-service from headers. Hence, the protocol is vulnerable to denial-of-service from
off-path attackers. Possible attacks include desynchronizing the off-path attackers just as plain TCP is. Possible attacks include
underlying TCP stream, injecting RST packets, and forging or desynchronizing the underlying TCP stream, injecting RST or FIN
suppressing rekey bits. These attacks will cause a tcpcrypt segments, and forging rekey bits. These attacks will cause a
connection to hang or fail with an error. Implementations MUST give tcpcrypt connection to hang or fail with an error, but not in any
higher-level software a way to distinguish such errors from a clean circumstance where plain TCP could continue uncorrupted.
end-of-stream (indicated by an authenticated "FINp" bit) so that Implementations MUST give higher-level software a way to distinguish
applications can avoid semantic truncation attacks. such errors from a clean end-of-stream (indicated by an authenticated
"FINp" bit) so that applications can avoid semantic truncation
attacks.
There is no "key confirmation" step in tcpcrypt. This is not There is no "key confirmation" step in tcpcrypt. This is not
required because tcpcrypt's threat model includes the possibility of required because tcpcrypt's threat model includes the possibility of
a connection to an adversary. If key negotiation is compromised and a connection to an adversary. If key negotiation is compromised and
yields two different keys, all subsequent frames will be ignored due yields two different keys, all subsequent frames will be ignored due
to failed integrity checks, causing the application's connection to to failed integrity checks, causing the application's connection to
hang. This is not a new threat because in plain TCP, an active hang. This is not a new threat because in plain TCP, an active
attacker could have modified sequence and acknowledgement numbers to attacker could have modified sequence and acknowledgement numbers to
hang the connection anyway. hang the connection anyway.
 End of changes. 5 change blocks. 
12 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/