Re: [Hipsec] clarification on HIT Suite IDs

[Julien Laganier <[e-mail]>]

On Thu, Sep 25, 2014 at 6:27 AM, Rene Hummen
<[e-mail]> wrote:
>
> Separating the OGA ID from the HIT suite ID certainly has its advantages regarding the small OGA ID space. However, it also has implications on HIPv2 crypto-agility. For example, how should the Initiator select the destination HIT if it receives multiple Responder HITs from DNS but only supports ECDSA?

I don't see how this (an initiator having to select a HIT out of a set
of HITs generated with different OGA IDs) would be impacted by
decoupling or not the OGA ID from the HIT suite ID. Irrespective of
the decoupling, an initiator that receives a set of HITs for a
responder has to select one for which it supports the OGA ID.

> Plus, end-hosts would have to support multiple hash functions to cater to a situation where the HIP hash function does not match the hash function indicated by the OGA ID (which admittedly only is a minor issue for Internet hosts).

This isn't a bug, it's a feature - hash agility.

> So, I propose to _not_ make any major modifications at this point.

I am not feeling strongly either way; from my perspective it is fine
to worry about the need for more hash functions when the need arise
which isn't the case now.

(I was just trying to make sense of the seemingly contradictory
decision to tie the burn rates of the small OGA ID space to the larger
HIP suite ID space, where the HIP suite ID space is presumably made
larger to increase future security, at the cost of shrinking the hash
output which to me decreases security.)

Regardless, I think that the text talking about using more bits of the
ORCHIDs to encode a HIP suite ID should be removed as this is not
supported by the ORCHID generation scheme (and would IMHO be a bad
thing to do, but that is beyond the point.)

--julien