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

[David Mazieres <[e-mail]>]

Stephen Farrell <[e-mail]> writes:

>>> 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.

I wish I hadn't conflated things.  What's not deployable today is
putting a DH key exchange into SYN segments.  The downside (in terms of
ruling out timestamp, MSS, etc.) is simply not realistic.  Of course,
that's the long-term dream, so I discussed it, but realistically it
cannot happen without large options, so let's just forget I ever
mentioned it.

What is eminently deployable is using TCP-ENO to negotiate a
ciphersuite.  E.g., you can agree to use curve25519 for ECDHE by the end
of the SYN exchange, and include a DH parameter in the first data
segment of a connection, after only one round trip.

As you say, we probably only need two or three ciphersuites in play at a
time, a primary and one in case the primary starts looking weak, and
maybe third to satisfy diversity of algorithm designers.  So there's no
reason ENO can't chose between these three.

>> 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.

If you can elaborate on this, we would certainly appreciate it.  We
certainly can leave a second level of negotiation in tcpcrypt--that
would even be easier for us--but it will add pages to the RFC, so it
would help to understand why.

David