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.
> The session ID is a channel binding identifier, not a cryptographic
> secret. Woe betide anyone who bootstraps authentication outside of the
> context of the encrypted session using a session ID it had seen
> sometime in the past under the assumption it was secret.
I'm not talking about anything outside of the encrypted session, or any
sort of past data linkage.
> This is why I like the original wording of "public", because it
> clearly implies you can throw one around at will as its knowledge will
> do no good to anyone not in control of one of the endpoints of the
> connection.
If we really want to limit ourselves to authentication mechanisms that
don't break if the session ID is public, then i agree we should call it
"public". But i personally haven't evaluated the full bestiary of
PAKE/SRP/PSK/all possible uni- or bi-directional authentication
mechanisms that one might want to use. So i'm not confident that we can
safely treat the session ID as a public variable in all cases.
But I'm happy to hear arguments in that direction, if you've got 'em.
At the very least, publication/leakage of the session ID could indicate
that two endpoints were probably talking to each other (if they both
announce that they've seen the same session ID). Do we want to
encourage that kind of metadata leakage by saying they should be
"public"?
--dkg
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
