Re: [perpass] DNS confidentiality

"Hosnieh Rafiee" <ietf@rozanak.com> Fri, 27 September 2013 17:19 UTC

Return-Path: <ietf@rozanak.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F3721F9425 for <perpass@ietfa.amsl.com>; Fri, 27 Sep 2013 10:19:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd9800goNeH9 for <perpass@ietfa.amsl.com>; Fri, 27 Sep 2013 10:19:40 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 43FE021F9CDF for <perpass@ietf.org>; Fri, 27 Sep 2013 10:19:25 -0700 (PDT)
Received: from kopoli (g225191041.adsl.alicedsl.de [92.225.191.41]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LtqTF-1VoWc23g1N-011Xor; Fri, 27 Sep 2013 13:19:21 -0400
From: Hosnieh Rafiee <ietf@rozanak.com>
To: 'Karl Malbrain' <malbrain@yahoo.com>
References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com>
In-Reply-To: <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com>
Date: Fri, 27 Sep 2013 19:19:10 +0200
Message-ID: <003901cebba5$b2762c10$17628430$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJOGj5UkWbfuDhxpmMKtaAoIXGv7QHKq7oDAZ0lsZ0CNxrNyAK3hHhTAo3vF0yYgzAmEA==
Content-Language: en-us
X-Provags-ID: V02:K0:GCVtQAI6ctfCFu0zJFO16Y0KsWCYTbUqUaBlN+Mv0s0 /Li6t4+itdfapuKmu0B+ItNk3tJQnNotaTuuVifZRXXTMmO8OT FKhW54xITf1d4hQAmVebcgtuqxH9VcIqTcD2AGdWOP/+LGQur2 NiO+Oax6JKgYXSDQprgzszU/mRu8Y7E5GxljAb6TIAy+lIuSt3 p8x9PUlnCBo3xbInF1DtrBawc98+sV3OxwuAZidfSQ8CKl24nY SqA0ILHJdA6zsQo7jQPDF2DVeJwIQB7oYJ5IGSPxVsYDvlldgh knH+OfPp99GyV9DRFn0VF+yQ5h2eEM3Tx1F2ScwldKySkZRPCy sIj5RSFncs75p3Qg7cKg=
Cc: 'perpass' <perpass@ietf.org>, 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>
Subject: Re: [perpass] DNS confidentiality
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2013 17:19:44 -0000

>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