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

[David Mazieres <[e-mail]>]

Watson Ladd <[e-mail]> writes:

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

What you describe about lexicographically least is a proprety of the
encryption spec.  The question ENO addresses is how to negotiate that
spec in the first place.  Suppose suboptDHE does what you describe and
suboptA is TCPINC (e.g., something derived from tcpcrypt or
TCP-use-TLS).  Now consider the following simultaneous open:

  A->B: SYN ENO<suboptA, suboptDHE key-material>
  B->A: SYN ENO<suboptDHE key-material>, ENO<suboptA>

Keeping in mind that the above two messages were sent concurrently,
which spec should ENO chose:  A or DHE?  The current draft says pick the
first spec in whichever SYN segment has the b flag set, and disable
encryption unless exactly one SYN segment has the b flag set.

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

It is probably used mostly by NAT-piercing applications.  The timing is
actually hard to get right if you don't have NATs involved to drop SYN
segments that would otherwise trigger resets.  I wish I had more data on
this.

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

I don't understand your comment.  By "the other ones", do you mean the
contents of packets X' and Y' in the simultaneous open scenario?  With
TCP-ENO you don't need those contents (just the one bit that the option
got through and was acceptable).

The context of the example was a response to a comment from EKR about
why not eliminate the tie-breaker bit "b" and have B chose one of the
active opener's encryption specs.  I can't see a way to make EKR's
suggestion work without embedding meaningful data in X'.  And the
problem I was pointing out is that the other side must commit to TCPINC
before seeing the contents of X'.

But I may have misunderstood your question.

For context, keep in mind that, while we would like to leave open the
possibility of embedding a DH key exchange in the SYN options, this
cannot be the only solution to TCPINC, because 32-byte curves may stop
being secure before we get large options in SYN segments (not to mention
middlebox problems of inevitably compressing SACK, TIMESTAMP, etc., to a
supported-option bit-vectorj.  So we need a more general
forward-compatible negotiation option.  To avoid a circular dependency,
the negotiation needs to proceed independently of the particular
encryption spec.

David