Subject: [perpass] DNS confidentiality

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Sep 2013 09:43:51 +0100

Hiya,

I've not seen mention of this so far here that I recall.

Even as we improve the security of loads of protocols, there
will still be issues with meta-data monitoring based on
DNS queries for example. This point was sort of raised on
the IETF list e.g. in [1].

DNSSEC doesn't provide any confidentiality. There are
proposals that do try do that.

Do we think this is worth looking at?
If so, anyone up for doing some work on that?
If so, how, or starting from what?

S.

[1] http://www.ietf.org/mail-archive/web/ietf/current/msg82696.html

---

From: Andy Wilson <[email-masked]>
Date: Tue, 24 Sep 2013 23:31:10 +1200

Have you seen DNSCurve? http://dnscurve.org/
There are a few opensource implementations of it out there, OpenDNS for one
have implemented it on their resolvers

On 24 September 2013 20:43, Stephen Farrell <[email-masked]>wrote:

> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

-- 
Regards

Andy

---

From: Karl Malbrain <[email-masked]>
Date: Tue, 24 Sep 2013 13:31:05 -0700 (PDT)

To obviate the harvesting of meta-data, we do need a secure interface to DNS.
 
MITM resistance (authentication) is also going to be required in DNS server connections. Maybe well known certificates for DNS servers incorporated into browser software
 
Given the reluctance of browser writers to implement DANE,  we're going to need something like encrypted QUIC available as a transport first.
 
Karl Malbrain  

________________________________
 From: Stephen Farrell <[email-masked]>
To: perpass <[email-masked]> 
Sent: Tuesday, September 24, 2013 1:43 AM
Subject: [perpass] DNS confidentiality

Hiya,

S.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 24 Sep 2013 23:08:14 +0200

MITM attack can be prevented by signing the data. Please check cga-tsig
draft.

Hosnieh

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Karl Malbrain
Sent: Tuesday, September 24, 2013 10:31 PM
To: Stephen Farrell; perpass
Subject: Re: [perpass] DNS confidentiality

To obviate the harvesting of meta-data, we do need a secure interface to
DNS.

MITM resistance (authentication) is also going to be required in DNS server
connections. Maybe well known certificates for DNS servers incorporated into
browser software

Given the reluctance of browser writers to implement DANE,  we're going to
need something like encrypted QUIC available as a transport first.

Karl Malbrain  

Hiya,

S.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 24 Sep 2013 17:10:47 -0400 (EDT)

> To obviate the harvesting of meta-data, we do need a secure interface to DNS.

It might help but giving people urls that will trigger dns requests for
tracking is pretty easy. Only something like tor might safeguard against
that.

> Given the reluctance of browser writers to implement DANE,  we're going to need something like encrypted QUIC available as a transport

There will be dane in browsers, once we ensure it is cheap 
enough on high latency devices. Eg see

http://tools.ietf.org/html/draft-wouters-edns-tcp-chain-query-00

It's easy to add anonymous IPsec to open resolvers (and I'm in the
process od doing so) but hiding DNS queries involves a lot more than
just encrypting queries.

Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Sep 2013 14:15:21 +0200

On Tue, Sep 24, 2013 at 11:31:10PM +1200,
 Andy Wilson <[email-masked]> wrote 

> Have you seen DNSCurve? http://dnscurve.org/

Channel-security solutions like the non-standard and poorly documented
DNScurve provide confidentiality against a passive third-party
observer. Not against the operators of the authoritative name servers
who see a lot of traffic and can share it with others. (For instance,
several of the root name servers are managed by the US army or a US
government agency.)

Not to mention the resolvers of the ISP or the big open resolvers like
OpenDNS or Google Public DNS, both based in PRISMland. (They see even
more since the caching does not "protect" against them.)

To summary, modify DNS to ensure confidentiality is highly
non-trivial.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 25 Sep 2013 13:26:43 +0100

> tracking is pretty easy. Only something like tor might safeguard against

Presumably the threat is not the provider of the URL but an observer
of your traffic?

---

From: Mark Handley <[email-masked]>
Date: Wed, 25 Sep 2013 05:31:36 -0700

> more since the caching does not "protect" against them.)

