Re: [tcpinc] Review of draft-ietf-tcpinc-api-03

David Mazieres <> Sat, 30 September 2017 04:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF0AD134487 for <>; Fri, 29 Sep 2017 21:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b5KjqMtfqESP for <>; Fri, 29 Sep 2017 21:48:12 -0700 (PDT)
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 93F4E134218 for <>; Fri, 29 Sep 2017 21:48:12 -0700 (PDT)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id v8U4mBDv009022; Fri, 29 Sep 2017 21:48:11 -0700 (PDT)
Received: (from dm@localhost) by (8.15.2/8.15.2/Submit) id v8U4mBSP096567; Fri, 29 Sep 2017 21:48:11 -0700 (PDT)
From: David Mazieres <>
To: Kyle Rose <>, tcpinc <>
In-Reply-To: <>
References: <>
Reply-To: David Mazieres expires 2017-12-28 PST <>
Date: Fri, 29 Sep 2017 21:48:11 -0700
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [tcpinc] Review of draft-ietf-tcpinc-api-03
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: Sat, 30 Sep 2017 04:48:14 -0000

Kyle Rose <> writes:

> (Keepalive before list timeout.)
> This is a review of draft-ietf-tcpinc-api-03. Chair hat off.

Okay, thanks for the review.  I stupidly somehow thought your email
ended halfway through and uploaded a draft addressing half your
comments.  That's now been fixed, but you will want to diff version 5
against version 3.  The latest is here:

Most of your points were straight-forward and should now be addressed.
I'll just comment on ones that might be marginally more complicated.

> * I don't understand the rationale behind the last bullet in the
> tcpcrypt section. Is the presumption that an application will
> authenticate the first connection and then resume without
> authentication? If so, then it's more than prudent: it MUST purge that
> session from the cache.

I just got rid of that point.  The idea was that if you somehow
connected to a man in the middle and think you can avoid it by trying
again, then you want to flush the cache.  But in practice if you have an
interception proxy or something that is implementing tcpcrypt, then
probably trying again isn't going to work.  The point is kind of arcane
anyway, so no need to try to make it.

> * What is "baddynamic"? A Google search was unrevealing. Does this
> need a reference?

So some BSD have such a sysctl.  For example:

I was just trying to be as compatible as possible with that mechanism
since it exists already.

> 5.1:
> * TCP_ENO_LOCAL_NAME conflicts with SELF_NAME.

I didn't understand this comment at the time.  Now I think you just mean
I used TCP_ENO_LOCAL_NAME which is not a thing.  I've already submitted
too many drafts tonight, but I fixed this in the git repo, so once we
settle on everything else I need to fix, the final draft can have this

> * Can you describe for me an attack that would be possible using an
> authenticator taken out of context? I'm assuming that both ends of the
> connection with the unique session ID already have the cookie, and
> that the authenticator would be useless on any other tcpinc connection
> because of the uniqueness property. Is the issue that the session ID
> used in the PRF could collide with an entirely distinct (i.e.,
> non-tcpinc) use? Something similar applies to 5.2, as well.

Yes, say you have a peer-to-peer system where nodes authenticate
themselves by signing the session ID but not the role.  Then you can
connect to a server and convince it that it is talking to itself by just
echoing back the signed message.

> * It might be worth pointing out that, in unilateral authentication,
> the side that does not validate an authenticator relies on the peer
> ending the connection if validation fails to prevent man-in-the-middle
> attacks.

I don't really understand this comment.  In unilateral authentication
one side does not care about whom it is talking to, so why would it need
to rely on the unknown other side for anything?