Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[David Mazieres <[e-mail]>]

Stephen Farrell <[e-mail]> 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