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

"Black, David" <> Thu, 16 February 2017 00:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EC7C120725 for <>; Wed, 15 Feb 2017 16:30:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.586
X-Spam-Status: No, score=-4.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=YObuTx6q; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.b=d2ZsPxUy
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JbE1nddFoZD7 for <>; Wed, 15 Feb 2017 16:30:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0220512953F for <>; Wed, 15 Feb 2017 16:30:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=smtpout; t=1487205009; x=1518741009; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Ru0qaAmoRRRyOpI6JJvvQBJIkQs50mshGar7FyPFteM=; b=YObuTx6qw55nlJqfFxGfWbA+4LDxw1ozUxPbHncCaVEYew32SrulrclO YVGTLP+7I22HmBX1d1SMjJZGw6lXCfy28+kNTB0Vl4vEWjVrbBLc3t2rQ OQL+qdByqOdyqPvK3niPUmhIl1LZyZsllOwrXccY8ZhFSwSbWRiGWXlZl M=;
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2017 18:30:08 -0600
From: "Black, David" <>
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 06:24:52 +0600
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v1G0U7H3002806 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <>; Wed, 15 Feb 2017 19:30:12 -0500
X-DKIM: OpenDKIM Filter v2.4.3 v1G0U7H3002806
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=jan2013; t=1487205012; bh=55L0yDyrbfEc9NAs6XpB4IuisAw=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=d2ZsPxUy2MnKLiMc01JtrDF3c/+AYV+0MebH13XtBzybPtnHFHO8biFaQwMJ6QuN6 SHBN/BFc2qwooeF8rcKg3Gp7SQvExuwtHcY/C+VmiSeMrsUk3HFV11yhxUuEIkn7i3 1cS6G8/oE879WY5PNOSDO/UcHLT+UfUvJ/2Z/UW0=
X-DKIM: OpenDKIM Filter v2.4.3 v1G0U7H3002806
Received: from ( []) by (RSA Interceptor) for <>; Wed, 15 Feb 2017 19:29:41 -0500
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v1G0TkB3006726 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for <>; Wed, 15 Feb 2017 19:29:47 -0500
Received: from ([fe80::849f:5da2:11b:4385]) by ([]) with mapi id 14.03.0266.001; Wed, 15 Feb 2017 19:29:46 -0500
To: tcpinc <>
Thread-Topic: [tcpinc] WGLC for draft-ietf-tcpinc-tcpcrypt
Thread-Index: AQHSdc6peeeSs/CYCky6tOBSgBKtGqFq6pFw
Date: Thu, 16 Feb 2017 00:29:45 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F870DD1MX307CL04corpem_"
MIME-Version: 1.0
X-RSA-Classifications: public
Archived-At: <>
Subject: Re: [tcpinc] WGLC for draft-ietf-tcpinc-tcpcrypt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Feb 2017 00:30:15 -0000

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 [] 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 Please review the document and send your comments to the list by 2017-February-15.
- Kyle and David