Hey Marcelo, I agree with what you said about certificates and CGAs. For the Key Hash and Digital Signature, please see my questions below.
marcelo bagnulo braun wrote: >> 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 Right, this is SeND specific, but i see the Digital Signature field as a bigger issue then this field. The Key Hash field is not susceptible to the collision attacks, since attacker chooses both keys, right? Preimage attacks could be more useful, but are not feasible. But even in that case, if an attacker breaks key hash and produces signature with the new key, there is still CGA to deal with. Right? > >> 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 Why? AFAIU, the Digital Signature field is vulnerable to the collision attack. An attacker produces two colliding messages, underlays one of the messages to be signed with authorized keys (through CGAs), but uses another message afterwards. However, the prediction and production of the useful content of such two messages is just theoretically possible, since SeND message contains mostly human readable data. And as rfc4270 says, the structure of at least one of two messages is predefined. What am i missing here? >> 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 > Right, that is about flexibility, we should not expect from CA and host to use the same algorithm. It might be useful to give opportunity to define separate algorithm for certs, and use CGA algorithm for other hashes. CGAs are used for different purposes, but CGA hash threat analysis and hash agility is provided by the rfc4982, we should not bother with that, right? Ana _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
