Re: [Hipsec] clarification on HIT Suite IDs

[Julien Laganier <[e-mail]>]

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