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