Stephen Farrell <[email protected]> writes: > On 24/08/15 21:08, Stephen Kent wrote: >> Watson, >> >> based on many years of experience dealin wit this sort of issue >> I suggest that the relative merits (strength, etc.) of cipher suites >> form a lattice, not a total order. > > Folks - Steve is I think correct here but I'm quite confused > as to why we're having this discussion about this draft. TLS > (if we go there) has a way of negotiating ciphersuites. So > does tcycrypt (or it will before we're done). > > Discussion of AES vs. ChaCha shouldn't be popping up to this > level should it?
Watson has lodged a specific objection to the fact that TCP-ENO allows hosts to express preferences for TCP-ENO specs, vs. having the IETF impose a total ordering on the specs. By analogy, he gave the example of always preferring SSHv2 over SSHv1 (though I note that OpenSSH permits you to overwrite this default by putting "Protocol 1,2" in a stanza, and people actually do this sometimes to accommodate old authorized_keys files with v1-format user keys). The issue relates to ciphers because TCP-ENO can be used to negotiate cipher suites. Indeed, that is how we are currently rewriting the tcpcrypt draft, and it has significantly simplified things. Even if our initial TCPINC spec supports negotiation outside of TCP-ENO (as TCP-use-TLS does), we still need to allow the possibility of ENO being used to negotiate cipher suites, because if we ever get large SYN options, we will want a new spec that starts an ECDH exchange in the SYN-ACK (or possibly even initial SYN) segment. In fact, it's possible to fit a 32-byte ECDH parameter into a SYN-ACK segment today. That means even without large SYN options, we can imagine making TCPINC zero latency. Realistically, doing so will require a gross hack in which TCP-ENO compactly encodes timestamp and SACK availability, window scaling, etc., in lieu of larger options. I don't expect people would be very happy with something like that from day one. But we don't want to shut the door to such an optimization either, in case TCPINC becomes a runaway success. (We've been careful to leave a bunch of reserved suboptions in the TCP-ENO spec just in case we need extra bits for such optimizations.) That said, Watson has a point that even more simplicity is to be gained by just picking some particular cipher suite that works. I respect this argument, but given how many future unknowns are associated with any choice of cipher suite, and given the additional hurdles this may create to standardization (as it forces us to argue over ciphers as well), I'm unpersuaded by his argument. Thus, unless a bunch of other people voice the same opinion, I do not anticipate the group would want to remove the preference mechanism from TCP-ENO. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