A long time ago we looked into pushing DNS NS data in bulk, primarily as
a way to make it more robust against DDoS attack.  But solutions in this
general space might also be used to improve privacy:
http://www.cs.ucl.ac.uk/staff/m.handley/papers/dnspush.pdf‎

Cheers,
Mark

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Sep 2013 13:35:54 +0100

Hi Stephane,

> Channel-security solutions like the non-standard and poorly documented

Non-standard we can fix and we do our best to help with
poorly documented as well:-)

> To summary, modify DNS to ensure confidentiality is highly

Right, I agree its non-trivial and that some servers somewhere
will see the queries and responses and could be part of a
monitoring network via collusion or coercion or as a result of
being hacked.

I guess I'm wondering though if its worthwhile and if there are
folks who'd be willing and able to do the work. Or at least some
initial work - I don't think this is one where I'd expect its
likely somoene can just write a nice short draft and be finished
very quickly.

S.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Sep 2013 14:40:59 +0200

On Wed, Sep 25, 2013 at 01:35:54PM +0100,
 Stephen Farrell <[email-masked]> wrote 
 a message of 49 lines which said:

> initial work - I don't think this is one where I'd expect its likely
> somoene can just write a nice short draft and be finished very
> quickly.

May be starting with the more modest but certainly useful "DNS privacy
considerations" Internet-Draft? Such a document, just documenting the
problem, would be a good idea, IMHO.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 25 Sep 2013 09:59:25 -0400

> problem, would be a good idea, IMHO.

+1

(since I would love to read such a thing but likely have little 
expertise in the drafting.)

--
Joseph Lorenzo Hall
Senior Staff Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: BE7E A889 7742 8773 301B 4FA1 C0E2 6D90 F257 77F8

---

From: Karl Malbrain <[email-masked]>
Date: Wed, 25 Sep 2013 12:18:56 -0700 (PDT)

>tracking is pretty easy. Only something like tor might safeguard against
 
I'm not following you here.  Can you elaborate on the threat?  I was referring to passive monitoring of DNS traffic by third parties who want to know what domains you are visiting.

>> Given the reluctance of browser writers to implement DANE,  we're going to need something like encrypted >>QUIC available as a transport
>> first.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Sep 2013 15:34:32 -0400 (EDT)

On Wed, 25 Sep 2013, Karl Malbrain wrote:

> I'm not following you here.  Can you elaborate on the threat?  I was referring to passive monitoring of DNS traffic by third parties who
> want to know what domains you are visiting.

A passive monitor can just wait and ignore your DNS and then see you
connect to IP a.b.c.d. They can easilly find what's hosted there. I
mean netcraft even runs a public website where you can ask for all the
vhosts running on a certain IP.

And if you're going to use tor to hide that, than your DNS should also
have gone via TCP on the tor network.

An active attacker trying to de-anonymise you could use specifically
crafted DNS queries to lure you into resolving something that only
exists to catch you.

I think of the DNS as one of the only required non-encrypted services to
kickstart encryption, but I agree that we could hide DNS better using
Opportunistic Encryption (IPsec based). You would still need some
unencrypted DNS to setup the IPsec to the DNS servers though.

What we don't need though is another dns-like protocol to do so. (and
definitely not dnscurve, as it does not support dns data authenticity,
only transport security)

Paul

---

From: Karl Malbrain <[email-masked]>
Date: Wed, 25 Sep 2013 12:37:54 -0700 (PDT)

Yes, MITM can be prevented if you have a copy of the public certificate obtained through exteriour means to check the signature over the data.  If your certificate is provided by MITM you naturally lose that signature protection.

________________________________
 From: Hosnieh Rafiee <[email-masked]>
To: 'Karl Malbrain' <[email-masked]> 
Cc: 'perpass' <[email-masked]>; 'Stephen Farrell' <[email-masked]> 
Sent: Tuesday, September 24, 2013 2:08 PM
Subject: Re: [perpass] DNS confidentiality

MITM attack can be prevented by signing the data. Please check cga-tsig draft.

Hosnieh

From:[email-masked] [mailto:[email-masked]] On Behalf Of Karl Malbrain
Sent: Tuesday, September 24, 2013 10:31 PM
To: Stephen Farrell; perpass
Subject: Re: [perpass] DNS confidentiality

 
 
