Stephen Farrell <[email protected]> writes: >>> It is not at all clear to me that that'd be a good plan. I think >>> the gross-hack that it may one-day open up is unlikely to be worth >>> it, and negotiating once is bad enough so it'd seem like a bad >>> plan to do it twice, which I think would be the inevitable outcome. >> >> Sorry, I can't reconcile the first and last sentence of that paragraph. > > If a mechanism defined in the TCP-ENO document "supported" ckiphersuite > negotiation, but was not deployable (which seems like it'd be the case > given attempts to squeeze in 32 bytes of DH public) then you'd end up > having to support algorithm agility in-band anyway. Hence bad-plan + > doing it twice.
I wish I hadn't conflated things. What's not deployable today is putting a DH key exchange into SYN segments. The downside (in terms of ruling out timestamp, MSS, etc.) is simply not realistic. Of course, that's the long-term dream, so I discussed it, but realistically it cannot happen without large options, so let's just forget I ever mentioned it. 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. As you say, we probably only need two or three ciphersuites in play at a time, a primary and one in case the primary starts looking weak, and maybe third to satisfy diversity of algorithm designers. So there's no reason ENO can't chose between these three. >> We are currently rewriting tcpcrypt to consume three ENO suboptions, one >> for P-256+AES-128, one for P-512+AES-256, and one for >> Curve25519+Chacha/Poly1305. Compared to the existing draft, this lets >> us ditch PKCONF and pretty much everything except the DH parameters in >> INIT1 and INIT2 messages. We are also ditching RSA (which at this point >> was there "just in case," because tcpcrypt had to be future compatible >> with things other than DH, but now ENO frees us from worrying about >> future compatibility). The result is a much simpler document. > > I'll just repeat that I think that's a bad plan and you'd be > better off not making such changes. If you can elaborate on this, we would certainly appreciate it. We certainly can leave a second level of negotiation in tcpcrypt--that would even be easier for us--but it will add pages to the RFC, so it would help to understand why. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
