Let's say that I don't buy the justification contained in the
document.
Having a fixed hash function in an algorithm is not acceptable,
period.
Variable hashing functions open the possibility of a "downgrade"
attack,
in which an attacker manages to produce the same "address bits"
using a
very weak and easy to crack algorithm. However, protection against the
downgrade attack is very easy. The host that receives a cryptographic
address and the claimed input will check that the algorithm identified
in the input is "strong enough", and will treat an attempt to use a
weak
hash the same way as a failed hash.
That assumes that the community will move away from the function that
has become more vulnerable overnight. That won't happen; quite a lot
of people still use MD-5 and DES even when their software supports
stronger algorithms.
IMHO, your proposal leaves too much responsibility to the verifier,
which IMHO is wrong in this particular case. The incentives are
wrong. The "owner" of a KHI, i.e. the party that generated it, may
easily have much more interest in keeping the KHI secure than the
verifier, while the verifier may easily have reasons to be as
backwards compatible as possible. Hence, even if Alice created a new
KHI for herself when she learns that the hash algorithm X1 has become
vulnerable, that doesn't help if Bob is still accepting X1. Mallory
may generate a KHI matching with Alice's new KHI using X1, and send
that to Bob. Bob will accept it, allowing Mallory to play Alice.
That is not acceptable.
The only way that works is to encode the hash function in the KHI
itself. If having a fixed hash algorithm is not acceptable, the only
way forward that I see is to take a few bits away from the hash value
(making collisions slightly more probable) and using them to encode
the hash function.
On the other hand, if you assume a closed user group or a group where
you can guarantee that the verifier has larger incentive for security
that backwards compatibility (compared to the KHI generator), then
your proposal is fine. Furthermore, there is nothing in the current
proposal that prevents you from using it within a single context.
What you can do for a specific context is the following:
Input := any string
Hash1 Input := CID | hash function id | Input
Hash1 := Hash(Hash1 input)
SHA1 Input := CID | Hash1
and so on. Basically, you encode another hash function into the
input, and use it first to generate the input for the method defined
in the draft.
--Pekka Nikander
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
