Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpcrypt - draft header

From: "Black, David" <[email-masked]>
Date: Thu, 16 Feb 2017 00:37:16 +0000

The tcpcrypt draft is going to be an Experimental RFC, as indicated by our charter and the datatracker.   However, the draft header says “Intended status: Standards Track”  (oops).   This oversight is a must-fix item before we can send the draft to the IESG with an RFC publication request ...

Thanks, --David

From: Tcpinc [mailto:[email-masked]] On Behalf Of Black, David
Sent: Wednesday, February 15, 2017 7:30 PM
To: tcpinc
Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpcrypt

I focused on the changes since the -03 version, and found this sentence in Section 3.7:

   When the TCP FIN flag differs
   from "FINp", a receiving host MUST either ignore the segment
   altogether or abort the connection and raise an error condition
   distinct from the end-of-file condition.

I believe that this is ok, although I suggest adding a short explanation of why this is not a new denial-of-service exposure to the Security Considerations section.  In essence, this check blocks off-path injection of FIN, as the off-path attacker cannot generate valid tcpcrypt content, so the packet should be dropped before getting to this header flag processing, and the situation for an on-path attacker is no worse, as in tcpcrypt’s absence, the injected FIN would close the connection.

Thanks, --David

From: Tcpinc [mailto:[email-masked]] On Behalf Of Kyle Rose
Sent: Monday, January 23, 2017 6:16 PM
To: tcpinc
Subject: [tcpinc] WGLC for draft-ietf-tcpinc-tcpcrypt

This is a working group last call for the "Cryptographic protection of TCP Streams (tcpcrypt)" draft available at https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/. Please review the document and send your comments to the list by 2017-February-15.
- Kyle and David

---

From: Daniel B Giffin <[email-masked]>
Date: Wed, 15 Feb 2017 18:19:40 -0800

Sorry for the oversight on the document category!  I've
submitted a new draft labeled Experimental.

In the new draft (-05) I've also changed the denial-of-
service discussion slightly to make clear that there is no
special vulnerability of tcpcrypt above what TCP suffers:

   To gain middlebox compatibility, tcpcrypt does not protect TCP
   headers.  Hence, the protocol is vulnerable to denial-of-service from
   off-path attackers just as plain TCP is.  Possible attacks include
   desynchronizing the underlying TCP stream, injecting RST or FIN
   segments, and forging rekey bits.  These attacks will cause a
   tcpcrypt connection to hang or fail with an error, but not in any
   circumstance where plain TCP could continue uncorrupted.
   Implementations MUST give higher-level software a way to distinguish
   such errors from a clean end-of-stream (indicated by an authenticated
   "FINp" bit) so that applications can avoid semantic truncation
   attacks.

I didn't mention on-path attackers because it should be
clear that they have arbitrary DOS capability.

Thanks for the suggestion.

daniel