Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

David Mazieres <> Tue, 25 August 2015 14:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 36C401AD35F for <>; Tue, 25 Aug 2015 07:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.91
X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v6QxfRnY5sdc for <>; Tue, 25 Aug 2015 07:27:29 -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 0C30B1B2FA5 for <>; Tue, 25 Aug 2015 07:27:24 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id t7PERIdA011151; Tue, 25 Aug 2015 07:27:18 -0700 (PDT)
Received: (from dm@localhost) by (8.14.7/8.14.7/Submit) id t7PERHhT028471; Tue, 25 Aug 2015 07:27:17 -0700 (PDT)
X-Authentication-Warning: dm set sender to using -f
From: David Mazieres <>
To: Stephen Farrell <>, Stephen Kent <>,
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 25 Aug 2015 07:27:17 -0700
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: David Mazieres expires 2015-11-23 PST <>
List-Id: "Discussion list for adding encryption to TCP." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Aug 2015 14:27:32 -0000

Stephen Farrell <> writes:

>>> It is not at all clear to me that that'd be a good plan. I think
>>> the gross-hack that it may one-day open up is unlikely to be worth
>>> it, and negotiating once is bad enough so it'd seem like a bad
>>> plan to do it twice, which I think would be the inevitable outcome.
>> Sorry, I can't reconcile the first and last sentence of that paragraph.
> If a mechanism defined in the TCP-ENO document "supported" ckiphersuite
> negotiation, but was not deployable (which seems like it'd be the case
> given attempts to squeeze in 32 bytes of DH public) then you'd end up
> having to support algorithm agility in-band anyway. Hence bad-plan +
> doing it twice.

I wish I hadn't conflated things.  What's not deployable today is
putting a DH key exchange into SYN segments.  The downside (in terms of
ruling out timestamp, MSS, etc.) is simply not realistic.  Of course,
that's the long-term dream, so I discussed it, but realistically it
cannot happen without large options, so let's just forget I ever
mentioned it.

What is eminently deployable is using TCP-ENO to negotiate a
ciphersuite.  E.g., you can agree to use curve25519 for ECDHE by the end
of the SYN exchange, and include a DH parameter in the first data
segment of a connection, after only one round trip.

As you say, we probably only need two or three ciphersuites in play at a
time, a primary and one in case the primary starts looking weak, and
maybe third to satisfy diversity of algorithm designers.  So there's no
reason ENO can't chose between these three.

>> We are currently rewriting tcpcrypt to consume three ENO suboptions, one
>> for P-256+AES-128, one for P-512+AES-256, and one for
>> Curve25519+Chacha/Poly1305.  Compared to the existing draft, this lets
>> us ditch PKCONF and pretty much everything except the DH parameters in
>> INIT1 and INIT2 messages.  We are also ditching RSA (which at this point
>> was there "just in case," because tcpcrypt had to be future compatible
>> with things other than DH, but now ENO frees us from worrying about
>> future compatibility).  The result is a much simpler document.
> I'll just repeat that I think that's a bad plan and you'd be
> better off not making such changes.

If you can elaborate on this, we would certainly appreciate it.  We
certainly can leave a second level of negotiation in tcpcrypt--that
would even be easier for us--but it will add pages to the RFC, so it
would help to understand why.