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

[Pekka Nikander <pekka.nikander at nomadiclab.com>]

Christian,

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

Thanks for your support!

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

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?

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

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


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------