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

[Watson Ladd <[e-mail]>]

On Sat, Aug 22, 2015 at 10:13 PM, David Mazieres
<[e-mail]> wrote:
> Eric Rescorla <[e-mail]> 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.
>
>> TECHNICAL
>> 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
case.

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