Hi, Julien, I still insist SEND hash algorithm should be independent from CGA hash algorithm. There are some scenarios that CGA option is not necessary and SEND Signature is needed. In these cases, define SEND hash algorithm should be the same with CGA hash algorithm does not make sense. For example, according to RFC3971, "Router Advertisement, and Redirect messages MUST contain the RSA Signature option", but CGA option is not mandate.
One more point, actually there are two hash algorithms within SEND: the hash algorithm of Key Hash and the hash algorithm of Digital Signature. The hash algorithm of Digital Signature is bound to the Signature algorithm. So far, RSASSA-PKCS1-v1_5 signature algorithm has only two hash algorithms: MD5 and SHA-1. It means if CGA uses other hash algorithm, such as SHA-256, HA-KH may be able to adopt the same hash algorithm; HA-DS is NOT able to adopt the same hash algorithm at all. Besides the above, different algorithms could be useful for future uses and testing purposes. While our whole support for hash agility is future-oriented (current SEND or CGA is not affected by the current attacks), we should take the future usage into account. Best regards, Sheng JIANG, Ph.D. IP Research Department, Networking Research Department, Network Product Line, Huawei Technologies Co. Ltd. *-----Original Message----- *From: julien laganier [mailto:[EMAIL PROTECTED] On *Behalf Of Julien Laganier *Sent: Thursday, July 03, 2008 5:19 PM *To: [email protected]; Sheng Jiang; Suresh Krishnan *Cc: [EMAIL PROTECTED] *Subject: Re: [CGA-EXT] Hash Agility in SEND (Was: new version *of "Send Hash Threat Analysis") * *Hi Suresh and Sheng, * *On Thursday 03 July 2008, Sheng Jiang wrote: *> *> I can agree with you under the circumstance that SEND uses CGA. But *> SEND does not depend on CGA. There are many scenarios the CGA option *> may unattended. Therefore, the hash function and its description *> option in SEND must be INDEPENDENT from CGA hash function. It may *> happen to be the same hash function with CGA hash function or not. * *On Thursday 03 July 2008, Suresh Krishnan wrote: *> *> I agree with you conceptually, but there might be a point in time *> (near future) where SEND may be used without CGAs. And hence *we cannot *> just state "use the same hash function as CGA". With this in *mind, do *> you agree with us? * *Two points here: * *- the current SEND specification does depend on CGA, and CSI *is not chartered to extend SEND to support use non-CGAs IP addresses. * *- we do not necessarily need to use CGAs with SEND to rely on *RFC4982 hash algorithm types in SEND. It's possible to define *another format of addresses (e.g. SNCGA - SEND *Non-Cryptographically Generated Addresses) that has three bits *reserved in the IID to encode RFC4982 SEC parameter encoding *the hash algorithm to be used with SEND, while other bits in *the IID are chosen freely. * *--julien * *On Wednesday 02 July 2008, Julien Laganier wrote: *> Sheng, *> *> It seems you agree using different hash functions for SEND and CGA *> doesn't improve security. *> *> Using the same hash functions for SEND and CGA does provide *the useful *> security feature that the hash function is encoded in the *address (via *> RFC4982) and thus no bidding down attacks are possible. *> *> Since using a Hash algorithm option in the SEND protocol does not *> provide any security feature and does not protect against *bidding down *> attacks leading to use of a broken hash function in SEND, it does *> harm. *> *> Thus it's my opinion that we shall specify that SEND use the *same hash *> function than that of the CGA. *> *> --julien *> *> On Wednesday 02 July 2008, Sheng Jiang wrote: *> > Hi, Julien, *> > *> > What you describe is exactly collisional public-private key pair. *> > You find another key pair that just happens to match the *result from *> > key pair 1. You break one of the two assumptions for hash function *> > [rfc4270]. Yes, in your case, multiple hash functions does *not help *> > and "the system can't be stronger than the weakest of its *> > components". *> > *> > However, even so, it does not means we should forbid or *restrict the *> > usage of multiple hash function. The second stronger hash function *> > does not do any harm in your case and may help when we face other *> > kind of threats. *> > *> > Best regards, *> > *> > Sheng JIANG, Ph.D. *> > *> > IP Research Department, Networking Research Department, Network *> > Product Line, Huawei Technologies Co. Ltd. *> > *> > *> > *-----Original Message----- *> > *From: julien laganier [mailto:[EMAIL PROTECTED] *On *Behalf *> > Of Julien Laganier *> > *Sent: Wednesday, July 02, 2008 8:28 PM *> > *To: [email protected]; Sheng Jiang *> > *Cc: [EMAIL PROTECTED] *> > *Subject: Re: [CGA-EXT] Hash Agility in SEND (Was: new version *of *> > "Send Hash Threat Analysis") *> > * *> > *Sheng, *> > * *> > *I am not talking about finding a collisional public-private *key *> > pair, whatever that is. *> > * *> > *I'm talking about a CGA hash function with broken pre-image *> > resistance. * *Given a CGA CGA1 generated (via the hash function) *> > from a *public-private key pair PK1/SK1, if can find a preimage to *> > the *CGA1, I can extract from the preimage another public-private *> > *key pair PK2/SK2 that yields the same CGA CGA1, and thus I can *> > *impersonate that CGA CGA1 by signing messages with the *> > *public-private key pair PK2/SK2. *> > * *> > *There's no need to break anything in the SEND specification, *> > *neither the digital signature algorithm, or the hashes. I *simply *> > break the hash function used for CGA generation. *> > * *> > *--julien *> > * *> > *On Wednesday 02 July 2008, Sheng Jiang wrote: *> > *> Hi, Julien, *> > *> *> > *> Your example is correct. However, it is misleading. You were *> > talking *> about you have found a collisional public-private key *> > pair. In that *> case, no matter how strong the hash *algorithms are, *> > you can *break the *> whole security system. Our *assumption here is: *> > based on a collision *> free public-private key pair, whether one *> > hash algorithm with two *> results or two hash algorithms with two *> > results are stronger. My *> choice is the latter. *> > *> *> > *> Best regards, *> > *> *> > *> Sheng JIANG, Ph.D. *> > *> *> > *> IP Research Department, Networking Research Department, Network *> > *> Product Line, Huawei Technologies Co. Ltd. *> > *> *> > *> *> > *> *-----Original Message----- *> > *> *From: julien laganier [mailto:[EMAIL PROTECTED] On *> > *Behalf *> Of Julien Laganier *> *Sent: Wednesday, July 02, 2008 *> > 6:17 PM *> *To: Sheng Jiang *> *Cc: [email protected]; *> > [EMAIL PROTECTED] *> *Subject: Re: *> > [CGA-EXT] Hash Agility in SEND (Was: new version *of *> "Send Hash *> > Threat Analysis") *> * *> *Hi Sheng, *> * *> *If I can generate a *> > public-private key pair that yields an **arbitrary *> CGA (attack *> > against your A below), then I can *impersonate *that CGA's **> owner *> > by simply signing with that *public-private key pair *> > *-- no need *> > *> to break the digital *signature algorithm (your B). *> > *> * *> > *> *--julien *> > *> * *> > *> *On Wednesday 02 July 2008, Sheng Jiang wrote: *> > *> *> Hi, Julien, *> > *> *> *> > *> *> I can agree with you that SEND and CGA may use the same hash *> > *> *function. *> > *> *> Actually, in the current protocol, they do use the *same sha-1. *> > *> *> However, we should also allow/support that they use *different *> > *> *> algorithms through we may not recommended it. *> > *> *> *> > *> *> I don't agree with your statement "the security of the *> > *resulting *> *> system can't be stronger than the weakest of its *> > components". *> > *> *> Actually, in many cases, it may be opposite: the *strongest *> *> > component *> decides the attacker's difficulty. Let's put *it into a *> > *> concrete *> example here, say, SEND uses algorithm B that *> > stronger *> than *algorithm *> A in CGA and there is an *attacker who *> > can break *> algorithm A *but not B. *> > *> *> Then, the attacker may produce a faked CGA option, *but because *> > he *> *> cannot produce a faked SEND signature option that use *> > **algorithm B, *> he *> can still get through the SEND *verification. *> > When multiple *> *algorithms *> are use together, the attacker has *> > to break all *> algorithms to break *> the security system. *> > *> *> *> > *> *> Best regards, *> > *> *> *> > *> *> Sheng *> > *> *> *> > *> *> *-----Original Message----- *> > *> *> *From: [EMAIL PROTECTED] *> *> *> > *[mailto:[EMAIL PROTECTED] On Behalf Of Julien **Laganier *> *> > *> *Sent: Tuesday, July 01, 2008 10:24 PM *> *To: [EMAIL PROTECTED]; *> > *> [EMAIL PROTECTED] *> > *> *> *Subject: [CGA-EXT] Hash Agility in SEND (Was: new *version of *> > *> *"Send *> Hash Threat Analysis") *> * *> * *> *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? *> > *> *> * *> > *> *> *--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 *> > * *> > * *> > * *> *> _______________________________________________ *> 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
