I forgot to mention something. The text about the ENO option in the non-SYN packet doesn't seem entirely clear about what must appear in that option. I'm assuming it's the negotiated _spec_ but unless I've missed it, I don't see where it actually says that. What happens if that doesn't match the highest priority option.
-Ekr On Thu, Oct 22, 2015 at 2:12 PM, Eric Rescorla <[email protected]> wrote: > > > 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
