review of Projects/replay_cache_collision_avoidance, ending Jan. 12

[Tom Yu]

Greg Hudson <ghudson at MIT.EDU> writes:

> 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.

I think that looking for pairs of entries as an indication of a record
written by a new implementation will reduce the number of false
positives for authenticators received by new implementations.  I'm
fairly sure this gives us at least a somewhat improved false-positive
rate in a mixed-code deployment.

>> 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 think I forgot to update part of the proposal after I removed the
part of the prior version of the proposal that would put identifying
information in the timestamp field.  I think it turns out that using
the timestamp that way would cause an old implementation to
prematurely expunge new-style cache records.

>> 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.

Ok, it looks like we have consensus on this part.