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 <[email protected]> wrote: > 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
