Hi all, just wondering if the decision was made for us, as RFC5201-bis was approved yesterday:
=== The IESG has approved the following document: - 'Host Identity Protocol Version 2 (HIPv2)' (draft-ietf-hip-rfc5201-bis-19.txt) as Proposed Standard This document is the product of the Host Identity Protocol Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ === BR René On 25 Sep 2014, at 06:21, Julien Laganier <[email protected]> wrote: > 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 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21426 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
