Re: [DNSOP] please review CGA-TSIG
Hosnieh Rafiee wrote: Hello, We actually put all our efforts to change the document thoroughly and not only consider the IPv4 scenario that was comment of some people in mailinglist but also we expand the DNS privacy section and explained it in more detail (no need to change the protocol.) http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-08 thank you. i am not a member of the int-area@ mailing list, so please forward this reply to that forum. So, any more comments? Any more feedback? do you think it is now a good acceptable version? :-) see below. 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. 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. 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. 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 document updates the following sections in TSIG document: ... those details should not be in the Introduction section. 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. 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. 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. 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. Disadvantages: - Offline generation of the signature DNSSEC [RFC6840 http://tools.ietf.org/html/rfc6840] needs manual step for the configuration. For instance, when a DNSSEC needs to sign the zone offline. offline generation is not a disadvantage. dnssec makes it optional, and offers it because it is a desirable feature. 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. - 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. i stopped reading this draft at the end of section 1. it appears not to be worth my time to read the
[DNSOP] I-D Action: draft-ietf-dnsop-rfc6304bis-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : AS112 Nameserver Operations Authors : Joe Abley William F. Maton Filename: draft-ietf-dnsop-rfc6304bis-03.txt Pages : 29 Date: 2014-06-26 Abstract: Many sites connected to the Internet make use of IPv4 addresses that are not globally-unique. Examples are the addresses designated in RFC 1918 for private use within individual sites. Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called reverse lookups) corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the corresponding authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it. RFC6304 described the steps required to install a new AS112 node, and offered advice relating to such a node's operation. This document updates that advice to facilitate the addition and removal of zones for which query traffic will be sunk at AS112 nodes, using DNAME, whilst still supporting direct delegations to AS112 name servers. This document obsoletes RFC6304. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc6304bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsop-rfc6304bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc6304bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] please review CGA-TSIG
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
