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

[Stephen Farrell <[e-mail]>]

Hiya,

On 25/08/15 15:27, David Mazieres wrote:
> 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. 

Conflating often does that - but none of us are perfect, certainly
not me;-)

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

Good.

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

So yes one could. But that assumes that the WG have not chosen
to do TLS I think, doesn't it? If the WG did choose TLS then
ciphersuite selection has to happen in the TLS h/s or else we
will not get the security guarantees that TLS is supposed to
give us.

Even without the large options, whacking in ciphersuite specific
values in TCP-ENO now is a bad plan as it (for me anyway) further
muddies the already muddy waters within which we've been fishing
for consensus in this WG. (Apologies for the strained analogy and
even more for the pun in the apology:-)

*If* the WG selected tcpcrypt then it might make sense to see
if algorithm agility could be sufficiently well supported in the TCP
handshake. I'm not sure if it could or not myself. But if the WG
selects TLS or decide to pursue both (ick) then that'd not make
any sense that I can see.

So trying to figure out now if or how algorithm agility can be
handled via TCP options is IMO a bad plan that may move us further
away from rather than towards consensus.

If TCP-ENO is proposed as a meta-negotiation of the security
protocol to use that is arguably different. I still don't like it
(as I don't want us to continue processing both TLS and tcpcrypt,
though it seems like Martin T. disagrees with me on that) but at
least that meta-negotiation wouldn't repeat stuff done within TLS
or tcypcypt so isn't nearly as bad as putting ciphersuite stuff
into TCP options (now).

Cheers,
S.

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