Re: [tcpinc] Revised version of TCP-ENO

[David Mazieres <[e-mail]>]

Ted Hardie <[e-mail]> 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