Re: [Hipsec] Antwort: Re: clarification on HIT Suite IDs

[Julien Laganier <[e-mail]>]

Hi Tom,

FWIW your proposal looks good to me.

--julien

On Mon, Sep 29, 2014 at 10:06 AM, Tom Henderson <[e-mail]> wrote:
> On 09/29/2014 09:20 AM, [e-mail] wrote:
>>
>> Hello,
>>
>> I'd like to confirm some of your statements. The thought was really to
>> show both options a) reuse of OGAs and b) what could happen if we need
>> more bits. However, the wording and the current set of IDs was chosen so
>> that it discourages the use of more IDs at the same time so the option
>> to take more bits from the OGA was really just a last resort. Nothing
>> anybody would really want.
>>
>> See my comments below.
>>
>>
>>
>>
>> Von: Francis Dupont <[e-mail]>
>> An: Tom Henderson <[e-mail]>,
>> Kopie: HIP <[e-mail]>, Francis Dupont <[e-mail]>,
>> [e-mail]
>> Datum: 26.09.2014 12:39
>> Betreff: Re: [Hipsec] clarification on HIT Suite IDs
>> Gesendet von: "Hipsec" <[e-mail]>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Tom Henderson writes:
>>  >        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.
>>
>> => yes, there is a long discussion in RFC 7343 about this tradeoff.
>>
>>  > which implied to me that the HIT suite ID may in the future consume
>> more
>>  > bits presently allocated to hash.
>>
>> => the fact the problem could exist doesn't mean it will exist...
>>
>> TH=> This was just to cover all options. It is not a desired or intended
>> action.
>
>
> There is discussion of this in the IANA considerations section; perhaps this
> could be modified as follows:
>
> Old text:
>
>       If 16 Suite IDs prove insufficient and
>       more HIT Suite IDs are needed concurrently, more bits can be used
>       for the HIT Suite ID by using one HIT Suite ID (0) to indicate
>       that more bits should be used.  The HIT_SUITE_LIST parameter
>       already supports 8-bit HIT Suite IDs, should longer IDs be needed.
>       Possible extensions of the HIT Suite ID space to accommodate eight
>       bits and new HIT Suite IDs are defined through IETF Review.
>
> New text:
>
>       If 15 Suite IDs (the zero value is initially reserved) prove
>       to be insufficient and
>       more HIT Suite IDs are needed concurrently, more bits can be used
>       for the HIT Suite ID by using one HIT Suite ID (0) to indicate
>       that more bits should be used.  The HIT_SUITE_LIST parameter
>       already supports 8-bit HIT Suite IDs, should longer IDs be needed.
>       However, RFC 7343 does not presently support such an extension,
>       and the rollover approach described in Appendix E is suggested to
>       be tried first.
>       Possible extensions of the HIT Suite ID space to accommodate eight
>       bits and new HIT Suite IDs are defined through IETF Review.
>
>
>
>>
>>  > > So there is nothing very clear about what will happen if one will
>> need
>>  > > more than 15 HIT Suite-IDs... BTW according to appendix E I should
>> add
>>  > > "at the same time" (appendix E proposes to reuse values, making
>> unlikely
>>  > > to really need more than 15 values).
>>  >
>>  > I'm not sure where you are proposing to add the clause; can you point
>>  > out the sentence?
>>
>> => one will need more than 15 HIT Suite-IDs ->
>> one will need more than 15 HIT Suite-IDs at the same time
>>
>> TH=> Exactly. The intention is to reuse the HIT Suite IDs once they are
>> reasonably out of use. Appendix E describes this rollover.
>
>
> So for this proposal by Francis, we would change Appendix E text from:
>
>    Since
>    the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID
>    0 is reserved) to be used in parallel, phased-out HIT Suites must be
>    reused at some point.  In such a case, there will be a rollover of
>
> to:
>
>    Since
>    the 4-bit OGA field only permits 15 HIT Suites to be used at the
>    same time (the HIT Suite with ID 0 is reserved), phased-out HIT
>    Suites must be
>    reused at some point.  In such a case, there will be a rollover of
>
>>
>>  > > => no, the current choice makes more sense with the HIT Suite-IDs
>>  > > from OGAs. But it is a matter of taste for sure...
>>  >
>>  > 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).
>>
>> => clearly the current plan is the first (reuse 4 bit values).
>> The second is just a provision in the case the first fails.
>>
>> TH=> Yes. I can confirm this.
>>
>>  > 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.
>>
>> => perhaps it was considered as too optimistic? BTW I have no idea
>> about the future need in new values in the HIT_SUITE_ID / OGA space
>> (but does somebody already have one?)
>>
>> TH=> I am fine with not specifying the extension of the ID but to leave
>> 0 as reserved instead.
>
>
> Julien suggested that if we consider non-zero bits as an error at the
> receiver, it may facilitate use of the four non-zero high-order bits in
> future extensions.
>
> in 5.2.10, it says:
>
>                     The four
>                     lower-order bits are reserved and set to 0 and
>                     ignored by the receiver.
>
> The proposal would be to change this to:
>
>                     The four
>                     lower-order bits are reserved and set to 0 by
>                     the sender.   The reception of an ID with
>                     the four lower-order bits not set to 0 should be
>                     considered as an error that MAY result in a
>                     NOTIFICATION of type UNSUPPORTED_HIT_SUITE.
>
> Any comments/concerns with this potential change?
>
>>
>>  > 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.
>>
>> => it is a question for the hipsec mailing list (I subscribed to it
>> but from my personal e-mail).
>>
>> TH=> Moving the table to 5.2.10 is fine from my perspective.
>
>
> I tend to prefer this; I will work up a proposal for this.
>
> - Tom
>
>