Karl Malbrain  
 
From:Stephen Farrell <[email-masked]>
To: perpass <[email-masked]> 
Sent: Tuesday, September 24, 2013 1:43 AM
Subject: [perpass] DNS confidentiality

Hiya,

S.

---

From: Karl Malbrain <[email-masked]>
Date: Wed, 25 Sep 2013 12:47:06 -0700 (PDT)

I see.....
 
Then the difference in security is that once you are targetted individually, your connection meta-data are available for harvesting and something like tor is required.  But, if the monitoring is at the DNS server then encryption makes it impossible to determine who should be targetted next.

________________________________
 From: Paul Wouters <[email-masked]>
To: Karl Malbrain <[email-masked]> 
Cc: perpass <[email-masked]>; Stephen Farrell <[email-masked]> 
Sent: Wednesday, September 25, 2013 12:34 PM
Subject: Re: [perpass] DNS confidentiality

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Sep 2013 20:59:38 +0100

Hi Paul,

> definitely not dnscurve, as it does not support dns data authenticity,

You might be right about dnscurve, or maybe not. I dunno
enough about it yet to be to be honest. But, as you know,
DNSSEC is where the IETF has placed its bet for DNS data
origin auth. Changing that would maybe require a seismic
shift, so for this discussion I was assuming DNSSEC is the
answer for data origin auth and just asking if it'd be
useful to add confidentiality. So, the fact that dnscurve
doesn't do what DNSSEC does isn't really a compelling
argument here I think.

Cheers,
S.

PS: Yes, we should all be doing stuff to encourage more
deployment of DNSSEC, but I think that's a separate
discussion, for other lists probably, even though DNSSEC
deployment might make it harder to mount some attacks
that are used in monitoring.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 25 Sep 2013 22:08:06 +0200

Not if you use another approach as well as a signature. This means that if
the two nodes know the IP address of each other, then nobody can play a role
of MITM if they are using CGA-TSIG
(http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig) as a means of DNS
authentication.

Hosnieh

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Karl Malbrain
Sent: Wednesday, September 25, 2013 9:38 PM
To: Hosnieh Rafiee
Cc: 'perpass'; 'Stephen Farrell'
Subject: Re: [perpass] DNS confidentiality

Yes, MITM can be prevented if you have a copy of the public certificate
obtained through exteriour means to check the signature over the data.  If
your certificate is provided by MITM you naturally lose that signature
protection.

From: Hosnieh Rafiee <[email-masked]>
To: 'Karl Malbrain' <[email-masked]> 
Cc: 'perpass' <[email-masked]>; 'Stephen Farrell'
<[email-masked]> 
Sent: Tuesday, September 24, 2013 2:08 PM
Subject: Re: [perpass] DNS confidentiality

 

Hosnieh

Karl Malbrain  

Hiya,

S.

---

From: Karl Malbrain <[email-masked]>
Date: Thu, 26 Sep 2013 11:08:34 -0700 (PDT)

CGA-TSIG seems to be a trust on first use protocol for subsequently updating records within DNS.  It doesn't seem to address the problem of an arbitrary client securely obtaining the IP/Public Key for an arbitrary host from DNS without the possiblity of MITM.  Perhaps you could explain further.
 
Karl Malbrain  

Sent: Wednesday, September 25, 2013 1:08 PM

Not if you use another approach as well as a signature. This means that if  the two nodes know the IP address of each other, then nobody can play a role of MITM if they are using CGA-TSIG (http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig)as a means of DNS authentication.

Hosnieh

 
From:Hosnieh Rafiee <[email-masked]>

Hosnieh

 

Karl Malbrain  

Hiya,

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Sep 2013 12:51:07 -0400

> If so, how, or starting from what?

I have been looking at this for over a year now. Does anyone have issues
with the following:

* The communication between the client and the DNS resolver need not be the
same as the protocol between the DNS resolver and the Authoritative servers.

* System must offer fault tolerance with the client having access to
multiple service points.

* Use JSON over HTTP wherever possible

* Individual DNS queries MUST result in low latency responses, this limits
us to using UDP.

