Subject: [Int-area] please review CGA-TSIG

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 27 Jun 2014 00:18:18 +0200

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