In your previous mail you wrote: > > What changes from RFC 3972 to your draft in this high-level analysis? > > The difference between my draft and that of RFC 3972 is that I make use of > the public key in the IP address directly.
=> this is IMHO a bad idea because it limits the search space in the best case (i.e., not when the structure of the public key allows trivial attacks as in the RSA case) to 2**64. > Doing it the way I have explained > in my draft eliminates the need for the use of those SHAx steps because I > believe the use of those steps does not lend itself to improved security. => I strongly disagree: the use of those SHAx steps is the way to extend the search space and until SHAx pre-images are broken for the worst case (i.e., no attack better than brute force). > My > reason for this opinion is that RFC 3972 can only prevent DAD attacks and > not the other types of attacks. This attack can also be prevented by using > CGA if we add this extra verification step (that of the node checking the > public key of the sender to his own), otherwise RPKI would be used. This is > the same procedure as outlined in my draft. So the security of both depends > on the security of the public/ private keys. After a successful verification > (which could have resulted from a fast relay attack) the attacker's > link-layer address is included in a cache as a legitimate address, and if > routing is based on the link-layer address, then the node has no way of > knowing that it was just a replay attack. Otherwise, the use of RPKI, where > the node that has this IP address/or link layer is specified, would contain > this public key. This is why, in this case, the keys' security is very > important. => this seems to be replay attacks. RFC 3972 (CGAs) doesn't protect against replay but provides message (aka connectionless) integrity so any use of CGAs can add an anti-replay device (RFC 3971 (SEND) uses nonces and timestamps for anti-replay). BTW CGAs and SSASs are the same for this point. Regards francis.dup...@fdupont.fr PS: I don't say to put the public key in the address is intrinsically broken but it cannot be done this way. I suggest to look at Identity Based Cryptography (the SAAG could provide guidance). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
