Subject: Re: [perpass] DNS Integrity vs DNS confidentiality

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 29 Sep 2013 16:25:35 +0200

Hi Christian,

Let me first say that I have altered the subject line because, as I
explained earlier, our approach does not provide for data confidentiality
(one can eavesdrop on the data but one cannot modify and spoof the sender or
message content) but does provide for data integrity. If one wants both
confidentiality and data integrity then one can use the approach I
introduced in the first message I sent. This approach is called CGA-TSIGe
(encrypted CGA-TSIG). 
 
> 
> CGA only protect against MITM attacks if the addresses are exchanged 
> securely. Otherwise, you get the following situation:

May I ask you to first read the draft cga-tsig?  
I guess your assumption is that CGA is valid only in the local link so any
other nodes are capable of playing in between, like playing MITM or like
Proxy NDP, etc. To answer your concern, I confirm that CGA-TSIG is an
application layer protocol, dissimilar to the original CGA, and that the
node directly makes use of TCP or UDP to send messages to the DNS server or
other nodes. This means that CGA-TSIG options constitute a payload within
the TCP message which is signed by the originator. There is thus a binding
between the originator IP address and the public key of the signer so this
approach works and avoids MITM attacks by providing data integrity.

> * A wants to connect with B;
> * The evil E convinces A that the address of B is  X, a CGA address
composed by

How does the evil E convince A? This is the question because A already knows
the IP address of B and only accepts the messages from B. It will not open
any channel with any intermediate nodes as it expects an end to end channel
with B whose IP address it knows and the routers in between only route the
packets. 

What I want to tell you here is that we assume that A receives the IP
address of B from a resolver that again knows its IP address or obtained it
using a secure manner. Your scenario, by the use of cga-tsig, changes to the
following: 

A asks R(resolver) what is the IP address of B. 

Evil E says that it is X.

A checks the signature and proceeds with the CGA verification. It fails. 

A rejects the answer from E. 

A receives a response from R.

A proceeds using the verification process that is explained in cga-tsig. 

A accepts R and accepts the message content. R says the IP address is Y. A
establishes the connection with B using Y. 

E fails so E couldn't play the MITM.  

> E;
> * Using CGA, A establishes a secure channel to X;
> * Using CGA, E establishes a secure channel  from X to B;
> 
> Voila, the connections are properly secured with CGA, yet E is in the
middle.

I think the data confidentiality doesn't need to use the resolver scenario.
Because the resolver responds to anonymous queries it doesn't make sense to
decrease the DNS performance the the use of something that is not needed.
What I want to explain here is that data confidentiality is good for DNS
query updates (zone transfer, FQDN update) in order to avoid leaking zone
information.

Hosnieh

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 29 Sep 2013 16:54:35 -0700

> approach works and avoids MITM attacks by providing data integrity.

The main value of CGA is that it encodes a hash of a public key in the least
significant 64 bits of an IP address. You propose to use this property to
simplify the configuration of DNS TSIG. To quote your draft, "the current
problem with using TSIG is that manual processing is required in order to
generate and exchange the shared secrets." 

The default signature process of DNS-TSIG is an MD5 MAC protected by a
shared secret. You propose to replace that by a public signature based the
same public key used to generate the IPv6 CGA address, and then add
parameters in TSIG to facilitate the verification of the linkage of public
key to IPv6 address according to the CGA algorithms.

The security of your approach relies on the fact that "the resolver already
knows the IPv6 address of the server." That is, the only "secure"
configuration needed at the resolver is the CGA IPv6 address of the server.
This configuration is critical, because if the IPv6 address can be spoofed,
then man in the middle attacks become possible. 

If we expect to provide secure updates, we will need to also assume that
"the server already knows the IPv6 address of the resolver." More precisely,
the server would need to maintain the list of IPv6 CGA addresses that are
authorized to send updates of records for a given DNS names. 

Your claim is that configuring the CGA IPv6 address of the servers on the
resolvers, and configuring the CGA IPv6 addresses of the authorized
resolvers on the server, is simpler than configuring shared secrets on both
the servers and the resolvers. I am not sure that this is true in practice.
The CGA addresses in your design are used as the authentic signature of an
authorized public key. As such, they will need the same level of protection
as for example a "key ring" in PGP. If one can securely configure these
addresses, one could probably just as well configure a shared secret. 

Using IPv6 addresses as "trusted key hashes" introduces serious life time
issues. IP addresses typically have a shorter life time than the trust
relation between a server and a resolver. Making IP addresses the key to
security introduces serious complexity in the IP address update process.
Your draft proposes some ways to do that, but the whole issue screams
"administrative nightmare." 

It seems that the bulk of the administrative gains in your proposal come
from a shift from shared secrets to public keys in TSIG. The transactions
end up being protected by the public keys of the servers and resolvers. This
may be a valid tradeoff, which could certainly be debated in the DNS working
group. However, IPv6 CGA would be just one way to introduce public keys in
TSIG. Two alternative come to mind, using TLSA to negotiate a secure DNS
transport, and if you really want to use CGA, using CGA in conjunction with
TKEY to negotiate the TSIG secrets.

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Sep 2013 01:17:54 +0100

I've gotta say: this doesn't seem like a useful diuscssion here.
IMO the snr on this list is being affected by that, so please
stop discussions that are off-topic for this list.

On this list, we're considering how to make pervasive monitoring
more expensive. Authenticating end-user devices just is not a
part of that. Bulk operations between DNS infratructure nodes is
(by itself) just not a part of that. Since those basic functions
are not relevant here, please don't continue using this list for
that discussion.

If you disagree, please start an informed discussion as to how
authenticating end-users or their devices assists in making
pervasive monitoring harder. Or try argue that protocols used
between DNS infrastructure nodes can help make pervasive
monitorinng harder. But please do not continue discussion that
isn't aimed at making pervasive monitoring harder.

Regards,
Stephen. (As a list admin)

PS: Yes, this mail is a precursor to starting down the road of
RFC 3683. If you don't know what that means, please read the RFC.
Either way, please stay on topic.