Subject: [Hipsec] HIP needs hash agility

From: Robert Moskowitz <[email-masked]>
Date: Mon, 30 Mar 2009 17:56:04 -0400

One item that is a MUST to address in HIP is adding hash agility.  This
is specifically called out in the IESG comments in RFC5201.  I doubt if
there is anyone here that feels otherwise, but we need to work out some
requirements.

Hash agility SHOULD include HIT generation.  Even if analysis shows that
today's class of attacks on SHA-1 do not affect HIT generation does not
mean this will always be the case.

Hash agility MUST NOT added to that HIP base exchange.  That is, in
dealing with say downgrade attacks, the HIP exchange MUST NOT be
increased from its current 4 packets.  It is ALLOWed to change the state
machine as needed in adding Hash agility.

The hash used to generate the HIT SHOULD be used to protect the HIP base
exchange.  KISS.

HITs in ACLs SHOULD be considered in adding Hash agility (should you be
able to tell by looking at an ACL that a HIT uses a hash that you no
longer support).

Adding Hash agility MAY result in reving the version number in HIP.

What else is needed for a design for hash agility?

=============================================

Here is my 1st serious thought on Hash agility:  We alter the content of
the HI to be not just the PK pair and the algorithm (plus parameters)
used, but also the Hash for HIT/Base exchange.  The only question would
be is it always just ONE hash, or can it be a set?