Re: [Hipsec] clarification on HIT Suite IDs

[Rene Hummen <[e-mail]>]

On 25 Sep 2014, at 06:21, Julien Laganier <[e-mail]> wrote:
> Hi Tom,
> 
> Please see inline
> 
> On Tue, Sep 23, 2014 at 12:54 PM, Tom Henderson <[e-mail]> wrote:
>> Julien, responses inline below.
>> 
> 
> <cutting thru a bit>
> 
>>> I may be lacking the background behind tying the OGA ID to the HIT
>>> suite ID, but IMHO it makes little sense to tie an identifier for a
>>> combination of hash, HMAC, and signature (the HIT Suite ID), with that
>>> of the identifier for a hash function (the OGA ID), especially when
>>> the ID space for the latter is of such a small size.
>>> 
>>> It implies that if we wanted to create a new HIT suite that just
>>> changes the signature algorithm, because the hash function in use is
>>> still perfectly good, we in effect burn one OGA ID in the small
>>> 15-number space for no extra hash agility w.r.t ORCHID. To me it seems
>>> like a bad thing to do.
>>> 
>>> Why can't the HIP specification  creates a HIP registry for its OGA
>>> ID, and allocate value 1, 2, and 3 to the OGA SHA256, SHA384 and SHA1
>>> on one hand, and on the other hand define a HIP registry for the HIT
>>> suite, and allocate ID 1, 2 and 3 as follows:
>>> 
>>>         HIT Suite
>>>         RESERVED                                            0
>>>         RSA,DSA/SHA-256/OGAID1                  1
>>>         ECDSA/SHA-384/OGAID2                      2
>>>         ECDSA_LOW/SHA-1/OGAID3               3
>>> 
>>> This decouples the burn rate for the HIT suites from that of the OGA
>>> ID (small) space, thus making it possible to define in the future HIT
>>> suite 4 with ECDSA/SHA-512 but still OGAID1....
>> 
>> 
>> IMHO the above is better than what I proposed, if the WG is willing to make
>> this kind of a change at this point.

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?

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

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

>> Perhaps we should ask at this point for other WG opinions on whether the
>> above decoupling is acceptable?
> 
> Yes we should.
> 
> But does silence implies consent? :)
> 
>>>> Accordingly, would you agree to a modification to your proposal, as
>>>> follows?
>>>> 
>>>>      The ID field in the HIT_SUITE_LIST is an eight-bit field that
>>>>      encodes a HIT Suite ID value in its higher-order four bits,
>>>>      leaving the lower-order four bits reserved.  The encoding is
>>>>      a measure to allow for possibly larger HIT Suite IDs in the
>>>>      future, although such expansion is outside the scope of this
>>>>      document.  The lower-order four bits of the ID field are set
>>>>      to zero by the sender and ignored by the receiver.
>>>> 
>>>>      The HIT Suite IDs are an expansion of the OGA IDs that denote
>>>>      which hash function corresponds to a given HIT.  The OGA ID
>>>>      encodes, in four bits, the value of the HIT Suite ID that
>>>>      corresponds to the hash function (and other algorithms) in use.
>>>>      A registry for the OGA ID is not separately established since
>>>>      the values are aligned with those of the HIT Suite ID.
>>>> 
>>>>      The four-bit OGA ID field only permits 15 HIT Suite IDs
>>>>      (the HIT Suite ID with value 0 is reserved) to be used at
>>>>      the same time.  If 15 Suite IDs prove to be insufficient,
>>>>      future documents will specify how additional values can
>>>>      be accommodated.
>>> 
>>> 
>>> If a receiver ignores the low order four bits of the suite ID field,
>>> if in the future we decide to use the remaining low order four bits,
>>> won't they be required to be used with the reserved value zero for the
>>> 4 high order bits?
>>> 
>>> That would limit the HIP Suite ID to a total of 31 legitimate values
>>> instead of the full 255 available. Shouldn't we rather have a receiver
>>> treat the low order bits not set to zero as an error instead?
>> 
>> 
>> I just suggested that handling based on the traditional way of specifying
>> reserved bits (be liberal in what you accept...).  But I agree with you that
>> there is a difference here with respect to the existing non-reserved values,
>> so thank you for catching this.  I propose to amend the above by deleting
>> "and ignored by the receiver".  We could go further by explicitly stating a
>> response if the bits are set, or just leave it as an implicit "Parameter
>> Problem" case just as if a value outside of 1,2 or 3 were received.
> 
> Having the receiver reply with a "parameter problem" when it receives
> a Suite ID value outside of the set of values it understands sounds
> good. For now that is 1, 2, and 3, but can be amended in the future.
> 
> --julien
> 
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: [phone]
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/