Ted Hardie <[email protected]> writes: >> That said, one could imagine a fringe use case where an application >> wants to prove that two anonymous TCP connections belong to the same two >> processes, in which case the session ID of the first connection might be >> used as a MAC key to authenticate the session ID of the second. So you >> don't want the session ID to be predictable, even if making it public >> doesn't hurt TCPINC itself. >> >> > I don't think I understand this use case. To whom does the application > want to prove this?
Again, it's pretty fringe, but here's a contrived application. I'm running some kind of legacy protocol over TCPINC that involves a long-running TCP connection, but at least one end is anonymous. Maybe it's a chat application like IRC. But now I want to run a newer control protocol that connects to the same server and proves it is associated with the previous connection. It can do so by using the previous session ID as a MAC key. Also, if we want the 32+-byte hash size to mean anything, we kind of need the session ID to make use of all the bits anyway. Finally, when you're trying to prove things, pseudo-random quantities are often nice to work with. So that's three kind of mediocre reasons to have pseudo-random session IDs, vs. zero reasons to permit lower-entropy/predictable ones. We hadn't previously required it, but this brief discussion has made me inclined to require pseudo-random session IDs. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
