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

[[e-mail]]

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.

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

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

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



Best regards,

Tobias



DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.