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

From: "Christian Huitema" <[email-masked]>
Date: Tue, 6 Sep 2005 21:31:32 -0700

> We would appreciate very much feedback from members of the IPv6 WG on
> this internet draft.

I am supportive of the genral idea of reserving a prefix for
"statistically unique identifiers" that are derived from some kind of
cryptographic ID. However, I have a problem with the specified syntax:

   Input      :=  any bitstring
   Hash Input :=  Context ID | Input
   Hash       :=  SHA1( Expand( Hash Input ) )
   KHI        :=  Prefix | Encode_n( Hash )

This syntax includes a static reference to the SHA1 hash function and to
the "encode_n" extraction function. As a general rule, hard coding a
specific cryptographic algorithm in a standard is a very bad idea. In
fact, SHA1 is already suspect. The syntax should allow for an
identification of the algorithm as part of the "hash input".

I would much prefer seeing the syntax modified to explicitly allow for
an arbitrary hashing function, maybe something like:

   Input      :=  any bitstring
   Hash Input :=  Algorithms ID | Context ID | Input
   Hash       :=  Hash( Expand( Hash Input ) )
   KHI        :=  Prefix | Encode_n( Hash )

In the proposed syntax, "algorithms ID" identifies the hash function,
the expand function, and the encode_n function. It may also identify a
particular syntax for the Input data, e.g. whether some type of
certificate is expected. 

-- 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 09:21:39 +0200

Christian,

>> We would appreciate very much feedback from members of the
>> IPv6 WG on this internet draft.
>
> "statistically unique identifiers" that are derived from some
> kind of cryptographic ID.

Thanks for your support!

> However, I have a problem with the specified syntax:
>
>    Input      :=  any bitstring
> This syntax includes a static reference to the SHA1 hash
> function and to the "encode_n" extraction function.

Yes, that is intentional.  See Security Considerations:

    As of today, SHA1 applied in conjunction with a proper expansion
    function of the hash input is considered as satisfying the second-
    preimage resistance requirement [I-D.hoffman-hash-attacks].  Hash
    output of at least 100 bits, but preferably up to 120 bits, is
    considered to have a low enough probability of collisions.

> As a general rule, hard coding a specific cryptographic algorithm
> in a standard is a very bad idea. In fact, SHA1 is already suspect.
> The syntax should allow for an identification of the algorithm as
> part of the "hash input".

I violently agree with your general rule.  We explicitly considered
this while writing the draft; see the Security Considerations section:

    All mechanism using KHIs MUST use exactly the same mechanism for
    generating a KHI from the input bitstring.  Allowing different
    mechanisms, without explicitly encoding the mechanism in the KHI
    itself, would allow so called bidding down attacks.  That is, if
    multiple different hash functions were allowed in constructing KHIs
    in a given shared name space, and if one of the hash functions  
became
    insecure, that would allow attacks against even those KHIs that had
    been constructed using with the other, still secure hash functions.

Do you find that clear enough or should we add an example attack
there?

Taking a step back, we have a conflict of interest here:  preserving
as many bits as possible for the hash, and encoding the hash method
to the KHI.  In Section 5, Design Choices, we write:

    Additionally, due to security considerations, the present design
    REQUIRES that the hash function used in constructing KHIs is
    constant; see Section 6.

Maybe we aren't clear enough there?

> particular syntax for the Input data, e.g. whether some type of

Unfortunately that does not work.  The Algorithm ID would need to
be in the final KHI output:

    Input      :=  any bitstring
    Hash Input :=  Context ID | Input
    Hash       :=  Hash( Expand( Hash Input ) )
    KHI        :=  Prefix | Algorithm ID | Encode_n( Hash )

In a way, we already implicitly state that, by writing:

    Consequently, the suggested method to react to the hash result
    becoming too short due to increased computational power or the used
    hash function becoming insecure due to advances in cryptology is to
    allocate a new prefix and cease to use the present one.

Maybe that should be clarified?

--Pekka Nikander

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Sep 2005 17:53:34 +0200

In your previous mail you wrote:

   cryptographic ID.

=> thanks

      Input      :=  any bitstring
   
   This syntax includes a static reference to the SHA1 hash function and to
   the "encode_n" extraction function. As a general rule, hard coding a
   specific cryptographic algorithm in a standard is a very bad idea. In
   fact, SHA1 is already suspect.

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

Thanks

[email-masked]