marcelo bagnulo braun wrote: >>>> (1) Since there are only 8 possible Sec values, wouldn't it make >>>> sense to recycle the semantics of these values over time? >>> yes, but my concern is about how much time do we need to start re >>> using an previously assigned value safely >> >> Keep a registry entry considered insecure deprecated as long as >> possible. Re-use it only when a new registry entry is needed, but all >> 8 >> available Sec values are occupied. In that event, re-use the oldest >> deprecated registry entry. > > or the less used entry i.e. suppose that one assignment was made that > was not successfull at all for any reasons (like IPv5 for instance)
Ok, although it might in general be difficult to decide which registry entry is used the least. <snip> >> Note that a CGA implementation that is hard-coded for a stale registry >> entry uses insecure/broken cryptographic functions anyway. This means >> that it does not matter that much if such an implementation falls back >> to standard IPv6 if it turns out that it is incompatible with a more >> up-to-date implementation at a peer. >> >>>> Along this line, we could deprecate registry entry 0 (SHA-1 + 0 >>>> leading zero bits in Hash2) today. >>> Are you proposing to do this now? I am not sure that at this point >>> the sec = 0 is unsafe... Do you have some information about specific >>> threats with this Sec= 0? >> I'm not saying there are existing threats for Sec=0. > > but then there is no point in deprecating it imho > I mean, as i see it, we need to deprecate an entry because it is no > longer safe to be used, not because there are stronger options... > agree? Yes. <snip> >>> So, i would preffer delaying the reassignemet of sec values as much >>> as possible, in particular, till we run out of sec values. Then we >>> could start reassigning the initiallly assigned values (or other >>> values that had prooved not to be widely implemented) >> This is what I was proposing in my email. >> >>> OTOH, i am not we need to do anything in the draft in order to >>> support this... I mean AFAICT is a matter of the registry >>> administration and we will need to deal with this when we run out of >>> Sec values, i guess... >> It would be good to specify the intent for re-use in the draft so that >> sophisticated CGA implementations could provide an interface via which >> they can be updated to registry updates. > > 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. >>>> (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, 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? 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
