Re: [DNSOP] New Version Notification for draft-muks-dnsop-dns-message-checksums-00.txt

["Joe Abley" <[e-mail]>]

On 29 Sep 2015, at 22:32, Mukund Sivaraman wrote:

>> The Security Considerations section should say more about the
>> limitations of this approach, e.g. the ability of an off-path attacker
>> to correct for changes that would change a checksum with other changes
>> that will restore it, which is my lazy précis of the no-doubt more
>> succinct observation that Vixie made somewhere in this thread (or
>> another thread near it).
>
> I didn't understand this part. Candidate checksum algorithms will have
> to be one-way cryptographic hash functions, and they will automatically
> take care of this.

Any hash function is susceptible to collisions; this is surely a simple truism based on the mapping of an M-bit message to an N-bit digest where usually M >> N. If I can alter a message in such a way that the digest remains the same, I can defeat the checksum.

Surely the threat models here depend on the algorithm. I am no cryptographer, but it seems reasonable to mention the characteristics of the hash function that are important to minimise the risk of this kind of attack, especially when there are other motivations in choosing an algorithm (such as the speed at which it can be calculated) that might weaken the mechanism.

To choose an extreme example, it seems likely that choosing to calculate a parity bit would be much computationally cheaper than calculating a SHA-256 digest. However, a parity bit would not offer much protection against off-path attacks.


Joe