Julien, responses inline below.
On 09/23/2014 12:37 PM, Julien Laganier wrote:
Hi Tom,
Please see inline.
On Tue, Sep 23, 2014 at 10:39 AM, Tom Henderson <[email protected]> wrote:
Hi Julien,
I agree generally with your recommendations but I have a modified proposal
(below):
On 09/23/2014 07:49 AM, Julien Laganier wrote:
<snip>
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.
What I think is still lacking in the draft is a clear distinction between
the OGA ID and the HIT Suite ID, and perhaps some clearer wording that the
ID field in the HIT_SUITE_LIST is not yet another parameter needing a
registry.
HIT Suite IDs are a combination of hash function, HMAC, and signature
algorithm(s). Francis stated that they are an extension of (or derived
from) the OGA ID. The HIT_SUITE_LIST IDs are specific eight-bit encodings
of the HIT Suite ID values.
I may be lacking the background behind tying the OGA ID to the HIT
suite ID, but IMHO it makes little sense to tie an identifier for a
combination of hash, HMAC, and signature (the HIT Suite ID), with that
of the identifier for a hash function (the OGA ID), especially when
the ID space for the latter is of such a small size.
It implies that if we wanted to create a new HIT suite that just
changes the signature algorithm, because the hash function in use is
still perfectly good, we in effect burn one OGA ID in the small
15-number space for no extra hash agility w.r.t ORCHID. To me it seems
like a bad thing to do.
Why can't the HIP specification creates a HIP registry for its OGA
ID, and allocate value 1, 2, and 3 to the OGA SHA256, SHA384 and SHA1
on one hand, and on the other hand define a HIP registry for the HIT
suite, and allocate ID 1, 2 and 3 as follows:
HIT Suite
RESERVED 0
RSA,DSA/SHA-256/OGAID1 1
ECDSA/SHA-384/OGAID2 2
ECDSA_LOW/SHA-1/OGAID3 3
This decouples the burn rate for the HIT suites from that of the OGA
ID (small) space, thus making it possible to define in the future HIT
suite 4 with ECDSA/SHA-512 but still OGAID1....
IMHO the above is better than what I proposed, if the WG is willing to
make this kind of a change at this point.
Perhaps we should ask at this point for other WG opinions on whether the
above decoupling is acceptable?
Accordingly, would you agree to a modification to your proposal, as follows?
The ID field in the HIT_SUITE_LIST is an eight-bit field that
encodes a HIT Suite ID value in its higher-order four bits,
leaving the lower-order four bits reserved. The encoding is
a measure to allow for possibly larger HIT Suite IDs in the
future, although such expansion is outside the scope of this
document. The lower-order four bits of the ID field are set
to zero by the sender and ignored by the receiver.
The HIT Suite IDs are an expansion of the OGA IDs that denote
which hash function corresponds to a given HIT. The OGA ID
encodes, in four bits, the value of the HIT Suite ID that
corresponds to the hash function (and other algorithms) in use.
A registry for the OGA ID is not separately established since
the values are aligned with those of the HIT Suite ID.
The four-bit OGA ID field only permits 15 HIT Suite IDs
(the HIT Suite ID with value 0 is reserved) to be used at
the same time. If 15 Suite IDs prove to be insufficient,
future documents will specify how additional values can
be accommodated.
If a receiver ignores the low order four bits of the suite ID field,
if in the future we decide to use the remaining low order four bits,
won't they be required to be used with the reserved value zero for the
4 high order bits?
That would limit the HIP Suite ID to a total of 31 legitimate values
instead of the full 255 available. Shouldn't we rather have a receiver
treat the low order bits not set to zero as an error instead?
I just suggested that handling based on the traditional way of
specifying reserved bits (be liberal in what you accept...). But I
agree with you that there is a difference here with respect to the
existing non-reserved values, so thank you for catching this. I propose
to amend the above by deleting "and ignored by the receiver". We could
go further by explicitly stating a response if the bits are set, or just
leave it as an implicit "Parameter Problem" case just as if a value
outside of 1,2 or 3 were received.
- Tom
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
