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

[Eric Rescorla <[e-mail]>]

Review of draft-bittau-tcpinc-tcpeno-01

I have reviewed the -01 version of the ENO draft. This seems like a good
general idea, but I have concerns about a number of the details.


TECHNICAL
S 3.0.
The variable/non-variable encoding seems suboptimal and in particular
the restriction that only one suboption can be variable length. What
are we going to do if two specifications wish to have variable-length
data in the SYN packets? The specification suggests that you should
address this by having two ENO options but that seems clumsy.

I would suggest instead that if the v bit is set the next byte be the
length. This comes at the cost of one byte for settings where there is
only one variable-length option but is more efficient when you
want to have multiple variable-length options, since you don't need
to repeat the kind byte.


S 3.1.
I am not convinced that a one-bit tiebreaker for simultaneous open
is going to work. Experience with other protocols that have the
problem of symmetry (e.g., ICE) is that this sort of thing results
from confusion about which side is really "first". In that case,
both sides will try to set the same "b" bit, and you will not break
the symmetry.

I believe we must either ignore simultaneous open or use a higher-
entropy tiebreaker.


S 3.2.
I am unclear on why the active opener needs to have an ENO segment
in his first ACK. Can you explain?

This mechanism for negotiating mechanisms seems over-complex, what
with A and B each providing lists and then choosing B's top
preference.  I would suggest instead that we simply have B choose out
of A's list, as with ALPN. The document offers two reasons why this
might not work, simultaneous open and inflexible implementations: If
we resolve simultaneous open in the SYN exchange then this should work
fine and the issue of implementation seems like a corner case.


S 3.3.
Having two different "application aware" code points (10 and 01) seems
like it's asking for trouble. I would make one of these reserved.


S 4.
I understand the desire to require a minimum cipher length, but I
would observe that read strictly, "128-bit security" excludes
Curve25519 and also would exclude AES if any real analytical progress
is ever made and it becomes secure at (say) 127 bits.

I'd like to see more clarity around forbidding encryption modes that
don't supply PFS. For instance, with TLS a common strategy for
optimizing session resumption is for the client to send the server
a traffic key encrypted under the server's master key, thus allowing
the server to be stateless (RFC 5077 Session Tickets). Would this
be forbidden?


S 4.1.
Given that session IDs are required to be unique, why bother with the
spec-id prefix?


EDITORIAL/TERMINOLOGY
Instead of describing this as a negotiation between "specs" I would
describe it as a negotiation between "protocols".

I would use the terminology "initiator" and "responder" rather than
A and B. This matches IKE and is generally more familiar.

"Session ID" is a technical term in TLS that means something different
than here. Perhaps "channel binding" or "channel identifier"?