Hi , > On top of a preliminary Q&A at the dnsop/dnsext lists > (http://www.ietf.org/mail-archive/web/dnsop/current/msg11252.html) > here are a bit more detailed comments on the draft of mine. > > Overall, the advantage of this approach doesn't seem to be very convincing to > me: > - It's IPv6 only. While I'm a strong lover of IPv6, it's not > realistic (or efficient) to consider a solution for DNS security > that doesn't work for IPv4.
I am also thinking about expanding it for IPv4. One possible solution is using the mapping of IPv4 and IPv6. It means use the hash of public key the same way as we use in IPv6 for IPv4. It will not have the same security as exist for IPv4 but is securer than many current approaches for IPv4. However, I am not quite agree with this point because we are in transition time. All networks needs to support both, that is true but there is only some mechanisms that works in both cases and in most cases there is a separate policies for the use in IPv4 and IPv6. This is what can consider here too. Since I do not think the node asks at the same time both IPv4 and IPv6, Does it? So, if it is IPv4, one can use any available mechanism in IPv4 and if it is IPv6, then it can answer it. Again, that mapping can also solve this problem > - At least to me, the traditional TSIG would be sufficient to protect > zone transfers. Usually we expect cooperation between primary and > secondary servers (they are often even the same administrator), so > it doesn't have to be public key based mechanism. The traditional TSIG has some problems that I explained in problem statement of this document. Such as manually exchange of a shared secret and in case of shared secret exposal to the attacker, the repeat of this process. It also does not provide data confidentiality that this draft have this advantage that provide this option easily without extra effort. Public key mechanisms are not so heavy performance. I tested them. It is heavy performance if you want to encrypt or decrypt a large data with them. And here we don't do this. Signing a message is the process of hashing a data and then encrypting the hash of data. > - To protect dynamic updates, my general understanding is that the > major barrier is not the underlying authentication mechanism but > that many server administrators simply don't want to allow their > clients to update the zone. When the administrator can accept that > operation, and it's only for AAAA or PTR, I guess they would even > accept weaker but more easier to use mechanisms such as BIND 9's > "tcp-self" update-policy (yes, this is a hack and not really secure > for security purists, but doesn't require any protocol > modification). This document does not change protocol . This is why we added all values in the other data section of TSIG. I guess you misunderstood the problem here. IMHO, what you exclaim here is that we don't need security because we don't want to modify protocol. This is quite a wrong consideration. What I understand here, the whole process in IETF is toward having better support of security and privacy, both. Now again, the problem that this draft address is not only authentication, again as I explained earlier, it is the problem of IP spoofing during DNS update. In draft I explained two different scenarios. Zone transfer is different than only letting the client to update his own values like his PTR. You are right that you might not let any client to update any records, but some administrator wants to let their clients to do so because the applications working based on the names not IP. For zone transfer process I considered both data confidentiality and data integrity and secure authentication. How you can have this with tcp-self? You cannot. I will continue answering the other parts of your comments after DNSE today. Thank you, Hosnieh _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
