Re: [tcpinc] Revised version of TCP-ENO

[David Mazieres <[e-mail]>]

Martin Thomson <[e-mail]> 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