On Thu, Sep 25, 2014 at 6:27 AM, Rene Hummen <[email protected]> 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 _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
