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

Stephen Farrell <> Tue, 25 August 2015 14:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AA08A1B349F for <>; Tue, 25 Aug 2015 07:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZPM7awcgCDOZ for <>; Tue, 25 Aug 2015 07:55:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3C461B34A6 for <>; Tue, 25 Aug 2015 07:55:49 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B0D3BE2F; Tue, 25 Aug 2015 15:55:48 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z_SaP-zPRIwv; Tue, 25 Aug 2015 15:55:48 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id C05E2BDCC; Tue, 25 Aug 2015 15:55:47 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1440514547; bh=moh8evKMvGnybvhpQPaur7pHbEotDKZxOhQaJ4Z/FQU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=sAWJdRlTxhWEuMxALInnmD66C7j4EgzlBo4zdinJrPOYd5q5Tc/BjvKsXKC/cDY1V 0ePfwfs4zB+LqmHD2Nju7F2EGu/o3vktJPnP6PueIUV7LrO/abs8aB/6HOsAofyO44 zVsjrXgZuSlgvlT72QqigsC+XDUYV/LYP2rgqDfc=
Message-ID: <>
Date: Tue, 25 Aug 2015 15:55:47 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: David Mazieres expires 2015-11-23 PST <>, Stephen Kent <>,
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
X-Mailman-Version: 2.1.15
Precedence: list
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:55:52 -0000


On 25/08/15 15:27, David Mazieres wrote:
> 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. 

Conflating often does that - but none of us are perfect, certainly
not me;-)

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

So yes one could. But that assumes that the WG have not chosen
to do TLS I think, doesn't it? If the WG did choose TLS then
ciphersuite selection has to happen in the TLS h/s or else we
will not get the security guarantees that TLS is supposed to
give us.

Even without the large options, whacking in ciphersuite specific
values in TCP-ENO now is a bad plan as it (for me anyway) further
muddies the already muddy waters within which we've been fishing
for consensus in this WG. (Apologies for the strained analogy and
even more for the pun in the apology:-)

*If* the WG selected tcpcrypt then it might make sense to see
if algorithm agility could be sufficiently well supported in the TCP
handshake. I'm not sure if it could or not myself. But if the WG
selects TLS or decide to pursue both (ick) then that'd not make
any sense that I can see.

So trying to figure out now if or how algorithm agility can be
handled via TCP options is IMO a bad plan that may move us further
away from rather than towards consensus.

If TCP-ENO is proposed as a meta-negotiation of the security
protocol to use that is arguably different. I still don't like it
(as I don't want us to continue processing both TLS and tcpcrypt,
though it seems like Martin T. disagrees with me on that) but at
least that meta-negotiation wouldn't repeat stuff done within TLS
or tcypcypt so isn't nearly as bad as putting ciphersuite stuff
into TCP options (now).


> 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.
> David
> _______________________________________________
> Tcpinc mailing list