Subject: [tcpinc] ENO negotiation

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Oct 2015 12:39:38 -0700

The current ENO negotiation has a kind of idiosyncratic mechanism,
which, assuming I understand it, works as follows.

A sends a set of identifiers.
B sends its own set of identifiers.

The negotiated spec is the highest priority member (defined by B's
option) of the overlapping set of identifiers. I.e., it's possible for A
to send X, Y, Z and B to send V, W, resulting in negotiation failure.
The reasoning for this is:

   When possible, host B SHOULD send only one spec identifier (suboption
   in the range 0x20-0xff), and SHOULD ensure this option is valid.
   However, sending a single valid spec identifier is not required, as
   doing so could be impractical in some cases, such as simultaneous
   open or library-level implementations that can only provide a static
   TCP-ENO option to the kernel.

My sense is that this is over-design and it would be better just for
A to send a list and B to pick out of the list. I'm not very compelled by
the "static option" reason. That's certainly not something I am excited
about, and I tend to think it would be easier to have a special design
for SO, if needed at all (since you already need special logic for
the symmetry-breaking anyway).

This also leads me to a comment about tcpcrypt's use of ENO. Presently,
it offers one different suboption for each curve group (P-256, X25519, etc.)
rather than offering a variable-length suboption with a list of curves [0].
This
seems to me to be a bit suboptimal and also has the potential for weird
orderings, like tcpcrypt-X25519 > TLS > tcpcrypt-P256. I would suggest
instead using the variable-length suboption.

-Ekr

[0] TLS actually puts these in the ClientHello, though I suppose we could
put a list in the option if that had value.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 22 Oct 2015 14:06:57 -0700

In-line reply.

On Thu, Oct 22, 2015 at 12:39 PM, Eric Rescorla <[email-masked]> wrote:

> A to send a list and B to pick out of the list.
>

​I think that would be the most common case, frankly, because if B has
received and parsed A's list it seems sensible to provide an answer that
has overlap if there is any.  But for simultaneous open, B is a nominal
role determined by the tie-breaker bit, and I don't see how to avoid​ the
risk that the two options don't overlap without simply having an MTI that
MUST always be in the offer.

Am I missing some way of making simultaneous open work here?

​Ted​

> I'm not very compelled by
> rather than offering a variable-length suboption with a list of curves
> [0]. This
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Oct 2015 14:12:37 -0700

> Am I missing some way of making simultaneous open work here?

Perhaps.

1. It's not clear we need SO, since the only SO use cases I know of
are NAT traversal cases which barely work anyway and which generally
have their own COMSEC.

2. The bit isn't a tiebreaker. It's a confirmation that external
coordination
of the roles worked, so that means you might be able to have external
coordination of the ciphers.

3. Even if you don't have external coordination, it might make sense to
simply require that B pick only one if it's not SO, since, as noted above,
SO is a special case.

-Ekr

​Ted​

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Oct 2015 14:33:51 -0700

I forgot to mention something. The text about the ENO option in the non-SYN
packet doesn't seem entirely clear about what must appear in that option.
I'm assuming it's the negotiated _spec_ but unless I've missed it, I don't
see where it actually says that. What happens if that doesn't match the
highest priority option.

-Ekr

---

From: David Mazieres <[email-masked]>
Date: Thu, 22 Oct 2015 19:21:45 -0700

> the symmetry-breaking anyway).

We are already saying that implementations SHOULD behave the way you
want them to.  So really your question is about whether to upgrade that
to a MUST, and if it is a MUST, whether we should specify the behavior
of host A when host B deviates from the protocol with multiple
suboptions or whether we should leave that behavior unspecified.

I'm not super opposed.  There are some plausible ways in which TCPINC
could gain faster deployment with a SHOULD than a MUST.  However, at
this point we just don't have enough implementation experience or data
to debate the point productively.  So I'd suggest we postpone
consideration of the question until we've had some time to kick the
tires on some candidate TCPINC implementations.

> see where it actually says that. What happens if that doesn't match the

In a non-SYN option, the content doesn't matter, only the presence of
the ENO option.  The normative diagram and language were supposed to be
this:

          byte    0     1                0     1     2     N-1
               +-----+-----+          +-----+-----+-----...----+
               |Kind=|Len= |          |Kind=|Len= |  ignored   |
               | ENO |  2  |    or    | ENO |  N  | by TCP-ENO |
               +-----+-----+          +-----+-----+-----...----+

       Figure 2: non-SYN TCP-ENO option in segment without SYN flag

       ...
       
        Figure 2 illustrates the non-SYN form of the ENO option.
        Encryption specs MAY include extra bytes in a non-SYN ENO
        option, but TCP-ENO itself MUST ignore them.

David