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

Stephen Farrell <> Tue, 25 August 2015 10:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 568E41AC3B2 for <>; Tue, 25 Aug 2015 03:59:40 -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 I99hAvuKkkdz for <>; Tue, 25 Aug 2015 03:59:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A30681A8A1A for <>; Tue, 25 Aug 2015 03:59:37 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5F45BDD0; Tue, 25 Aug 2015 11:59:35 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MveLwk_saw0N; Tue, 25 Aug 2015 11:59:35 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 579B1BDCA; Tue, 25 Aug 2015 11:59:35 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1440500375; bh=kikprvKeixAsdtrlAI9f0M6wHS//tg2o8LD0UHekgc0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=nae2vnJUdK0g6WSme09jobc5f/XnbRZsQYd+5hcyCe2bU5jMlRBleqKsS6UE4HCHd MVJzv1xCvoXZ2cM5RqPF33yMjC9Zij+6b2Uq3UoJomibZbGtu9lbGWMgT7HA3rqXS4 2Dznk/AVPyLKiqNcymOmVEDZkAScYY0gqib6Rnsk=
Message-ID: <>
Date: Tue, 25 Aug 2015 11:59:35 +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-22 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 10:59:40 -0000


On 24/08/15 23:48, David Mazieres wrote:
> Stephen Farrell <> writes:
>>> The issue relates to ciphers because TCP-ENO can be used to negotiate
>>> cipher suites.  
>> 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.

> If negotiated TCP-ENO spec implies a specific cipher suite, then you
> only negotiate once.  If TCP-ENO specs have multiple cipher suites, then
> you have two negotiations, first the ENO-level meta-negotiation on how
> to negotiate, then a second cipher suite within the particular
> encryption spec.
> Your first sentence reads like a recommendation *not* to tie a single
> cipher suite to a single TCP-ENO suboption, in which case you'd need a
> separate cipher suite negotiation mechanism.  Your second sentence
> implies you consider two rounds of negotiation a bad idea, in which case
> why wouldn't you want ENO to negotiate the cipher suite.  We value your
> opinion on this question, so please clarify!
>> But so long as tcpcrypt is not a WG document that's your call I guess.
> 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.


> But this is all easy to change until we've updated the code to match the
> forthcoming document, so high-level feedback now would be appreciated.
>> My take fwiw would be that a TCP option should really only signal
>> turning on TCPINC full stop. And that TCPINC initially ought only
>> have two ciphersuites defined, one for use now and a backup. But
>> TPCINC will have to support some form of algorithm agility so that
>> that pair of ciphersuites can be changed over time. So yes some
>> form of agility is needed but it's not clear to me that a TLS-like
>> scheme is best.
> Given that latency is critical, at a minimum we have to start the
> public-key cipher negotiation in the SYN-ACK of a three-way handshake.
> So why not have the TCP-ENO suboption just specify the ciphersuite?
>> If/when practical deployment of DH values becomes feasible then
>> it'd be time to discuss how to use that. But not now when that is
>> not, if I understand correctly, possible to do that.
> Well, it is possible today.  What's not not possible is to do that and
> enable TCP timestamp for the same connection.
> David
> _______________________________________________
> Tcpinc mailing list