Upon further reflection ("these are loafers"), I am returning to my
previous position.
I was conflating two issues: cipher spec and authentication. The problem
here is that the application doesn't by default choose the cipher spec(s),
so the session ID is what it is, which means it needs to be lowest common
denominator over all applications. That means "public", at least for all
default cipher specs.
Is it reasonable for a system like tcpinc to support specs available via
TCPENO_SPECS that have properties that allow naïve misconfiguration to
create vulnerabilities? Maybe the historical problem of people doing dumb
things with SSL_Ciphers is not an issue for TCP-ENO, with sane defaults.
Kyle
> 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'm starting to come around to dkg's viewpoint that it doesn't
necessarily *have* to be public: batch signing of session IDs is one
suggested use case, but authentication protocols that don't do that
could potentially make use of the session ID being private.
I think maybe guidance about when it is appropriate to consider them
public vs. private belongs in section 4.1 of this doc, or in the API
doc if a section there is added on batch signing. Strictly speaking,
the current wording ("The session ID MUST NOT contain any confidential
data (such as data permitting the derivation of session keys)") is
probably right.
Kyle
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
