Subject: RE: I-D ACTION:draft-laganier-ipv6-khi-00.txt

From: "Christian Huitema" <[email-masked]>
Date: Wed, 7 Sep 2005 10:43:39 -0700

> => security considerations explain that:
>  - SHA1 can be replaced by something else
>  - SHA1 is still good for this usage
>  - if SHA1 or another important detail is changed then another prefix
>    must be used.
> 
>    The syntax should allow for an
>    identification of the algorithm as part of the "hash input".
> 
> => the document explains why this is a bad idea.

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.

The cryptographic identifier is checked by comparing the address and
some "input". The input will be carried by an upper level protocol. One
might expect the input to contain a set of information, such as a host
name, a public key, maybe a certificate linking name and key, and maybe
some other information required by the particular application. My point
is simple: one should expect the input to also contain an identifier of
the particular hashing function that is being used.

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.

-- Christian Huitema

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 7 Sep 2005 20:09:50 +0200

> 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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 12:19:51 +0200

=> so we should agree because we have a fixed hash function per prefix
as explained in details by Pekka.

Thanks

[email-masked]

PS: so I'll read your answer to Pekka's message...