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

[David Mazieres <[e-mail]>]

Stephen Farrell <[e-mail]> writes:

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

Right.  So my working assumption is that the WG has not killed tcpcrypt
yet, and is still deciding on tcpcrypt vs. TCP-use-TLS.  TCP-ENO is an
effort A) to make progress on common elements of TCP-use-TLS and
tcpcrypt, B) to satisfy people from tcpm who believe (correctly, IMO)
that TCPINC would benefit from future TCP enhancements, and C) to enable
a fixed target API for application writers so that any application-level
efforts to leverage TCPINC will continue to apply even across
significant revisions of TCPINC.

> 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:-)

Well, in order to make the choice between tcpcrypt and TCP-use-TLS the
most salient, it seems worth maximizing the advantages of the two
protocols.

The big advantage of TCP-use-TLS is compatibility with TLS.  Hence, the
obvious way to fit TCP-use-TLS onto tcpcrypt is to use a single
ENO suboption to trigger it, and then use as much TLS as possible for
everything else.

The big advantage of tcpcrypt is simplicity (and hence easier analysis)
as well as its tight fit with TCP, for which it was specifically
designed.  So for that our thinking was that TCP-ENO already specifies a
suitable negotiation mechanism, let's not have two different negotiation
mechanisms when we only need one.  It doesn't feel particularly "whacked
in"--in fact there's a very straight-forward fit.  It's basically about
as simple as you can get:

  A->B: SYN      "Hey, I support tcpcrypt suite X and tcpcrypt suite Y"
  B->A: SYN-ACK  "Great, let's use X"
  A->B: ACK      "Agreed, here's my DH parameter"
  B->A: ACK      "Here my DH parameter, ciphertext from here on out"
  ...

The alternative (more like the previous draft of tcpcrypt) would be:

  A->B: SYN      "Hey, I support tcpcrypt and TLS"
  B->A: SYN-ACK  "Great, let's tcpcrypt with cipher suite X or Y"
  A->B: ACK(*)   "I choose X and here's my DH parameter"
  B->A: ACK(*)   "Here my DH parameter, ciphertext from here on out"
  ...

(*)These segments use TCP data for TCPINC messages, not application
   data.

That's also pretty simple, and works perfectly well with the existing
TCP-ENO.  I'd be delighted to do it if we didn't support simultaneous
open.  But simultaneous open risks scenarios like this:

  A->B: SYN      "Hey, I support tcpcrypt and TLS"
  B->A: SYN      "Hey, I support tcpcrypt"
  A->B: ACK(+)   "Great, let's use tcpcrypt with cipher suite X or Y"
  B->A: ACK(+)   "Great, let's use tcpcrypt with cipher suite Z"
  A->B: ACK(*)   DH parameter, etc.

(*)TCP payload includes TCPINC message.

Now this gets messy if either of the segments market (+) is dropped,
because those segments don't consume sequence numbers, and so wouldn't
ordinarily get ACKed.

> *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 there are multiple issues being discussed in this thread:

  1. Should IETF set a global total order on ENO suboption preference,
     or should hosts be able to configure this?

  2. Should simultaneous open enable encryption with no application
     involvement, or is it okay to require a socket option?

  3. Should tcpcrypt leverage TCP-ENO suboptions for ciphersuite
     negotiation?

Questions 1-2 affect the TCP-ENO draft.  Question 3 does not affect the
TCP-ENO draft.  The discussion touched on both because answering YES to
question 1 forces us to answer NO to question 3.  However, my sense is
that the working group mostly believes the answer to #1 is YES.

In that case, does it not make sense to answer question 3 (which affects
only the next tcpcrypt draft) under the assumption that the WG will
select tcpcrypt?  This is not being presumptuous, it's being realistic
that if the WG does not adopt tcpcrypt, we will have to chuck the
document.  So why not optimize the document for the case in which it
actually gets used, no?

That's not to say the answer to #3 is automatically YES.  We are leaning
towards YES because, a posteriori, having fiddled with the tcpcrypt
draft in the context of ENO, answering YES seems to buy us a lot of
simplicity.  We aren't fully convinced, though, so to the extent people
believe the answer is NO, we very interested in arguments, but only
arguments that still apply under the assumption tcpcrypt is adopted by
the WG.

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

But do you still feel this way if the debate becomes one over how to
*use* TCP-ENO, rather than one over what goes in the TCP-ENO document
itself?

David