See my reply in lines. Sheng
----- Original Message ----- From: marcelo bagnulo braun <[EMAIL PROTECTED]> Date: Wednesday, September 10, 2008 9:00 am Subject: Re: [CGA-EXT] hash function agility supportin draft-kukec-csi-hash-threat-02 To: Ana Kukec <[EMAIL PROTECTED]> Cc: [email protected] > Ana Kukec escribió: > > Hi all, > > > > Just to summarize the possible options about encoding hash > algorithm:> > right thanks > > > a) Use the same hash algorithm as in CGA for all hashes. There is > no > > bidding down attack in that case. Different algorithms then CGA > > algorithm for other hashes does not increase security. > > > > right > actually, as someone suggested in the meeting, it is also possible > to > encode the hash function in the last 3 bits of the address, > irrespectivly the address is a CGA or not I am support to use the same hash algorithm while don't want to rule out the necessariness of a new hash algorithm option. There are some scenarios that CGA option is not necessary and SEND Signature is needed. For example, according to RFC3971, "Router Advertisement, and Redirect messages MUST contain the RSA Signature option", but CGA option is not mandate. In these cases, since no CGA hash algorithm be described, we do need a SeND option to describe the hash algorithm in SeND. > > b) Use the Hash Algorithm option to define different (or the > same?) > > algorithm for all hashes. It is vulnerable to the bidding down > attack, > > but provides flexibility, since in the future, SeND might be used > > without CGAs. > > > > > well, the scope of bidding down attacks in this case could be > limited by > admin configuration. I mean, if it is determined that a given hash > function is insecure, then hosts simply don't accept the hash > algorithm > any more and no bidding down attack is possible > > The problem is when two hash algorithms with different level of > security > must be accepted simultaneously, so during that period, the attack > will > be possible > > regards, marcelo > > > > > Any opinions? :-) > > > > Ana > > _______________________________________________ > > CGA-EXT mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/cga-ext > > > > > > _______________________________________________ > CGA-EXT mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cga-ext > _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
