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