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

Stephen Farrell <> Wed, 26 August 2015 17:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B9B181A1B81 for <>; Wed, 26 Aug 2015 10:52:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.011
X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, 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 ZxRqr2QORq2K for <>; Wed, 26 Aug 2015 10:52:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE8941A878A for <>; Wed, 26 Aug 2015 10:52:47 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8BE5BE50; Wed, 26 Aug 2015 18:52:45 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sD7_4ggeRDJg; Wed, 26 Aug 2015 18:52:45 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id B2572BE4D; Wed, 26 Aug 2015 18:52:45 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1440611565; bh=iR+IU16nR9zT0PdmieMJOT+CIfT0e4IW631k1bljwiQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=hHyKO/ItJzTHhonx+mDLhCrIrlmwL0Hux2bQpNHakCl03BIjZ1VkbT/4VqGXnPs9E 8g3x1WXYolfOW0DDXE9jd14TY+RRxwJxIRqtyxOlAS0pbodWzQsCQf+ZGYqy7LRkTb JbKpgd+TuCYaroZA4p2N2Vqg7g3mQ/jPx0jddeZU=
Message-ID: <>
Date: Wed, 26 Aug 2015 18:52:45 +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: Mirja Kühlewind <>, David Mazieres expires 2015-11-23 PST <>,
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: Wed, 26 Aug 2015 17:52:52 -0000


On 26/08/15 16:47, Mirja Kühlewind wrote:
> Hi Stephen,
> just to double-check if I understand correctly what you are saying:

I don't think we're saying the same thing. My fault probably, but
I'll try again below:-)

> You basically say that you would not support the tcp-eno approach
> because you would like to have for any tcpinc protocol (not matter if
> tcp-use-tls or tcpcrypt) only a very simple negotiation in a TCP
> option where both ends confirm that they support tcpinc and then all
> additional negotiation is done in the payload data space (and
> therefore an own document is not needed)?
> What’s about the argument, that I believe you’ve stated earlier
> yourself, that one could use tcp-eno to update to a new protocol
> version (not only a new cipher) in case we detect flaws in the
> general protocol design…? If you think this is useful to have, would
> it then make then to have an own document for it (and potentially
> take the tcp-eno proposal as a starting point)?

Until the WG have selected between tcpcrypt and tcp-use-tls
I don't think it makes any sense for tcp-eno to delve into
ciphersuite or cryptographic algorithm details.

After the WG have selected tcpcrypt or tcp-use-tls:
- if the WG pursue only tcpcrypt it may make sense to handle
  algorithm agility in a TCP option (I'm not sure if it would
  or not but it'd be worth a look)
- if the WG select tcp-use-tls I don't think it makes sense
  to try handle any algorithm agility in a TCP option

The reason is that adding ciphersuite details into tcp-eno when
tcp-use-tls might be used could mean negotiating the same thing
twice, once in a TCP option and the 2nd time in the TLS handshake.
That seems like a bad idea that could create potential new
vulnerabilities, or at least confusion, bugs and possible lack
of interop.

If tcp-eno is only negotiating (or indicating) that tcpcrypt or
tcp-use-tls will be used, or that version-N of one of those will
be used, that could work, but I'm not so keen on it as it might
move the wg towards pursuing both tcpcrypt and tcp-use-tls in
the longer term, and I think one of the things on which the wg
did have consensus was that tcpinc would be based on only one
of those and that the wg would not continue to work on both
options beyond the next IETF meeting.

Does that help?


> Mirja
> On 25.08.2015 22:03, Stephen Farrell wrote:
>> On 25/08/15 17:54, David Mazieres wrote:
>>> TCP-ENO is an effort A) to make progress on common elements of
>>> TCP-use-TLS and tcpcrypt,
>> The above is reasonable.
>> ...
>>> Well, in order to make the choice between tcpcrypt and
>>> TCP-use-TLS the most salient, it seems worth maximizing the
>>> advantages of the two protocols.
>> I think your goal (A) and "maximising the advantages" of tcpcrypt 
>> (or of TLS) are incompatible goals at this point in time.
>> If/when the WG adopt tcpcrypt optimisations relating to algorithm 
>> agility will inevitably be explored. If/when the WG adopt TLS that 
>> kind of change wouldn't make sense.
>> In the meantime trying to squeeze discussion of loads of different 
>> things into discussion about TCP-ENO seems mostly a distraction.
>> S.
>> _______________________________________________ Tcpinc mailing
>> list