Daniel Kahn Gillmor <[email protected]> writes:
> On Thu 2015-08-13 17:05:38 -0400, Kyle Rose wrote:
>> This can't be the case if, for instance, the session IDs are signed in
>> batches as proposed in the tcpcrypt paper.
>
> You seem to be assuming that peer authentication will happen by an
> cryptographic public-key signature over the session id. In this case, i
> agree that the session id could be published without a problem.
>
> But this isn't necessarily the only mechanism that could be used to
> authenticate the peer.
So I think this conversation is convincing me of Kyle's point of view
that we should use the word public, to convey intended usage. What
about something along the lines of:
* Specs should assume the session ID will be made public and ensure
that it contains no confidential data (such as data permitting the
derivation of session keys).
* However, unless the application at either end of a connection
takes steps to disclose the session ID, specs should ensure that a
network eavesdropper has a negligible advantage in differentiating
the collision-resistant hash in a session ID from uniform random
bytes.
Whether you are using Public keys to sign session IDs, or HMAC to
authenticate them, or some PAKE thing dependent on the session ID, it
shouldn't matter that the session ID is public. You don't have to make
it public, but the formula for generating it should assume it will be
made public.
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.
What do you think?
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
