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.
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?
For clarification, it might be a good idea to add some text that says
more explicitly that the OGA ID is formed by taking the four high-order
bits of the ID found in the HIT_SUITE_LIST, and by making the table read
something like:
=> it is trade-off between defining OGAs from HIT Suite-IDs vs.
defining HIT Suite-IDs from OGAs. The second was chosen...
However, I wonder whether the better choice would be to simplify the
current encodings and make it a right-aligned field, keep the value 0 as
reserved, and leave future growth to future updates. The same kind of
growth could be accommodated if the (future) extended OGA ID were
encoded with the nibbles swapped.
=> 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). 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.
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.
- Tom
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
