Hiya, On 24/08/15 23:48, David Mazieres wrote: > Stephen Farrell <stephen.farr...@cs.tcd.ie> writes: > >>> The issue relates to ciphers because TCP-ENO can be used to negotiate >>> cipher suites. >> >> 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. > If negotiated TCP-ENO spec implies a specific cipher suite, then you > only negotiate once. If TCP-ENO specs have multiple cipher suites, then > you have two negotiations, first the ENO-level meta-negotiation on how > to negotiate, then a second cipher suite within the particular > encryption spec. > > Your first sentence reads like a recommendation *not* to tie a single > cipher suite to a single TCP-ENO suboption, in which case you'd need a > separate cipher suite negotiation mechanism. Your second sentence > implies you consider two rounds of negotiation a bad idea, in which case > why wouldn't you want ENO to negotiate the cipher suite. We value your > opinion on this question, so please clarify! > >> But so long as tcpcrypt is not a WG document that's your call I guess. > > 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. S. > > But this is all easy to change until we've updated the code to match the > forthcoming document, so high-level feedback now would be appreciated. > >> My take fwiw would be that a TCP option should really only signal >> turning on TCPINC full stop. And that TCPINC initially ought only >> have two ciphersuites defined, one for use now and a backup. But >> TPCINC will have to support some form of algorithm agility so that >> that pair of ciphersuites can be changed over time. So yes some >> form of agility is needed but it's not clear to me that a TLS-like >> scheme is best. > > Given that latency is critical, at a minimum we have to start the > public-key cipher negotiation in the SYN-ACK of a three-way handshake. > So why not have the TCP-ENO suboption just specify the ciphersuite? > >> If/when practical deployment of DH values becomes feasible then >> it'd be time to discuss how to use that. But not now when that is >> not, if I understand correctly, possible to do that. > > Well, it is possible today. What's not not possible is to do that and > enable TCP timestamp for the same connection. > > David > > _______________________________________________ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc > > _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
