Martin Thomson <[email protected]> writes: > I didn't suggest that you reduce entropy. My point was that you are > creating a special carve-out for your current solution. What if you > decide you want *two* bytes of discriminator? My point is that all > you need is to have the session ID as a whole be hard to > guess.synthesize, etc...
By our current solution, do you mean TCP-ENO? It seems reasonable for the TCP-ENO specification to include a special carve-out for itself. Any other spec that needs a discriminator can just include the discriminator in the collision-resistant hash input. That's fine because a spec knows what goes into the collision-resistant hash. The problem is that TCP-ENO doesn't even know which cryptographic hash functions specs will employ for the session ID. If someday one of those hashes turns out to be incredibly insecure, we want to make sure that if *either* end of the connection disables the bad spec, the security problem goes away. The minimum you need for that is to sign/MAC/etc. not just some hash but also something specifying how that hash was computed, to avoid cross-spec collisions. Given the way the TCP-ENO spec is written, one byte is sufficient for that purpose. There is another solution, which is to hard-code the hash function in TCP-ENO. It's not entirely elegant, either, but you could say all 32-byte session IDs are SHA-256 starting with the negotiation transcript, and IANA can specify other lengths and hash functions down the line. So that's more elegant in that the whole session ID can be made indistinguishable from random, but less elegant in that spec authors might have to rely on two different hash functions. So I can see arguments for 0 or 1 bytes not being indistinguishable from random, but I can't see arguments for a two-byte discriminator, unless you are also advocating more fundamental changes to ENO's negotiation mechanism (which is of course still on the table at this point). David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
