chair^ I don't think this has been a waste of time at all. Even if we decide to make no changes, the discussion has brought forth a number of interesting considerations not necessarily limited to SO, including that of how tcpcrypt will perform in a world of quantum-resistant key exchange.
member^ Regarding distinguishing role: >> There are two simple ways of handling authentication, in this >> scenario, depending on whether and how much you care about >> distinguishing “which endpoint is which” in the process. > > Exactly. The fact that applications currently have to chose between > multiple ways of doing this means they may get it wrong. Whereas having > a session ID and a role is pretty simple. What exactly is the issue here? You mentioned a client being tricked into thinking it has connected to itself, but I think I need you to spell out the worry here. In my earlier post, I was thinking it was sufficient for an application to know it is (at least) one end of a session identified by a particular SID, but I'm perfectly willing to believe I'm missing something subtle here. > But how is TCP's model symmetric? Simultaneous open is this weird > fringe case that didn't even work until we had NATs and firewalls to > suppress SYNs that would otherwise trigger RST packets. Even now it > basically only works through particular kinds of NATs. We can barely > seem to find any examples of its use in practice. Other than that, TCP > is full of asymmetries on both the connection setup and shutdown. > Someone with more historical perspective can correct me if I'm wrong, > but it doesn't appear as though symmetry was a particular design goal of > TCP. Yeah, I am worried we're expending too much mental energy on SO itself. But part of the reason I'm glad it was brought up is that I still have no real idea what the TCP establishment thinks about the expendability of SO considerations. I'd hate to put a lot of work into something and have the tsv AD or IESG remand it because it turns out a lot more people care about SO than we currently guess. That having been said, my suspicion is that it won't be a problem if the naive failure mode for an unmodified SO-based app, both endpoints of which support TCPINC, is to fall back to unencrypted TCP. I can believe they would have a problem with a failure mode in which SO applications fail to connect. Kyle _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
