Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)

Daniel B Giffin <> Fri, 17 November 2017 03:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AF48127522; Thu, 16 Nov 2017 19:17:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8A-xNalLY1be; Thu, 16 Nov 2017 19:17:37 -0800 (PST)
Received: from ( [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A7E6124D68; Thu, 16 Nov 2017 19:17:37 -0800 (PST)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id vAH3Ha8r089777; Thu, 16 Nov 2017 19:17:36 -0800 (PST)
Received: (from dbg@localhost) by (8.15.2/8.15.2/Submit) id vAH3Ha2V062981; Thu, 16 Nov 2017 19:17:36 -0800 (PST)
Date: Thu, 16 Nov 2017 19:17:36 -0800
From: Daniel B Giffin <>
To: Adam Roach <>
Cc: The IESG <>,, Kyle Rose <>,,
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)
X-Mailman-Version: 2.1.22
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: Fri, 17 Nov 2017 03:17:38 -0000

Thanks for the review, Adam ...

Adam Roach wrote:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thanks for a well-written document. I have some suggestions for improvement
> (two minor, and one significant).
> This document has several references to tables that are quite distant from the
> table being referenced. It might be useful to readers if these were phrased
> something like "Table 4 in section 7," so they know where to go looking for the
> table.

Good idea.  I've gone and added the section to all table

> Section 3.5 says:
>    If an active opener receives a resumption suboption for a particular
>    TEP and the received identifier-half does not match the "resume[i]"
>    value whose other half it previously sent in a resumption suboption
>    for the same TEP, it MUST ignore that suboption.  In the typical case
>    that this was the only ENO suboption received, this means the host
>    MUST disable TCP-ENO and tcpcrypt: that is, it MUST NOT send any more
>    ENO options and MUST NOT encrypt the connection.
> I think the text here would benefit from pointing out that the client MUST NOT
> attempt to resume a session with this host for the next TCP connection attempt.

Is your concern that these two peers can get "stuck" in a
state where they repeatedly fail a mutual attempt at
resumption, thus forever falling back to no encryption?

In the case of a hash-collision of resumption identifiers,
it seems we don't get stuck because the active opener will
advance to the next session secret on the next connection:

	When proposing resumption, the active opener MUST use the lowest value
	of `i` that has not already been used (successfully or not) to
	negotiate resumption with the same host and for the same pre-session
	key `ss[0]`.

Maybe you're seeing a different problem?

> ____
> Section 3.6 stipulates:

(I've responded to this concern in a separate thread.)