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

Kyle Rose <> Tue, 03 October 2017 16:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D2D8134F6C for <>; Tue, 3 Oct 2017 09:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id beesc0IDZYiV for <>; Tue, 3 Oct 2017 09:42:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE5B7134F5F for <>; Tue, 3 Oct 2017 09:42:32 -0700 (PDT)
Received: by with SMTP id n5so6578644qke.11 for <>; Tue, 03 Oct 2017 09:42:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6mu6wLnjNnSpA7dz9iNzzqnX2lRA6WxU6cJKi5hmJ2U=; b=hF4p6icQzBukucWGOyqTMje1QXO1qNmeQylcWf8H05mnFfY9aNc3SYOKC+YIhAwy4T rbY2c+mE+/hqWXKOzMSWvH2OJy0F9SgppID7PqZmDhlAye2ZXcsh6ghMfi2nRh+dJvkg xf7Uriy5qPJz0YOIDxwShvyX4ZDbvNeYlP2jA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6mu6wLnjNnSpA7dz9iNzzqnX2lRA6WxU6cJKi5hmJ2U=; b=Fk5jdBSREEkZzKN3ZEh20UL5gMNJSwqJe16WYav82JsdQB5jpvYVTHLWKVbDN40XDi mR4hvqmFWJvZ/BS6liIrJBHRJk2xfXeDLji2zIyF+KcWworVipkaUk/23lipI6WvMa50 FsnBUPRLh0GjUapAnmKFyFfo12pohh905g9OumrF9Fb4jzMCKT5KWNH7UyofqoU4D3P4 Rns3f5/ELUyc3niQcrumCIOT9sBkZIsMt45/YigwZWE4vJ3gPmaUKaMAnYbkL5l0xPfe KzF2H+Qenuon3GgqeU/86AzlWVGzTi0iQYuMtHHdRWSUTFU7Wr4d60BCTfMzYgJRyOlR gGtA==
X-Gm-Message-State: AMCzsaUa0kYVGFx3Nw/BTVYihfe6POogngXG9AhlgPbo+YUOTk1dhIrZ ogkpAMZ7+qtPdDFOgX4jY8MRam5uhdS26AUYhKC9p/1z
X-Google-Smtp-Source: AOwi7QDfSLaFS0vBW8JBQlcgNrjRxjQcZSr52l7ZEIh95UsFxJC7ZcOBV8vQYXZm355pbrDRZ8f3v0tJbl+YITtQaSs=
X-Received: by with SMTP id w3mr21194970qkd.26.1507048951679; Tue, 03 Oct 2017 09:42:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 3 Oct 2017 09:42:31 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
From: Kyle Rose <>
Date: Tue, 3 Oct 2017 12:42:31 -0400
Message-ID: <>
To: David Mazieres expires 2017-12-28 PST <>
Cc: tcpinc <>
Content-Type: text/plain; charset="UTF-8"
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: Tue, 03 Oct 2017 16:42:35 -0000

On Sat, Sep 30, 2017 at 12:48 AM, David Mazieres
<> wrote:
>> * 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.


> 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.

Sounds good. This was just an informational clarification for me
because for some reason I couldn't find anything about it.

> 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
> fix.

Yes, that's what I meant. I'm not sure why I put it precisely the way I did.

>> * 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.

Right. This also looks good.

>> * 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?

What I mean is maybe best illustrated by example. Server-only auth in
TLS provides protection against MitM attacks because the client
authenticates the output of a derivation from some secret that cannot
be engineered by an adversary to be the same on two connections:
modulo a compromise of the signing key or collusion by one of the two
endpoints, this is a proof that with overwhelming probability only the
server and the client know the symmetric key material protecting the
connection. But the server's protection in this case relies on the
client taking action: that is, authenticating the server's certificate
and hanging up if the cert check fails. If not, the MitM can pretend
to be the server to the client, and the server would never know. This
is not true with mutual authentication based on a channel binding, as
either endpoint would be able to distinguish a legit connection from a
broken one.