Hi Marcelo! <snip>
>> (2) CGA implementations must not accept two different meanings of >> the same Sec value as this would introduce a possibility for >> downgrading attacks. Specifically, an attacker may be able to find >> a set of CGA parameters that produces a victim's CGA with a >> cryptographically weak algorithm, while the victim itself has >> previously generated the CGA with a cryptographically stronger >> algorithm. > > fully agree with this, however, not sure if we should include this in > the draft > > i mean, we have discussed this point while writing this version of > the draft and our conclusion was that an implementation that would do > this would be really bogus so it was not worth mentioning it in the > draft... i mean, i am not sure we need to describe how people should > not shoot themselves in the foot in various ways... Good point. Maybe the security considerations is a better place to discuss this. The security considerations should in any case discuss the issue of downbidding attacks IMO---basically saying that no downbidding threat exists---, so it could be briefly mentioned there that the inability to pursue a downbidding attack hinges on implementations not accepting two different meanings of the same Sec value. >> (3) Optimally, new CGA implementations should include an interface >> via which they can 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. > > i am not sure i understand this... i mean reassigning the Sec value > would result in a different implementation i.e. additional code for > the new hash function and so on, so i guess that more that a change > in the registry will be needed, but actual code is needed in the > stack. I see your point. That's correct. <snip> Take care, - 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
