Re: [tcpinc] Revised version of TCP-ENO

[Martin Thomson <[e-mail]>]

Again, you are getting bogged down in the details.  What are the
properties you would expect from a session ID?  That it is unique to a
session and that it is hard to guess (with high probability).  Those
are the only properties that you need to require at this level of the
design.

To up-level a little, I think that TCP-ENO is going too far in terms
of specifying extra little bits.  This session ID stuff is a good
example of that.  If the purpose of the draft is to enable selection
of an encryption scheme, then it has far too much machinery.

I have problem with specifying requirements, which is part of what
Section 4 attempts to do.  But you'd be better off doing so in a
straightforward fashion.



On 14 August 2015 at 10:25, David Mazieres
<[e-mail]> wrote:
> 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