Re: [Hipsec] clarification on HIT Suite IDs

[Tom Henderson <[e-mail]>]

Julien, responses inline below.

On 09/23/2014 12:37 PM, Julien Laganier wrote:
> Hi Tom,
>
> Please see inline.
>
> On Tue, Sep 23, 2014 at 10:39 AM, Tom Henderson <[e-mail]> wrote:
>> Hi Julien,
>>
>> I agree generally with your recommendations but I have a modified proposal
>> (below):
>>
>> On 09/23/2014 07:49 AM, Julien Laganier wrote:
>>
>> <snip>
>>>
>>>
>>> The statement about using more bits of the ORCHID to encode a HIT
>>> suite ID seems to be factually incorrect, or at least it isn't
>>> supported by the ORCHIDv2 generation scheme as published in RFC 7343.
>>>
>>> Since this document (5201-bis) doesn't seem to be the right place to
>>> specify (future) ORCHID generation (a revision of ORCHIDv2 would), I'd
>>> like to suggest that plans for future enhancements be removed from the
>>> paragraph, and to only keep text necessary to ensure future
>>> enhancements are not prevented. For this, reserving the value zero
>>> seems to be enough. (and Appendix E already has a discussion of OGA ID
>>> reuse for the purpose of ID space exhaustion).
>>>
>>> Accordingly, the paragraph would read:
>>>
>>>        The ID field in the HIT_SUITE_LIST is defined as eight-bit field as
>>>        opposed to the four-bit HIT Suite ID and OGA field in the ORCHID.
>>>        This difference is a measure to accommodate larger HIT Suite IDs if
>>>        the 16 available values prove insufficient.  Hence, the
>>>        current four-bit HIT Suite-IDs only use the four higher order bits
>>> in
>>>        the ID field.  Future documents may define the use of the four
>>> lower-
>>>        order bits in the ID field.
>>
>>
>> What I think is still lacking in the draft is a clear distinction between
>> the OGA ID and the HIT Suite ID, and perhaps some clearer wording that the
>> ID field in the HIT_SUITE_LIST is not yet another parameter needing a
>> registry.
>>
>> HIT Suite IDs are a combination of hash function, HMAC, and signature
>> algorithm(s).  Francis stated that they are an extension of (or derived
>> from) the OGA ID.  The HIT_SUITE_LIST IDs are specific eight-bit encodings
>> of the HIT Suite ID values.
>
> 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?

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

- Tom