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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
