Stephen Farrell <[email protected]> writes: > I think we might want to also consider that one thing that > might happen is that loads and loads of these values (or > values derived from them) could end up being accumulated and > eventually end up really public. Just for safety's sake I'd > probably prefer that what might end up public is not the same > set of bits used as the session ID during the session though. > For example, using the same bits might enable later correlations > between log files that we'd prefer not be possible - say between > some client-host-firewall log reported via telemetry and an > application server log. So there might be benefits in defining > a way to do that so that application developers don't get > it badly wrong. In [1] we talk about a witness value that > is different from a session ID. Not sure if that's useful > here (or there;-) or not though.
I think you raise several questions here. First, should what TCP-ENO calls the session ID be traceable to a particular connection by a passive eavesdropper? A contrived scenario here is that for some reason you run a bulletin board that logs messages and session IDs. I put your bulletin board under surveillance, recording a complete packet transcript. Now I don't like a particular message. From its session ID, can I tell which client connection posted the message (assuming, say, that all messages are the same length and that timing information is obscured by batching the messages at the server). As I said, this is a bit contrived, but if everyone uses the same encryption spec, I do think there is value in this kind of privacy, and it is achieved by requiring the session ID to be computationally indistinguishable from random. Second, instead of a single session ID, should we define two values with this property, a "witness" and a "session ID", where the witness is available for use by other transport-level RFCs (such as MPTCP) and the session ID is for use by applications. Or, generalizing, allow a whole host of values indexed by an integer. The advantage of this is that domain separation ensures that whatever your application does will not undermine, say MPTCP. This is a valid argument, but it adds a lot of complexity, so it might be nice to avoid, also. > Lastly, we should check that whatever is done here is ok for > MTPCP. I assume you mean MPTCP? If so, I agree, assuming by "ok" you mean a subsequent update of MPTCP can easily integrate with TCP-ENO (as opposed to TCP-ENO citing RFC6824 as a normative reference and directly specifying how the two work together). David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
