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

Watson Ladd <> Sun, 23 August 2015 05:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E31651AC3CC for <>; Sat, 22 Aug 2015 22:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.6
X-Spam-Level: ***
X-Spam-Status: No, score=3.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_16=0.6, MANGLED_BACK=2.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DfJZRwN5AMbH for <>; Sat, 22 Aug 2015 22:35:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02A411AC3CB for <>; Sat, 22 Aug 2015 22:35:22 -0700 (PDT)
Received: by wijp15 with SMTP id p15so49501382wij.0 for <>; Sat, 22 Aug 2015 22:35:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Chb+Y9uq+w2YCrB8PnoFM+2tFuPiBtjjLXk0VRzJ8wE=; b=vf3yRNnckn29xUEuu+mWvA009HEA/zCfMaMOyfu+1jM8DbhNRghKbAoq/gCQKA+oIt uu3lFtw9lTa/gJSaTHgpE5LDIv4EUuQ5MUzDnAxticauzg0aVyLNrYOGaCFwdUYJsGUv 0L+ZbJzHmChjmge4qqgfftq4nF6p/Xn/hXiI5pjbK41HfdFoxJF6v78gON9KVq7b5M9d GLqyf05J1TGY3+0dsR4iPRdc3gD8cyXnQke13kzXsHWoKvvzCAMrr4cb272dW7Ry5Gl8 rOSJeeZuX+kjUHtZbx3kL6iAkR0K2mjeIOP7itMvBXwHMiTHHcdhssNvSGG0kZymeQsh UdLw==
MIME-Version: 1.0
X-Received: by with SMTP id bw17mr19337545wib.30.1440308120644; Sat, 22 Aug 2015 22:35:20 -0700 (PDT)
Received: by with HTTP; Sat, 22 Aug 2015 22:35:20 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Sat, 22 Aug 2015 22:35:20 -0700
Message-ID: <>
From: Watson Ladd <>
To: David Mazieres <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: Eric Rescorla <>, tcpinc <>
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: Sun, 23 Aug 2015 05:35:24 -0000

On Sat, Aug 22, 2015 at 10:13 PM, David Mazieres
<> wrote:
> Eric Rescorla <> writes:
>> Review of draft-bittau-tcpinc-tcpeno-01
>> I have reviewed the -01 version of the ENO draft. This seems like a good
>> general idea, but I have concerns about a number of the details.
> Thanks for going through in detail.  I will respond point-by-point.
>> S 3.0.
>> The variable/non-variable encoding seems suboptimal and in particular
>> the restriction that only one suboption can be variable length. What
>> are we going to do if two specifications wish to have variable-length
>> data in the SYN packets? The specification suggests that you should
>> address this by having two ENO options but that seems clumsy.
>> I would suggest instead that if the v bit is set the next byte be the
>> length. This comes at the cost of one byte for settings where there is
>> only one variable-length option but is more efficient when you
>> want to have multiple variable-length options, since you don't need
>> to repeat the kind byte.
> Our intent is to optimize for a future in which people only need one
> variable-length option.  For example, the SYN can list a bunch of
> options, and then the SYN-ACK can pick one of them.  The current design
> saves one byte, which may be quite important.  For instance, you can
> just barely fit a P-256 or Curve25519 DH key exchange in TCP options
> currently.  If TCPINC is wildly successful, we can imagine a future spec
> that does that and squeezes the 8 most popular SYN options into a single
> byte or something.  But if we waste even one more byte of option space,
> we start closing a lot of doors along that front.
> That said, if you can provide an explicit example of why you might want
> multiple variable-length suboptions, you could possibly convince us to
> optimize for that case.
>> S 3.1.
>> I am not convinced that a one-bit tiebreaker for simultaneous open
>> is going to work. Experience with other protocols that have the
>> problem of symmetry (e.g., ICE) is that this sort of thing results
>> from confusion about which side is really "first". In that case,
>> both sides will try to set the same "b" bit, and you will not break
>> the symmetry.
>> I believe we must either ignore simultaneous open or use a higher-
>> entropy tiebreaker.
> A high-level question is whether we should completely abandon enabling
> TCP?INC for simultaneous open.  If we allow encryption under some
> circumstances after simultaneous open, then the next question is how to
> apportion responsibility for making it work.  The high-entropy solution
> says make it work with high probability, but at the cost of a lot more
> option space.  Since simultaneous open is kind of finicky anyway,
> TCP-ENO took the approach of making applications responsible for working
> out the roles.  For example, one plausible approach is to set the 'b'
> bit to 1 at the endpoint with the lowest (public-IP-address,
> public-port-number) pair.  That's obviously not information available to
> TCP-ENO, which knows nothing of NATS, but is information available to an
> application using STUN to broker simultaneous open.  Perhaps we should
> work out an example of simultaneous open in the API document.