* The scheme MUST work in ANY network configuration unless the provider
takes explicit steps to block use. Therefore the scheme SHOULD support
tunneling over DNS as an option but a clean protocol over UDP is better.

* The scheme need not be limited to returning DNS information, if we have a
long term security association between a client and a resolution service we
can use it for speeding up access to OCSP data and much else if we choose.

The above analysis led me to the following conclusion:

http://tools.ietf.org/html/draft-hallambaker-omnibroker-06

This does not currently offer the UDP and DNS options but they are what
motivated the following proposal:

http://tools.ietf.org/html/draft-hallambaker-jsonbcd-00

There are important design differences between this proposal and CBOR. In
particular JSON-B is a minimal extension of the JSON framework to add in
efficient encoding of strings and binary data while CBOR is a rehash of
ASN.1 without the schema.

Note that the query currently supported is a replacement for the
gethostbyname API call rather than a full DNS interface. The reason for
this is that 99% of all applications only perform gethostbyname in the
first place. The spec does allow a service to respond with a DNSSEC proof
chain as advice on client request.

Adding direct DNS queries to the spec is very simple, these can certainly
be added if there is a desire for them. I would make one major change
however and that is to support multiple DNS queries per request. One of the
biggest limitations in the current DNS scheme is that it is only possible
to query for one DNS record at a time or the ANY pseudo record which
returns everything (and likely forces a TCP switchover).

The requests actual applications want to make are things like the following:

[example.com ? A, AAAA] [_http._tcp.example.com ? SRV, URI, URI2]

Use of extended DNS features would be much easier if a client could tell
the resolver to send back data for multiple queries at once.

Moving to a pure UDP protocol allows requests and responses to be longer
than 500 bytes. It is also possible for a single request packet to return
multiple responses. These mean that it is very unlikely that fallback to
TCP is ever going to be necessary for client queries where low latency is
essential. It is however possible that a complex DNSSEC interaction might
require a large amount of response data.

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Sep 2013 13:04:57 -0400

On Wed, Sep 25, 2013 at 3:59 PM, Stephen Farrell
<[email-masked]>wrote:

> origin auth.

+1

I really can't see how DNSCurve would have been practical if it had a clear
field. But now that we have bet on DNSSEC for authenticating the data
within a DNS zone, that is a fixed choice.

We can change some of the offensive parts of the DNSSEC architecture like
the fact that it grants ICANN entire control over who is in the DNS and who
is not. There is no reason that ICANN should have the ability to drop Cuba
or Iran out of the root when Ted Cruz is threatening to filibuster the
deficit ceiling limit rise if the President won't sign a bill forcing the
US corporation to do that.

> Changing that would maybe require a seismic

What we want from a design point of view is a secure mechanism for securing
the channel based on a long term session key. One option for that would be
DTLS. But since all we are doing is signing and encrypting packets under a
long term session key we can achieve the desired end with a much simpler
Kerberos-like scheme.

DTLS is actually a poor choice here because TLS is designed on the
assumption that the DNS layer stuff has already taken place. It uses
certificate chains and PKIX infrastructure that layers over TCP/IP and DNS.

> that are used in monitoring.

A replacement for the client-resolver protocol is one of the steps I think
would best help deployment of DNSSEC. That is where much of the difficulty
in making schemes like DANE practical lies.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 27 Sep 2013 19:19:10 +0200

>CGA-TSIG seems to be a trust on first use protocol for subsequently
Updating records within the DNS.  It doesn't seem to address the problem of
an arbitrary client securely obtaining the IP/Public Key for >an arbitrary
host from DNS without the possibility of MITM.  Perhaps you could explain
further.

The client doesn't need to retrieve their public key from anywhere.   They
generate it themselves. This is the actual case with CGA-TSIG. So how does
it work you ask? It is dependent on the scenarioes. 

