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

[Stephen Farrell <[e-mail]>]

On 24/08/15 22:44, David Mazieres wrote:
> 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.  

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.

But so long as tcpcrypt is not a WG document that's your call I guess.

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.

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.

However, a caveat - I've not had time to read all of this thread
so apologies if I'm off base a bit.

S.


> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpinc
> 
>