Hi Ana, thanks for starting the disucssion on this.
see comments in-line Ana Kukec escribió: > Hi all, > > We didn't reach the consensus about how to support hash function > agility. We should try to reach the consensus, thus, i am sending the > summary of analysis, possible solutions for encoding the hash functions, > pros and cons. > > The uses of hashes are the following: > a) Digital signature in X.509 certificate. Attacker can produce the > false certificate with the same identity data and signature, and > different key. After that, he does not have to break any other hash > (CGA, key hash field, digital signature), just uses that new, > unauthorized key in the generation of mentioned fields. > right, but this is not send specific, since it affects X.509 certs in general. I don't think we should aim to solve this here imho we should use it as baseline to compare whatever solution we come up with > b) CGAs. The same as with certificate, it is enough just to break the > CGA, and use the false key in key hash field generation and for digital > signature signing. > same here CGA hash agility has already been addressed in a separate document, so i don't see the need to deal with it here as well With the defined CGA hash agility should be enough to deal with it, right? > c) Key hash field. Again the same thing. Attacker breaks the key hash > and does not have to break any other hash, cause he just uses the new > key for other fields generation. > i think this is the key issue to address here. This is seND specific and this is what we should aim to solve > d) Digital signature. Attacker could change some of the SeND message > fields. However the attack is probably just theoretically possible; in > practice it is hard to perform it since there are mostly human-readable > fields to be signed. Attacker does not need to break any other hash, the > hashed message can be signed with authorized key (if attacker manages to > change the message before the SeND node starts signing it). > > i am not sure about this one > The question is, do we need to provide opportunity to choose different > hash algorithms? If attacker attacks just one hash, he breaks the whole > chain. Thus, it is enough to define just one hash algorithm in the Hash > Algorithm option. > > but the problem is that we may end up conditioning other operations I mean, CGAs are used for several things, not only send, so we may not want to impose changing all the different protocols in chain. In addition, there are many parties involved, Certs are generated by the CA and CGAs are generated by the host itself, so it may not be a good idea to require that both are upgraded simultaneously I am not sure what would be the right way to go here Regards, marcelo > On the other hand, the possibility for configuring multiple hashes > provides additional flexibility. Additionally, we could support it > because of the possible future changes in SeND. > > What are your 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
