review of Projects/replay_cache_collision_avoidance, ending Jan. 12

[Greg Hudson]

On Mon, 2008-12-29 at 08:02 -0500, Tom Yu wrote:
> What proportion of false positives is acceptable in a mixed-code
> deployment?

I think mixed-code deployments are going to be rare.  It's good that
we're going to effort to prevent things from breaking in such
deployments, but I don't think we need to bend over backwards to ensure
that we still get a reduction in false positives in such environments.

> One interesting possibility is to store a truncated copy of the hash
> in the microseconds field, which an old implementation would likely
> preserve when performing an expunge.

Speaking of which, the project proposal says:
        
        For new servers reading entries written by old servers, the
        string fields will be valid principal names and the time stamp
        value will not be a small integer. As a result, the server will
        know it is dealing with an old style entry and perform an old
        style check. This might lead to false positives but there is
        nothing we can do without additional information that is not
        available.

but the earlier part of the proposal doesn't mention anything about
putting a small integer in the time stamp value of hash records.  Is
there a missing bit of the proposal?

> I'd still like to know what benefit hashing the decrypted
> authenticator has above hashing the ciphertext.  As Roland pointed out
> elsewhere in that thread, the mandatory parts of the cleartext
> authenticator contain nothing that is guaranteed to be different for
> multiple rapidly consecutive legitimate requests.  Hashing the
> ciphertext makes it less likely that false positives will occur.

I think Sam has reversed his position on that point based on discussion
with Ken, and we can safely hash the authenticator ciphertext.