> Well, first, it's not at all clear that the new protocol will be > simpler. For example, how does session resumption work with two session > IDs?
As Bryan indicated, you could introduce a bidirectional PMS from which a bidirectional SID could be derived. If there is more than one key exchange (see below), order the outputs of the key exchange lexicographically, and use that as the PMS. > Having two session IDs could also make things a lot more > complicated for applications. I don't know that there's any particular reason to have unidirectional SIDs, only a way to construct a single SID in a way that does not depend on designating either end of the connection as A or B. > Second, just because currently we are using ECDHE does not mean that we > always will be. If you're using RSA, both sides could encrypt a secret and then order the two lexicographically to make the PMS. Of course, you'd have to agree to use RSA or ECDHE in advance, but you're already doing that via TCP-ENO. > Third, the working group has been unable to identify a good application > of simultaneous open that A) would benefit from tcpinc, and B) is harmed > by the current b bit mechanism. Sure. All the above having been said, I don't know how much effort should be put into supporting simultaneous open; my instinct, however, is to support it transparently if it doesn't overly complicate matters. I don't think these changes overly complicate the protocol. Kyle _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
