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

["Paul Hoffman" <[e-mail]>]

On 30 Sep 2015, at 5:28, Joe Abley wrote:

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

It is true if M>N, and in practice may be true even if M=N.

> If I can alter a message in such a way that the digest remains the 
> same, I can defeat the checksum.

But now you switched from talking about collisions to talking about 
preimage attacks. Collision attacks are when you find two messages with 
the same hash *before issuing the messages*. SHA-1 (nor even MD5!) is so 
far not susceptible to preimage attacks.

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

For this type of system, you want a hash or checksum function where 
finding collisions takes more than N attempts, and all of those attempts 
must be based on random guessing, not on some structure of the messages. 
N can be calibrated by the value of an attacker fooling you and the 
amount of time they have to create the collision. N=2^64 is probably 
sufficient for this attack because we still don't have a way to do 2^64 
guesses in a reasonable amount of time, and SHA-1 is still probably 
within that boundary. However, FNV (a non-cryptographic hash) has the 
same amount of collision protection but runs much faster.

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

Indeed. And this still calls into question whether trying to engineer a 
solution like this is a better idea than just using TCP.

--Paul Hoffman