review of Projects/replay_cache_collision_avoidance, ending Jan. 12

[ghudson@MIT.EDU]

I would like to reconsider the presence of the hash algorithm
identifier in the proposal.  The identifier was added in response to
this exchange:

http://mailman.mit.edu/pipermail/krbdev/2005-May/003447.html
[Jeffrey Altman:]
> I think we want to avoid the configurability at the moment.   We can
> use the server string as a marker for the type but I think having
> multiple hash types in the file is only going to get us into trouble.
[Jeffrey Hutzelman:]
> Configurability in this dimension is not that important, at least
> for the moment.  However, _extensibility_ is important.  Don't paint
> yourselves into a corner in which you can't transition from one hash
> to another.  In my mind, this means the hash type would need to be
> recored in each entry, so that future code can handle caches with
> two hash types, for transition purposes.

Here are my counterarguments:

1. Supporting multiple algorithm identifiers is not simple.  With a
fixed hash algorithm, you can hash a received authenticator once, use
it to check each record, and (if the authenticator is accepted) use
the same hash value to write out a new record.  With multiple
algorithms, the checking loop has to be prepared to re-hash the
received authenticator for each record.  (Note that I am addressing
the complexity cost here, not the performance cost.  The performance
cost is negligible since in almost every practical scenario, the
expected number of re-hashes is zero.)

2. Since the hash algorithm is not security-critical in this
application, it is vanishingly unlikely that we will ever need to
change it.

3. Extensibility mechanisms, where they exist, should be general.  An
algorithm identifier does not help us if we need to add another piece
of information to records, or if we want to change the data string
being hashed, both of which are much more likely than us needing to
change the algorithm.  In fact, we already have a more general
extensibility hook: the four-byte extension magic number extension
magic number 0x48415348 ("HASH").

4. The proposal does not define the meaning of the algorithm
identifier, and it is easier to simply remove it than it is to define
its meaning.