Hi Marcelo, thanks for the feedback! Responses in-line.
>> (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. >> Specifically, if an old CGA SEC registry entry is found to be >> insecure, it could be deprecated for a certain (minimum) time, so >> that CGA implementations have time to migrate to a more secure >> combination of hash function and number of leading zero bits in >> Hash2. When there is need for a new combination, the oldest >> deprecated registry entry would eventually get replaced. > > agree but i would like to hear some comments about how long does this > process take. I mean, i guess that there are quite a few old > implementations that do not get upgraded and we would need to support > these. See above. We only re-use registry entries as a last resort. 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. Deprecating the value now would simply ensure that new CGA implementation default to a more secure hash function. >> Optimally, new CGA implementations should include an interface via >> which they could be updated to registry changes. But since such >> changes are expected to occur only at a very low frequency, it may >> just be sufficient to pre-configure CGA implementations. >> >> Erroneous use of an obsolete CGA SEC combination would not be >> dramatic: CGA verification would fail in the worst case and nodes >> would have to revert to unprotected IPv6 addresses. But note this >> would happen only if the obsolete CGA SEC combination was >> considered insecure anyway. > > I am not sure about this.... > > wouldn't this open the doors to downgrading attacks? I don't think so. See below. > I mean, suppose that an attacker wants to hijack a CGA e.g. in SeND. > suppose that the CGA being used contains a Sec parameter that has > been reasigned. We have the old parameters associated with the Sec > value and the new paramters suppose that the attacker can crack the > old paramters but not the new ones so, the attacker will send SeND > validation information using the old paramters and the receiver will > beleive that this is just an old implementation that has not been > upgraded, so the attack can succeed... We have to ensure that a CGA implementation does never accept two different parameter sets for the same Sec value. Only this would allow for downgrading attacks. > Now, the alternative would be to simply not accept the old paramter > information as valid, but this would break interoperation, hence we > need very long periods of time for changing reasigning a sec value. Right, the timeout periods have to be very long. But if we do not allow for re-use after such a long period, then we would eventually run out of registry entries. There are only 8 available. And note we must use the 8 Sec values to encode BOTH, a hash function and a number of leading zeros for Hash2. While the hash function may have to be replaced only very rarely, we may have to increase the number of leading zeros for Hash2 more frequently, requiring a new Sec value each time... > 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. The current CGA standard also includes the option of falling back to standard IPv6 in case the correspondent node does not support (or claims not to support) CGAs. >> (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. If we define the modifier length in the registry entry, then CGA verifiers can see how long the modifier field is when they recompute/verify a given CGA. I do agree that there is no possibility for downgrading in this case. > that is why we need to encode the hash function there. Yes. <snip> Alright, best regards, - 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
