Stephen Farrell <stephen.farr...@cs.tcd.ie> writes: >> What is eminently deployable is using TCP-ENO to negotiate a >> ciphersuite. E.g., you can agree to use curve25519 for ECDHE by the end >> of the SYN exchange, and include a DH parameter in the first data >> segment of a connection, after only one round trip. > > So yes one could. But that assumes that the WG have not chosen > to do TLS I think, doesn't it? If the WG did choose TLS then > ciphersuite selection has to happen in the TLS h/s or else we > will not get the security guarantees that TLS is supposed to > give us.
Right. So my working assumption is that the WG has not killed tcpcrypt yet, and is still deciding on tcpcrypt vs. TCP-use-TLS. TCP-ENO is an effort A) to make progress on common elements of TCP-use-TLS and tcpcrypt, B) to satisfy people from tcpm who believe (correctly, IMO) that TCPINC would benefit from future TCP enhancements, and C) to enable a fixed target API for application writers so that any application-level efforts to leverage TCPINC will continue to apply even across significant revisions of TCPINC. > Even without the large options, whacking in ciphersuite specific > values in TCP-ENO now is a bad plan as it (for me anyway) further > muddies the already muddy waters within which we've been fishing > for consensus in this WG. (Apologies for the strained analogy and > even more for the pun in the apology:-) Well, in order to make the choice between tcpcrypt and TCP-use-TLS the most salient, it seems worth maximizing the advantages of the two protocols. The big advantage of TCP-use-TLS is compatibility with TLS. Hence, the obvious way to fit TCP-use-TLS onto tcpcrypt is to use a single ENO suboption to trigger it, and then use as much TLS as possible for everything else. The big advantage of tcpcrypt is simplicity (and hence easier analysis) as well as its tight fit with TCP, for which it was specifically designed. So for that our thinking was that TCP-ENO already specifies a suitable negotiation mechanism, let's not have two different negotiation mechanisms when we only need one. It doesn't feel particularly "whacked in"--in fact there's a very straight-forward fit. It's basically about as simple as you can get: A->B: SYN "Hey, I support tcpcrypt suite X and tcpcrypt suite Y" B->A: SYN-ACK "Great, let's use X" A->B: ACK "Agreed, here's my DH parameter" B->A: ACK "Here my DH parameter, ciphertext from here on out" ... The alternative (more like the previous draft of tcpcrypt) would be: A->B: SYN "Hey, I support tcpcrypt and TLS" B->A: SYN-ACK "Great, let's tcpcrypt with cipher suite X or Y" A->B: ACK(*) "I choose X and here's my DH parameter" B->A: ACK(*) "Here my DH parameter, ciphertext from here on out" ... (*)These segments use TCP data for TCPINC messages, not application data. That's also pretty simple, and works perfectly well with the existing TCP-ENO. I'd be delighted to do it if we didn't support simultaneous open. But simultaneous open risks scenarios like this: A->B: SYN "Hey, I support tcpcrypt and TLS" B->A: SYN "Hey, I support tcpcrypt" A->B: ACK(+) "Great, let's use tcpcrypt with cipher suite X or Y" B->A: ACK(+) "Great, let's use tcpcrypt with cipher suite Z" A->B: ACK(*) DH parameter, etc. (*)TCP payload includes TCPINC message. Now this gets messy if either of the segments market (+) is dropped, because those segments don't consume sequence numbers, and so wouldn't ordinarily get ACKed. > *If* the WG selected tcpcrypt then it might make sense to see > if algorithm agility could be sufficiently well supported in the TCP > handshake. I'm not sure if it could or not myself. But if the WG > selects TLS or decide to pursue both (ick) then that'd not make > any sense that I can see. So there are multiple issues being discussed in this thread: 1. Should IETF set a global total order on ENO suboption preference, or should hosts be able to configure this? 2. Should simultaneous open enable encryption with no application involvement, or is it okay to require a socket option? 3. Should tcpcrypt leverage TCP-ENO suboptions for ciphersuite negotiation? Questions 1-2 affect the TCP-ENO draft. Question 3 does not affect the TCP-ENO draft. The discussion touched on both because answering YES to question 1 forces us to answer NO to question 3. However, my sense is that the working group mostly believes the answer to #1 is YES. In that case, does it not make sense to answer question 3 (which affects only the next tcpcrypt draft) under the assumption that the WG will select tcpcrypt? This is not being presumptuous, it's being realistic that if the WG does not adopt tcpcrypt, we will have to chuck the document. So why not optimize the document for the case in which it actually gets used, no? That's not to say the answer to #3 is automatically YES. We are leaning towards YES because, a posteriori, having fiddled with the tcpcrypt draft in the context of ENO, answering YES seems to buy us a lot of simplicity. We aren't fully convinced, though, so to the extent people believe the answer is NO, we very interested in arguments, but only arguments that still apply under the assumption tcpcrypt is adopted by the WG. > So trying to figure out now if or how algorithm agility can be > handled via TCP options is IMO a bad plan that may move us further > away from rather than towards consensus. But do you still feel this way if the debate becomes one over how to *use* TCP-ENO, rather than one over what goes in the TCP-ENO document itself? David _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc