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

[David Mazieres <[e-mail]>]

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

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