Re: [Hipsec] clarification on HIT Suite IDs

[Julien Laganier <[e-mail]>]

Hi Tom,

Please see inline.

On Mon, Sep 22, 2014 at 10:34 PM, Tom Henderson <[e-mail]> wrote:
> On 09/22/2014 02:28 PM, Francis Dupont wrote:
>
>>>
>>> Basically, the draft is saying that if HIT Suite ID is zero, then this
>>> ORCHID encoding:
>>>
>>>    ORCHID     :=  Prefix | OGA ID | Encode_96( Hash )
>>>
>>> becomes instead:
>>>
>>>    ORCHID     :=  Prefix | HIT Suite ID | Encode_92( Hash )
>>>
>>> and the bits immediately after the Prefix are used also to identify the
>>> length of this OGA ID.  It seems to me that this could either be
>>> clarified further in the draft, or simplified.
>>
>>
>> => no, it doesn't say that: the current wording is:
>>
>>     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.  In that case, one of the
>>     16 values, zero, will be used to indicate that four additional bits
>>     of the ORCHID will be used to encode the HIT Suite ID.  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.
>
>
> Perhaps we can agree that it is ambiguous; elsewhere it also states:
>
>       For the time being, the HIT Suite uses only four bits because
>       these bits have to be carried in the HIT.  Using more bits for the
>       HIT Suite ID reduces the cryptographic strength of the HIT.
>
> which implied to me that the HIT suite ID may in the future consume more
> bits presently allocated to hash.

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.


(and that is beyond this discussion, but given that adding more suite
IDs presumably addresses a need for _increased_ security, it is
counter intuitive to already decide to achieve that by _reducing_ the
size of the encoded hash output, but I digress)

<snip>

> Perhaps we could start by trying to resolve whether the plan should be to
> reuse four-bit values if the space is eventually exceeded, or whether the
> HIT suite ID may grow in the future (and how that affects the ORCHID).
> Maybe we do not need to specify the plan in this draft; maybe we could just
> avoid the problem for now and just keep value 0 reserved and state that what
> to do when the HIT_SUITE_ID space is exhausted is for further study, with
> deprecated value reuse and expansion of the HIT Suite ID being two
> possibilities.

IMHO it is premature to plan for the ID space exhaustion while it has
not happened and we do not have an understanding of what will cause
the ID space to be exhausted (if it ever does.) E.g., if none of the
hash functions chosen in HIP suites provided enough security in 96
bits truncated output, will there be a new hash function that will? So
the discussion on contingency plan seems moot at this point in time.

Thus it seems keeping zero reserved is good enough for now.

> Another basic question I have is whether the table 11 in Appendix E should
> be merged with the unlabeled table at the end of 5.2.10 (and located in
> 5.2.10), and whether Appendix E text in general ought to be brought forward
> in the draft to section 3.2 and/or 5.2.10.

I think that makes sense since it is normative.

--julien