Hi, 2008/7/1 Julien Laganier <[EMAIL PROTECTED]>: > > Hello Ana, CSI'ers, > > I think I disagree with the paragraph of the draft copied below my note. > > To me it seems OK to specify that SEND should use the same hash function > than CGA. Since they are used together to provide security, and since > the security of the resulting system can't be stronger than the weakest > of its components, the maximum level of security can be reached by > choosing mechanisms (hash functions in this case) with similar security > strength for both CGA and SEND. > > Improving the security level of only one of the component would not > increase the overall security of the system. > > Has anybody an opinion on the topic?
At first sight, I agree with you for NA/NS/RS messages when CGA option is used. Now, I must admit I have no opinion for RA messages when CGA option is used because, at least for me, the specifications are not enough clear for the moment (cf. http://www.ietf.org/mail-archive/web/cga-ext/current/msg00102.html). Cheers. JMC. > > --julien > >> 4. Support for the hash agility in SeND >> >> While all of analyzed hash functions in SeND are theoretically >> affected by recent collision attacks, these attacks indicate the >> possibility of future real-world attacks. In order to increase >> the future security of SeND, we suggest the support for the hash and >> algorithm agility in SeND. >> >> The most effective and secure would be to bind the hash function >> option with something that can not be changed at all, like >> [rfc4982] does for CGA - encoding the hash function information into >> addresses. But, there is no possibilty to do that in SeND. We could >> decide to use by default the same hash function in SeND as in CGA, >> but this solution is architecturally strange and it does not really >> increase the security since the difficulty for attackers remain to >> break one single hash function. Furthermore, it may even reduce the >> security level by providing more relevant information of the hash >> function. On the other side, the use of two different hash algorithms >> makes attacker's life harder. >> >> Another solution is to incorporate the hash function option into >> SeND message. By putting a new hash function option in SeND message >> before RSA Signature option, attacker will have to break both the >> signature and the hash input at the same time since the new option >> will be input field for the Digital Signature in RSA Signature >> option. However, we can not avoid a downgrade attack totally because >> peer might be using just ND and not SeND. A completely safe solution >> here does not exist. A new hash function option in SeND message is a >> reasonable and the best solution for the hash algorithm agility >> support in SeND. >> >> Each implementation SHOULD use different hash or signature >> algorithms for each of the relevant fields (Key Hash field, Digital >> Signature, PKIX signature algorithm). Since all algorithms are in >> different procedures, making them the same does not make those >> procedures simpler, but making them different complicates possible >> attacks. > > > On Tuesday 01 July 2008, Ana Kukec wrote: >> The new version of draft-kukec-csi-hash-threat is submitted. Comments >> are welcome! >> >> Filename: draft-kukec-csi-hash-threat >> Revision: 02 >> Title: SeND Hash Threat Analysis >> Creation_date: 2008-07-01 >> WG ID: Independent Submission >> Number_of_pages: 15 >> >> Abstract: >> This document analysis the use of hashes in SeND, possible threats >> and the impact of recent attacks on hash functions used by SeND. >> Current SeND specification [rfc3971] uses SHA-1 [sha-1] hash >> algorithm and PKIX certificates [rfc3280] and does not provide >> support for the hash algorithm agility. Based on previous analysis, >> this document suggests multiple hash support that should be included >> in the SeND update specification. >> >> >> 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
