Marcelo, given that the registry entries are simply pointers to more detailed RFCs, yes, I do agree that the modifier length should be defined in those RFCs.
Nonetheless, I think that CGA implementors should be prepared for the possible change in the modifier length by some text in your and Jari's draft. Best, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ marcelo bagnulo braun wrote: >>> i don't have a problem with including a section with this. >>> >>> does anyone else has an opinion on this? Jari? >>> >>> basically the additional text would to state that: >>> - since there are few sec values, it may be needed to reuse sec values >>> - this is a last resource option, since it may affect interoperation >>> - a long time is required between the deprecation of the old value and >>> the reassignment in order to prevent misinterpretation of the value by >>> old implementations >>> - this may affect interoperation (if an old implementation receives a >>> CGA generated with the new meaning of the sec value, it will fail) >>> - by no means an implementation should support both meaning of the Sec >>> value, since it may lead to downgrading attacks, >>> >>> anything else needed in this section? >> This seems sufficient IMO. >> > > ok, i will wait for additional comments in this topic, and if no > opposition i will include some text in the next version > >>>>>> (2) Wouldn't the length of the modifier have to be defined as part >>>>>> of the CGA SEC registry, too? >>>>>> >>>>>> If we define the number of leading zero bits for Hash2, say N, as >>>>>> part of the registry, we are no longer bound to the limit of 16 * >>>>>> (23 - 1) = 112 bits which the 3-bit Sec parameter provides. >>>>>> >>>>>> However, the length of the modifier should be at least as long as N >>>>>> plus a certain number of bits for location privacy. Since this >>>>>> may, at some future time, exceed the limit of 112 bits, it may be >>>>>> good to define the modifier length as part of the IANA registry, >>>>>> too. >>>>> I think this is a good point, indeed >>>>> >>>>> However, I am not sure this needs to be encoded in the address >>>>> itself >>>>> i.e. in the sec value itself. I mean the only reason to encode >>>>> information in the address itself AFAICS is to prevent downgrading >>>>> atttacks, agree? >>>> I wasn't saying that the length of the modifier needs to be encoded >>>> into >>>> the CGA, but it should rather be defined as part of the registry >>>> entry. >>> You mean like additional information... >> Yes. >> >>> I don't know... >>> >>> i guess that if a new sec value is assigned, the details will need to >>> be defined in a RFC so i would say that the RFC would be right place >>> to >>> describe all the related information, including the modifier length >>> for >>> this particular sec value... i mean, as you mention, current 128 bit >>> modifier seems to be good enough for our needs now... >>> >>> Summarizing, i don't have a strong opinion on this neither, but i >>> think >>> it would be easier/simpler to store this information in the associated >>> spec and reduce to the minimum the information contained in the >>> registry itself. >>> >>> does anyone else has an opinion? >> Hmm, the necessary length of the modifier follows directly from the >> number of leading zeros for Hash2. Since this number of zeros is >> defined as part of the registry entry, > > this is not the case, actually > > The registry only contains the name, the sec value and the RFC where > the sec value usage is defined > > the number of zeros in the hash2 will also be defined in the RFC that > defines the sec value usage > > that is why i suggest to define the modifier length in the RFc that > defines the SEC value also > >> the registry entry also seems to >> be the right place to define the modifier length. >> >> Adding more modifier bits to the CGA Parameters data structure in the >> form of a variable-length extension field, as you mentioned, would also >> be a viable option, because the MN could then decide for itself how >> many >> random bits it needs. > >> BTW, will there /always/ be an RFC for each new registry entry? >> > > yes, the IANA considerations states > > "future assignments are to be made through Standards Action [2]." > > thanks, marcelo > > >> Bye, >> - Christian >> >> -- >> Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) >> www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
