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... > > 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 > > => 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. > 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?) > 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). Regards Francis Dupont <[email protected]> _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