For the resolver scenario:
The client knows the IP address of the resolver because it was obtained from
a DHCP server or a RA message. When, for the first time, the client wants to
resolve its query and the resolver answers, the client finds the binding
between the IP address and the public key, which is generated by the DNS
server itself. This is actually a capability of CGA (RFC 3972) or SSAS
(http://tools.ietf.org/html/draft-rafiee-6man-ssas  ),  which also provides
for the proof of address ownership. So, the client stores the public key of
the resolver in its cache. It will subsequently not accept any messages from
attackers. Why?
Because the attacker doesn't have the private key of the node  that he needs
in order to spoof the message and since the public key that is involved in
the address generation using both algorithms, then it is not possible for
the attacker to spoof this IP address and make use the public key of the
resolver. 

In the zone transfer scenario, both DNS servers know the IP address of each
other as a result of the first time manual configuration. So, nobody can
spoof this IP address and play a man in the middle attack. As all the
message is signed by both parties, the attacker cannot spoof the message nor
can he claim to be any of those nodes.

FQDN and PTR updates are only vulnerable to spoofing attacks the first time
an update is run because no association between the FQDN and the IP address
has been established. When any clients in the network want to update these
records, the DNS server will receive any message from the clients and, after
a successful verification, will then add the public key of this client thus
creating  the association. Then the DNS server stores the public key, which
is now associated with the client's hostname, in a new database table which
will be maintained for a certain period of time.
In this scenario, the only attack possible for the first time update where
the attacker claim to have a hostname that was chosen by the client.  When
it is important for a client to have certain hostname, then the first time
manual configuration will solve this problem. 

If any nodes want to change their IP addresses, do we need to initiate
another manual configuration?
No, because the node signs the timestamp with the old private key associated
with old public key and also signs the message with its own new private key.
So if the attacker wants to claim to be this node, since it doesn't have the
old private key and the new private key for this node, it cannot sign the
message and the signature verification process will fail.

If you want to avoid this manual configuration, which is ONLY for the first
time of processing, then you need to use trusted third parties. It can work
in the same way as the SSL works in retrieving the public key of the DNS as
is explained in CGA-TSIG draft.

So, CGA-TSIG provides the node with data integrity but as it doesn't encrypt
the message and only signs it, it cannot provide data confidentiality. But
this doesn't mean that it cannot protect the node against MITM attacks as I
explained in a different scenario. More details can be found in the draft.
I'm actually in the process of improving the draft by making it more
readable by shortening the abstract.

We also have a paper which discusses the possibility of encrypting the
message using the DNS server public key. Please refer to this paper
(http://www.hpi.uni-potsdam.de/fileadmin/hpi/FG_ITS/papers/Trust_and_Securit
y_Engineering/2013_Rafiee_NCA.pdf  ). This is more applicable to the DNS
update (zone transfer, FQDN) scenario. This means that the client first asks
for the public key of the DNS server. When using the CGA/ SSAS algorithm, a
binding is found between the public key and the IP address of the DNS
server. The client then generates a shared secret, encrypts it using the
public key of the DNS server, and generates the update message, encrypts it
using this shared secret (symmetric encryption - algorithm like AES), and
submits it to the DNS server. Since the attacker doesn't know the content of
message, it cannot play a role of MITM when using the FQDN scenario for the
first time.
This approach provides both confidentiality and integrity. But it requires a
change to the DNS protocol. Because, instead of the plain update section,
prerequisite section, etc. the DNS server receives the encrypted message and
needs to use its own private key to decrypt the shared secret and then
decrypt the whole update message. 

If anybody thinks this is useful, I will include it in the content of our
paper as a new draft.

Hosnieh

---

From: Karl Malbrain <[email-masked]>
Date: Fri, 27 Sep 2013 11:41:25 -0700 (PDT)

I'm concerned about three DNS security problems:
 
1.  Passive surveillence of traffic going to DNS resolvers yielding meta-data.
 
2.  MITM who inserts himself between a particular DNS client and a particular DNS resolver, and provids false addresses and certificates for use in MITM attacks.
 
3. A larger adversary who installs his own DNS resolver for a given geographic area by controlling the traffic at the router level into and out of that area to redirect DNS traffic to his DNS resolver, and then inserts MITM attacks on any connection out of the area he desires by supplying bogus addresses and/or server certificates.
 
I'm not concerned at this time about an even larger adversary capable of surveillence of all traffic in a given geographic area, yielding a complete set of meta-data. 

>it work you ask? It is dependent on the scenarioes. 
 
The client is trying to retrieve the IP address and public key for an arbitrary server from the DNS resolver.  This is subject to MITM attack.
 
>server itself.
 
How does this prevent MITM from inserting himself between the client and the resolver on the first connection to the resolver?
 
> This is actually a capability of CGA (RFC 3972) or SSAS
>attackers.
 
What if the public key being stored belongs to MITM and not the resolver? All client traffic is going to MITM.
 
> Why?
 
MITM provided his public key in the first connection from the client.

>(http://www.hpi.uni-potsdam.de/fileadmin/hpi/FG_ITS/papers/Trust_and_Security_Engineering/2013_Rafiee_NCA.pdf  ).
> This is more applicable to the DNS
 
Whom does the client "ask for the public key of the DNS server" from?  This is the step that is subject to MITM attack.
 Karl Malbrain

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Sep 2013 14:55:21 -0400

> 1.  Passive surveillence of traffic going to DNS resolvers yielding

Use your own resolver and/or encrypt traffic to the resolver.

e.g. Omnibroker.

> 2.  MITM who inserts himself between a particular DNS client and a
> particular DNS resolver, and provids false addresses and certificates for
> use in MITM attacks.
>

Authenticate messages between the client and resolver.

e.g. Omnibroker.

> 3. A larger adversary who installs his own DNS resolver for a given
> geographic area by controlling the traffic at the router level into and out
> of that area to redirect DNS traffic to his DNS resolver, and then inserts
> MITM attacks on any connection out of the area he desires by supplying
> bogus addresses and/or server certificates.
>

Tunnel your communication traffic to your chosen resolver via available
channels, e.g. HTTP or UDP or DNS tunnel

e.g. Omnibroker.

> I'm not concerned at this time about an even larger adversary capable of
> surveillence of all traffic in a given geographic area, yielding a complete
> set of meta-data.
>

That is a harder problem but one that I suspect is not such a great deal
due to caching. The NSA is only occasionally going to be able to match one
of my requests to outbound traffic. A resolver could even obfusticate
those. For example in the case of a cache miss make 20 DNS queries rather
than one.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 27 Sep 2013 21:21:50 +0200

>1.  Passive surveillence of traffic going to DNS resolvers yielding
meta-data.

Again not possible, at least not in IPv6 if your resolvers and recursive
resolvers are using cga-tsig. The signature and the CGA/SSAS algorithm
prevent it.

Again this is not possible if you are using cga-tsig.

geographic area by controlling the traffic at the router level into and out
of that area to redirect DNS traffic to his DNS resolver, and then inserts
MITM attacks on any connection out of the area he desires by supplying bogus
addresses and/or server certificates.

If you are using SeND with SSAS or centralized RPKI you can retrieve and
verify your router in a local link. RA can include the
(http://tools.ietf.org/html/rfc6106) DNS server options. This means that you
receive a signed message from a router that was previously authorized via
the centralized local RPK1. I am not sure whether or not DHCPv6 also
includes security approaches that can be used for authentication. I believe
that there was a draft about secure authentication using CGA in DHCPv6 as
well.
You can also us a scenario, like SSL, to verify your router certificate
where the client has already configured the list of CAs.

>The client is trying to retrieve the IP address and public key for an
arbitrary server from the DNS resolver.  This is subject to MITM attack.

I guess that you did not quite understand the reasoning behind CGA and that
is why you are asking a question about an issue that I have already
explained. Your client retrieves this IP address from the RA message that is
generated by the use of SeND with the DNS RA option (. Since this RA message
is already signed and we assume that this client has already verified this
router (centralized local RPKI that is explained in SSAS or other RPKI
approaches) the attacker has no way of spoofing this message as it cannot
spoof the content (due to the signature) and it cannot spoof the public key
due to the binding between the public key and the source IP address

>How does this prevent MITM from inserting himself between the client and
the resolver on the first connection to the resolver?

Your node already knows the IP address of your resolver.

> What if the public key being stored belongs to MITM and not the resolver?
All client traffic is going to MITM.

As I explained, you retrieve the IP address of your DNS server using a safe
means after having authorized your router in the local link. Now if your
MITM node is somewhere in the other network and tries to intercept the
connection between your node and the resolver, since you node already knows
the IP address of the resolver, it will reject the connection because the
CGA/SSAS verification process fails.
 
>Whom does the client "ask for the public key of the DNS server" from?  This
is the step that is subject to MITM attack.

I guess I have already responded this.

Hosnieh

---

From: manning bill <[email-masked]>
Date: Sat, 28 Sep 2013 03:02:03 -0700

you are conflating routing security/authentication with DNS service opaque capabilities.
there already exist a number of methods for securing the DNS channel,  [SIG(0), TSIG, DNSCurve…]
and we can add your technique to the list.   

protecting the service is very different than protecting the channel.

/bill

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 28 Sep 2013 16:11:12 +0200

I ask that you please put aside your preconceived ideas and read the
cga-tsig document with an open mind before you judge it. The document
addresses the problem with the use of TSIG and SIG and introduces a new,
combined method which can protect nodes against several types of attack. 
Karl asked how the node receives the IP address of the DNS as it can be the
first point of a MITM attack. I just explained that this is not possible, as
earlier explained, the node can retrieve this IP address in a safe manner
during a first time retrieval. 
This has nothing to do with CGA-TSIG as it assumes that the node already
learned the IP address of the DNS server in a safe way. This document only
explains a new method for secure authentication during different scenarios.

Hosnieh
 
> there already exist a number of methods for securing the DNS channel,
[SIG(0),
> TSIG, DNSCurve.]
> > Again not possible, at least not in IPv6 if your resolvers and
> > recursive resolvers are using cga-tsig. The signature and the CGA/SSAS
> > algorithm prevent it.
> >
> > particular DNS resolver, and provids false addresses and certificates
> > for use in MITM attacks.
> >
> > geographic area by controlling the traffic at the router level into
> > and out of that area to redirect DNS traffic to his DNS resolver, and
> > then inserts MITM attacks on any connection out of the area he desires
> > by supplying bogus addresses and/or server certificates.
> >
> > If you are using SeND with SSAS or centralized RPKI you can retrieve
> > and verify your router in a local link. RA can include the
> > (http://tools.ietf.org/html/rfc6106) DNS server options. This means
> > that you receive a signed message from a router that was previously
> > authorized via the centralized local RPK1. I am not sure whether or
> > not DHCPv6 also includes security approaches that can be used for
> > authentication. I believe that there was a draft about secure
> > authentication using CGA in DHCPv6 as well.
> > You can also us a scenario, like SSL, to verify your router
> > certificate where the client has already configured the list of CAs.
> >
> >
> > I guess that you did not quite understand the reasoning behind CGA and
> > that is why you are asking a question about an issue that I have
> > already explained. Your client retrieves this IP address from the RA
> > message that is generated by the use of SeND with the DNS RA option (.
> > Since this RA message is already signed and we assume that this client
> > has already verified this router (centralized local RPKI that is
> > explained in SSAS or other RPKI
> > approaches) the attacker has no way of spoofing this message as it
> > cannot spoof the content (due to the signature) and it cannot spoof
> > the public key due to the binding between the public key and the
> > source IP address
> >
> >
> >> (http://tools.ietf.org/html/draft-rafiee-6man-ssas ),  which also
> >> provides for the proof of address ownership. So, the client stores
> >> the public key of the resolver in its cache. It will subsequently not
> >> accept any messages
> > from
> >> attackers.
> >
> >> What if the public key being stored belongs to MITM and not the
resolver?
> > As I explained, you retrieve the IP address of your DNS server using a
> > safe means after having authorized your router in the local link. Now
> > if your MITM node is somewhere in the other network and tries to
> > intercept the connection between your node and the resolver, since you
> > node already knows the IP address of the resolver, it will reject the
> > connection because the CGA/SSAS verification process fails.
> >

---

From: Karl Malbrain <[email-masked]>
Date: Sat, 28 Sep 2013 08:27:52 -0700 (PDT)

The routers being controlled by the larger adversary are the ones that take traffic into and out of the geographic area.  The adversary is re-routing all traffic to DNS ports to his bogus DNS server and replying with IP address spoofing -- e.g. a MITM attack on DNS traffic.
 
DNS needs some means of authentication to prevent this.  Certificates can be forged. TOFU doesn't work either.
 
The routers are completely programmable by MITM -- they don't have any security that I know of.

________________________________
 From: manning bill <[email-masked]>
To: Hosnieh Rafiee <[email-masked]> 
Cc: 'perpass' <[email-masked]>; 'Karl Malbrain' <[email-masked]>; 'Stephen Farrell' <[email-masked]> 
Sent: Saturday, September 28, 2013 3:02 AM
Subject: Re: [perpass] DNS confidentiality

/bill

On 27September2013Friday, at 12:21, Hosnieh Rafiee wrote:

>> (http://tools.ietf.org/html/draft-rafiee-6man-ssas),  which also provides

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 28 Sep 2013 16:31:31 +0100

Karl,

The subject line is about confidentiality. If you (or others)
want to disucss other security issues with DNS, please first
read up on DNSSEC and then start new threads.

Now, can we get back to discussion of subject of the subject
line?

Thanks,
S.

---

From: Karl Malbrain <[email-masked]>
Date: Sat, 28 Sep 2013 08:36:08 -0700 (PDT)

>during a first time retrieval.
 
This is called Trust On First Use (TOFU).
 
If the MITM attacker is already in play before the "first time retrieval" then the node is not talking to the DNS resolver he thinks he is.  He is talking to MITM instead, who can forge certificates and spoof IP addresses.  Just knowing the IP address of the resolver you trust is not enough to protect against MITM.
 
>This has nothing to do with CGA-TSIG as it assumes that the node already
l>earned the IP address of the DNS server in a safe way. This document only
>explains a new method for secure authentication during different scenarios.

The problem is that you have not demonstrated a "safe way" to authenticate the DNS resolver connection.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 28 Sep 2013 17:53:19 +0200

Confidentiality is not possible unless all the queries are encrypted. Using
asymmetric cryptography for a small message is possible, but for a zone
transfer it will have an effect on the DNS performance. So one needs to use
symmetric approaches. (something like what was done in the paper that I sent
the link to in my last message)
Using one way hashing as DNSSEC does with NSEC3 does not completely provide
the zone file with data confidentiality. We tested this procedure and it was
possible to retrieve thousands of records within 2 hours using a standard
computer. The dictionary attack and brute force attack are also possible
which leads to zone walking.

Hosnieh

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 28 Sep 2013 23:32:58 -0700

Hosnieh,

CGA only protect against MITM attacks if the addresses are exchanged
securely. Otherwise, you get the following situation:

* A wants to connect with B;
* The evil E convinces A that the address of B is  X, a CGA address composed
by 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.

-- Christian Huitema

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 29 Sep 2013 20:28:04 +0200

On Fri, Sep 27, 2013 at 11:41:25AM -0700,
 Karl Malbrain <[email-masked]> wrote 

> I'm concerned about three DNS security problems:

You're not concerned about the fact that DNS servers (your resolver,
and the authoritative name servers) get a lot of data and can misuse
it? It seems to be that it is one of the main weaknesses of DNS, when
it comes to confidentiality. A big public resolver, like OpenDNS or
Google Public DNS (both located in PRISMland) can learn a lot of
things about its users (this has been used often to detect malware,
only from its DNS requests, but it could be used for more sinister
purposes). A big TLD (say, for example, .com, also located in
PRISMland) can also learn a lot.

And no amount of cryptographe between the client and this server will
help.

---

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

Stephane,

> And no amount of cryptographe between the client and this server will

Does that mean that there's scope for a BCP on ways of deploying
DNS that are more (or less) privacy friendly? While I guess a bunch
of n/w operators might not care, I'm pretty sure some would. (And
could perhaps get some competetive benefit from demonstrably caring
via following such a BCP.)

Additionally, if you're arguing that there's no useful role at all
for confidentiality in DNS then I think I'd argue that confidentiality
could well be useful, but that it won't by itself be sufficiently
useful to be worth deploying and so is only worthwhile in conjunction
with some already privacy-friendly deployment of DNS servers. Sound
wrong? Or right? If right, then maybe there's scope for some
experimental RFC(s) to go with that BCP.

Volunteers very welcome as usual:-) If you're one, just go write the
internet-draft and we'll catch up with you after you've posted a
link here.

Cheers,
S.