Let's imagine the stupidest possible protocol: each party squeezes 32
bytes into each SYN, representing a Curve25519 public key, and
we compute H(agreed key || lexographically least || lexographically
greater) . This protocol supports simultaneous open. So why can't a
more complicated protocol do the same?

> As it is, the b bit is an effort to find the knee in the cost-benefit
> curve.  I.e., is it worth 4+ bytes of option space to make
> simultaneous open work?  Hard to make that case.  But is it worth one
> *bit* not to shut the door completely?  Quite possibly.
>> S 3.2.
>> I am unclear on why the active opener needs to have an ENO segment
>> in his first ACK. Can you explain?
> There are two reasons:
> 1. Given the prevalence of asymmetric routes, it's highly likely that
>    situations will arise where ENO options are stripped in one
>    direction but not the other.  Therefore, both sides need to know
>    not only that the other endpoint supports ENO, but that the other
>    endpoint can receive ENO options.  If you remove the requirement
>    for that ACK, a scenario such as Figure 7 would result in total
>    failure of the TCP connection, not just failure to encrypt.  We
>    definitely want to avoid that.
> 2. Suboption data could involve parameters that are not universally
>    supported, in which case the active opener may which to disable
>    TCPINC based on the contents of the SYN-ACK segment.
>> This mechanism for negotiating mechanisms seems over-complex, what
>> with A and B each providing lists and then choosing B's top
>> preference.  I would suggest instead that we simply have B choose out
>> of A's list, as with ALPN. The document offers two reasons why this
>> might not work, simultaneous open and inflexible implementations: If
>> we resolve simultaneous open in the SYN exchange then this should work
>> fine and the issue of implementation seems like a corner case.
> If by resolve simultaneous open you mean not support it, I agree.  But
> if you mean something else, then things can get tricky.  I would
> welcome a detailed design that works, but just saying "do something
> like ALPN" is not enough detail to determine whether or not that
> approach is viable.  We'd need to see an "A -> B: ... B -> A: ..."-
> style example with TCP flags.

How often is simultaneous open used? Are there important applications
we won't encrypt if we kill it?

> One big challenge of simultaneous open is that each side must
> acknowledge the other side's SYN before seeing the other side's SYN-ACK.
> Moreover, other than the SYN, you can't consume TCP sequence numbers
> until you have definitively enabled or disabled TCPINC (and in the
> former case negotiated an encryption spec).  So whereas in a three-way
> hand-shake, you can do:
>    A -> B:  SYN     X
>    B -> A:  SYN-ACK X' which depends on X
>    A -> B:  ACK     X'' which depends on X and X' and might disable TCPINC
> With simultaneous open, you have two pairs of messages sent in parallel:
>    A -> B:  SYN X
>    B -> A:  SYN Y
>    A -> B:  SYN-ACK X' which depends on X and Y, but not X' or Y'
>    B -> A:  SYN-ACK Y' which depends on X and Y, but not X' or Y'
> So in particular B does not have the opportunity to abort TCPINC in
> response to X', but must decide it based on X and Y.  That's why TCP-ENO
> determines the spec based only on the first ENO option sent by each
> side.

But what do you need the other ones for in that case? If they just
contain keying material, you probably want to specialize them to that

"Man is born free, but everywhere he is in chains".