In-line reply. On Thu, Oct 22, 2015 at 12:39 PM, Eric Rescorla <[email protected]> wrote:
> 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 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 > 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 >
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
