Re: Spin bit discussion - where we're at

["Eggert, Lars" <[e-mail]>]

Hi,

On 2017-11-29, at 1:26, Brian Trammell (IETF) <[e-mail]> wrote:
> There are three possible states for an ECN negotiation: not attempted, failed, and succeeded. Each of these can add a fractional bit of information about the client and server TCP implementations. If a server negotiates ECN, you can be reasonably certain that it supports ECN, and can leverage the observations that sysadmins love defaults and servers are mostly Linux these days to figure out whether it's running a kernel before or after server side defaults were turned on.
> 
> Long-term observation of the ECN negotiation attempts of a client can be used to determine if the client is using probabilistic negotiation by default; i.e. is an Apple device of a certain vintage.
> 
> These are fractional bits of fingerprinting information, though, if that. I'm almost certain (but won't take the time to do the research now) that any of these observations would be useless. Anyone in a position to make them could also get much more information about the behavior of the TCP stacks at each end, such that the ECN bits add negligible information. cf. p0f, if that's still a thing.

this is certainly all true for TCP and ECN, where whether ECN is available and/or tried by default is tied to a certain kernel versions.

But for QUIC (= ECN with UDP), whether ECN is used or not is completely up to the app (= the QUIC stack), so you can't draw conclusions about whether a certain kernel or OS flavor is underneath (other than they less than about ten years old, i.e., have support for the IP_TOS/IP_RECVTOS socket options.)

So the fractional information leakage seems to be less than with TCP.

Lars