Watson Ladd <watsonbl...@gmail.com> 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 _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc