Hi Tom, Please see inline
On Tue, Sep 23, 2014 at 12:54 PM, Tom Henderson <[email protected]> wrote: > Julien, responses inline below. > <cutting thru a bit> >> 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? Yes we should. But does silence implies consent? :) >>> 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. Having the receiver reply with a "parameter problem" when it receives a Suite ID value outside of the set of values it understands sounds good. For now that is 1, 2, and 3, but can be amended in the future. --julien _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
