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

[Watson Ladd <[e-mail]>]

On Sat, Aug 22, 2015 at 11:12 PM, David Mazieres
<[e-mail]> wrote:
> 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.

So 50% of the time, encryption fails between two parties both
supporting the spec, when using simultaneous open. Why not impose a
fixed ordering on all possible options and use the best mutually
supported option, aka versioning?

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

My question is as follows: If we're willing to add half an RTT of
latency because we can't put key material in the first flight,
we can do the following exchange in the following manner
A->B "I can speak X,Y,Z"
B->A: "X, and here is my key share"
A->B: "here is my key share".

In the simultaneous case we can do: (using ; as sequencing mark)
A->B: "I speak X, Y, Z"
B->A: "I speak X,Y,Z";
A->B: "My key"
B->A "My key"

A and B both know that X, Y, Z are ordered, and so can agree.
Now, both kinds of message are completely different, and so shouldn't
be variations on the same kind to avoid attacks based on confusing SYN
with SYN-ACK.

>
> David



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