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 rest of it. i am frankly astonished that anyone would produce text and ideas at this low quality level and then ask others to review it with the invitation: "do you think it is now a good acceptable version?" my answer is not just "no" or "of course not" but rather "you should know better than to ask, given the document as it is." vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
