Subject: [Hipsec] HIP needs hash agility

From: Robert Moskowitz <[email-masked]>
Date: Fri, 27 Mar 2009 17:29:07 -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?

---

From: Miika Komu <[email-masked]>
Date: Tue, 31 Mar 2009 10:59:06 +0300

Robert Moskowitz wrote:

Hi,

> What else is needed for a design for hash agility?

I think we are going to need a new version of ORCHID that tells the hash
version?

Below are some comments from Ken Rimey. We have also asked Julien about
the exact reason why the context id is incorporated in the hash input
(security?), but no response yet.

-------- Original Message --------
Subject: ORCHIDs
Date: Tue, 10 Mar 2009 21:07:33 +0200
From: Ken Rimey <[email-masked]>
To: ext Pekka Nikander <[email-masked]>
CC: [email-masked], [email-masked]

Pekka,

After talking it over with Samu and Miika, I'd like to offer some
feedback on ORCHIDs.

Instead of using

	Hash_function(Context ID | Input)

as the input to Encode_100(), it would be better to use

	Hash_function(Context ID) XOR Hash_function(Input)

I'll explain.

I am running an administratively decentralized lookup service (not a
DHT) that stores limited-size byte strings (up to 8K) with a limited
time-to-live (up to a week), indexed by principal-label pair.  (See
http://openlookup.net/.)  The arguments to a lookup are the public key
fingerprint and the label or its hash.  I also support querying with a
prefix of the public key fingerprint instead of the full fingerprint.

Samu would like to use this service to look up information about a
host identity (current address, public key, etc.) using a HIT instead
of my public key fingerprint.  The problem is that this would require
me to maintain an additional database index.

More generally, if people are going to want to be able to look up
information using ORCHIDs, it would seem that I will need to maintain
an additional database index for each context identifier of interest.
A lookup would involve providing a context identifier, an ORCHID, and
a label.

The intent of my proposed change is to enable the client to factor the
context identifier out of the ORCHID and provide the
context-independent public key hash instead -- 100 bits of it, that
is.  (The purpose of XORing with the hash of the context identifier
instead of the context identifier itself is to prevent the party
selecting the context identifier from trivially arranging for an
inter-context collision to occur.)

I want to encourage clients to provide the full public key fingerprint
and not just 100 bits of it, but I can handle both cases with just one
database B-tree index by adding a rotation by 30 bits to the hash
function so as to bring the middle 100 bits to the front.  That's not
pretty, however, so if there is no strong reason to use the middle 100
bits, I think it would be appropriate to additionally change the
ORCHID scheme to straightforwardly use the first 100 bits.  (I don't
know the original rationale for that choice.)

Comments?

Ken