Dear Paul,
Thanks for your review and your comments. Please find my responses inline. >thank you. i am not a member of the int-area@ mailing list, so please forward this reply to that forum. I forwarded your message to Intarea. >>The TSIG keys, which are manually exchanged between a group of hosts, need to be maintained in a secure manner. >tsig keys have no needs. i suggest "must be maintained" here. Ok, will consider it. >or to assure a Slave Server that the zone transfer is from the original Master Server and that it has not been corrupted. >or as an access control method to permit AXFR/IXFR only when a shared TSIG key is present. What that sentence means is that the master zone file is not maliciously modified. >>Handling this shared secret in a secure manner and exchanging it does not appear to be easy. This is especially true if the IP addresses are dynamic or the shared secret is exposed to the attacker. >this is nonsequitur. either give a reference for what "does not appear to be" observed, or simply note that out of band key exchange by sneaker-net does not scale and was never expected to. also, _what_ ip addresses? you've not introduced that concept before referencing it. I suggest that you check it yourself in a lab since even theoretically what was explained is correct. Check the case where one of your nodes that has this shared secret is compromised then see the changes need to be done in the configuration of x number of nodes. This was an old discussion with people who already implemented DNSSEC protocol. If you have only two nodes, maybe not a big effort but if you have 10 to 100 nodes to update values on the Server then you're in trouble. Now consider the near future with thousands of Virtual nodes in the clouds that want to update a value on virtual DNS server. I don't think it is a fun even for the first time to exchange the keys between these hosts manually to be secured. >>this document proposes two algorithms which support both IPv4 and IPv6 scenarios. >does each of the two support both protocols? if not, the above wording is wrong. perhaps you mean "two algorithms, one for IPv4, and one for IPv6." This is where I say, you haven't read the document even the first parts and just glance it and some words grab your attention and then you try to review only a few lines of those sections that you found those words. All your comments show this lack of deep review. It is two algorithms, one for both DNS privacy and secure authentication and one for only secure authentication in case DNS privacy is not important. >>This document updates the following sections in TSIG document: ... >those details should not be in the Introduction section. This was a comment received from one of reviewer. JFYI, this document up to now had several DNS expert reviewers with different taste. So, one said it should be explained there and you say no. The story is now like the story of the boy, the man and the donkey. Probably I have to leave it to RFC editor decision. >>There are several different methods where DNS records can become >>compromised. Some examples of methods are DNS Spoofing; DNS >>Amplification Attacks; Resolver Source IP Spoofing; Unauthorized DNS >> Update; User Privacy Attack; and Human Intervention. >this Problem Statement is grossly inadequate to motivate the proposal you've submitted. Really! please show me a method that can prevent for example, DNS amplification among the current available approaches. DNSSEC can do this? I believe not! TSIG can do this? Hum..And about spoofing, what efforts should be done for preventing the nodes from spoofing, for DNSSEC please refer to my response below! At first those problems had also a short description but we thought that we are sending it to DNS experts and all knows about the description of these attacks. If someone also doesn't know, he can refer to the RFC that gathered all these attacks. >consider the User Privacy Attack scenario. the thing that you'd like to hide is the q-tuple, since the response is public information. only the requester's interest in a particular q-tuple at a particular time is worth protecting. we end up having to >encrypt the response not because the response itself is sensitive but because a response will implicate a q-tuple which is sensitive. If you're interested, only encrypt the part you like! I considered the encryption of the whole message without changing the protocol by only adding a new header to the encryption message. Because I think every section of DNS protocol can contain critical information. It is not just the question, it is also the additional section and so on. >in the stub-to-recursive data path, existing data mining is not occuring in-channel, but at the endpoints. A/V products instrument end-system resolvers to learn and sometimes intercept or redirect DNS transactions. that isn't a problem -- users >who don't want it to happen can't stop it with encryption, but they can stop it by uninstalling the A/V. at the other end, an RDNS often participates in some kind of passive DNS collection effort for security analytics purposes, and that is again not >the problem being stated here -- because that's happening outside the channel where encryption would do any good. asking for dns path protection end-to-end from stub to authority, such that the RDNS did not know the q-tuple, raises the >questions of how could it cache or reuse anything, how could DNS function without caching and reuse, and how could the RDNS route a query to an ADNS without knowing the q-name. Whatever you explained here are considered as a use case scenario that I explained some of these use case scenarios in the document. If you have read the document, that unfortunately you haven't, you would find out that like all security mechanisms, when DNS server receives a message with CGA-TSIG option there, then it first follows the verification step and if it is necessary based on the algorithm in use, it decrypts the message. in this stage it knows what was the question and what it needs to be done with this message. So, it is not a mysterious as you explained it here. >yet you're proposing hop-by-hop channel encryption. there is no stated justification for who that helps or how. only if a user wants to use a distant RDNS like opendns or googledns would a form of channel encryption that prevented the user's ISP and other intervening ISP's (or national security agencies in the wide-area data path) be useful. if that's the value you intend to add then you should say so -- after contextualizing it and defining your taxonomy. I have never explained in any part of the document that the communication is hope by hope! The stub resolver send a message securely to the recursive resolver. This recursive resolver can be even in the other networks. I even explained in the document that in case you cannot trust the resolver in a network, then you can easily set your home recursive or the one who you trust manually. This algorithm knows how to handle it securely. Not sure where did you bring "hope by hope" word! . The encryption can be done end-to-end as long as both end nodes support this approach. And about encryption level, it encrypts all the DNS message but adding a new header with a few information for only recognized by the DNS server. If you don't need encryption, then you can only use secure authentication. >offline generation is not a disadvantage. dnssec makes it optional, and offers it because it is a desirable feature. Not desirable feature when you want to have dynamic updates or handle thousands of anonymous nodes on the internet for DNS privacy. This is not a fun! >moreover you appear not to know about SIG(0) which worries me since that ought to have been part of any reasonable background check on this topic before writing a proposal as fundamental as this one. It appears that you don't know the differences between SIG(0) and TSIG and as I explained before, you only got some words from the document and then try to find opposite words for that :-) . I clearly explained in the document that this draft does nothing with TSIG and it only uses TSIG as a carrier protocol to avoid any changes to DNS protocol since for TSIG it is easy to add a new extension by registering it in IANA. But it addresses the problems exist with TSIG or other DNS mechanisms. And you also did not get the idea that the purpose is both security and privacy, and automation as much as possible. This is what you cannot find in SIG(0)! The similarity is that only SIG(0) use public key cryptography but nothing more . >> - IP spoofing >> The public key verification in DNSSEC creates a chicken-and- egg >> situation. In other words, the key for verifying messages should be >> obtained from the DNSSEC server itself. This is why a query requester >> needs to verify the key. >> If this does not happen, DNSSEC is vulnerable to an IP spoofing >> attack. >this is completely wrong, as in, 100% counter-factual. Sorry, you're wrong! What is clearly say there is that when the node does not check the key up to the root then the DNSSEC is vulnerable to spoofing since there is no binding between the key and the IP address of DNSSEC server. Please show me this binding. It appears that I cannot see it! You either need to manually set these bindings or hard copy it on the node. In both case, how do you know that your node is not compromised and if this done what! Show me the proof before you say 100% incorrect! Best, Hosnieh
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
