> I guess your assumption is that CGA is valid only in the local link so any > other nodes are capable of playing in between, like playing MITM or like > Proxy NDP, etc. To answer your concern, I confirm that CGA-TSIG is an > application layer protocol, dissimilar to the original CGA, and that the > node directly makes use of TCP or UDP to send messages to the DNS server or > other nodes. This means that CGA-TSIG options constitute a payload within > the TCP message which is signed by the originator. There is thus a binding > between the originator IP address and the public key of the signer so this > approach works and avoids MITM attacks by providing data integrity.
The main value of CGA is that it encodes a hash of a public key in the least significant 64 bits of an IP address. You propose to use this property to simplify the configuration of DNS TSIG. To quote your draft, "the current problem with using TSIG is that manual processing is required in order to generate and exchange the shared secrets." The default signature process of DNS-TSIG is an MD5 MAC protected by a shared secret. You propose to replace that by a public signature based the same public key used to generate the IPv6 CGA address, and then add parameters in TSIG to facilitate the verification of the linkage of public key to IPv6 address according to the CGA algorithms. The security of your approach relies on the fact that "the resolver already knows the IPv6 address of the server." That is, the only "secure" configuration needed at the resolver is the CGA IPv6 address of the server. This configuration is critical, because if the IPv6 address can be spoofed, then man in the middle attacks become possible. If we expect to provide secure updates, we will need to also assume that "the server already knows the IPv6 address of the resolver." More precisely, the server would need to maintain the list of IPv6 CGA addresses that are authorized to send updates of records for a given DNS names. Your claim is that configuring the CGA IPv6 address of the servers on the resolvers, and configuring the CGA IPv6 addresses of the authorized resolvers on the server, is simpler than configuring shared secrets on both the servers and the resolvers. I am not sure that this is true in practice. The CGA addresses in your design are used as the authentic signature of an authorized public key. As such, they will need the same level of protection as for example a "key ring" in PGP. If one can securely configure these addresses, one could probably just as well configure a shared secret. Using IPv6 addresses as "trusted key hashes" introduces serious life time issues. IP addresses typically have a shorter life time than the trust relation between a server and a resolver. Making IP addresses the key to security introduces serious complexity in the IP address update process. Your draft proposes some ways to do that, but the whole issue screams "administrative nightmare." It seems that the bulk of the administrative gains in your proposal come from a shift from shared secrets to public keys in TSIG. The transactions end up being protected by the public keys of the servers and resolvers. This may be a valid tradeoff, which could certainly be debated in the DNS working group. However, IPv6 CGA would be just one way to introduce public keys in TSIG. Two alternative come to mind, using TLSA to negotiate a secure DNS transport, and if you really want to use CGA, using CGA in conjunction with TKEY to negotiate the TSIG secrets. -- Christian Huitema _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
