On Thu, Oct 22, 2015 at 2:06 PM, Ted Hardie <[email protected]> wrote:
> 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? > 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 > > > >> 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
