[DNSOP] We want to have fruitful discussions - please review

"Hosnieh Rafiee" <ietf@rozanak.com> Fri, 28 February 2014 14:55 UTC

Return-Path: <ietf@rozanak.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 02B461A07B5; Fri, 28 Feb 2014 06:55:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.081
X-Spam-Level: *
X-Spam-Status: No, score=1.081 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FS_WE_WANT=1.629, RP_MATCHES_RCVD=-0.547] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ImCaNTGse3ep; Fri, 28 Feb 2014 06:55:29 -0800 (PST)
Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 12DB31A01E8; Fri, 28 Feb 2014 06:55:29 -0800 (PST)
Received: from localhost (unknown []) by mail.rozanak.com (Postfix) with ESMTP id 7491523E2D51; Fri, 28 Feb 2014 14:55:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at rozanak.com
Received: from mail.rozanak.com ([]) by localhost (mail.iknowlaws.de []) (amavisd-new, port 10024) with ESMTP id nyS8AdK2ueB2; Fri, 28 Feb 2014 15:55:23 +0100 (CET)
Received: from kopoli (g225115060.adsl.alicedsl.de []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 5F1F123E24C1; Fri, 28 Feb 2014 15:55:23 +0100 (CET)
From: "Hosnieh Rafiee" <ietf@rozanak.com>
To: <DNSOP@ietf.org>, <dnsext@ietf.org>
Date: Fri, 28 Feb 2014 15:55:21 +0100
Message-ID: <002101cf3495$1ad2d570$50788050$@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: Ac80lRjPs+oEPGR+Qe6rhNpf40faRg==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/vD8iptW1WHadzjANXWH8CLoyNik
Subject: [DNSOP] We want to have fruitful discussions - please review
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2014 14:55:31 -0000

Dear All,

Since we have a timeslot to present
http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig in DNSOP. I ask you
please review it so that the discussion would be fruitful and we can receive
good comments to improve it and to move ahead.  This draft is not a new one
as many of you already know or heard about it, it was first presented in
IETF 85 and recently in IETF 88 in Int-area. The reason was because it was
more related to DNSEXT and at that time it was going to shut down. It had
several volunteer reviewers and it received some good comments. However, we
would like to receive more comments in case we missed anything that needs to
be addressed or we missed to clarify any section in the draft that needs
more clarifications. Since now the DNS confidentiality is also an important
topic and this proposal could handle it for IPv6 and during data transfer, I
also included a section and explained the required changes to the original

Here again I briefly explain the purpose of this document for those who do
not know about it or who do not know the exact purpose of it:

This proposal is for the cases where DNS uses IPv6 and there is a need to
use a security mechanism for DNS authentication or provide the data
confidentiality for the DNS data during transferring data over the network.
It is possible to use this proposal in different DNS scenarios such as DNS
update, updating FQDN and PTR, or DNS resolving. In this case it is enough
that the verifier node only knows the IP address of the DNS server or
resolver. For DNS update, this IP address can be set manually for the first
time in the DNS configuration file and for other times, the CGA-TSIG can
handle the changes with the proposed specifications. For DNS resolver, it
receives this IP address securely via the option in the router advertisement
message. The implementation of this part is also available. one need to use
a suitable solution for secure authentication purposes while at the same
time decrease the human intervention for the configuration.
CGA-TSIG is the combination of the use of SSAS or CGA as an authentication
purpose for DNS protocol and TSIG. SSAS/CGA is the mechanism which provides
the node with the proof of IP address ownership by finding a binding between
the IP address and the nodes' public key. Since this approach prevent IP
spoofing (in network layer), it also ensures the DNS server or the clients
that the one who is talking with is the owner of this IP address without the
need to check the public key to the root to find out that this public key is
really belong to this node with this IP address. 

So, using this approach can eliminate the need for this check. It can be
also integrated with DNSSEC for this purpose and prevent IP spoofing without
the need to check the keys up to the root level and simplify the key
exchange process. This proposal also can be helpful for resolving scenario
that is now a problem. Since for DNSSEC, exchanging the key of the resolver
is the problem because the resolver must answer to anonymous queries, it is
not easy to exchange the keys of this DNSSEC resolver to all the nodes who
wants to ask this resolver. But with using this approach as I explained
earlier, the IP address of the resolver can be obtained in a secure manner
via the RA message and then since there is a binding between the IP address
and the public key, the CGA/SSAS verification helps to verify this resolver.

There is a recent discussion about privacy and data confidentiality.  This
proposal can also handle data confidentiality during the data exchanged
between two nodes (servers or clients). Since the node knows the IP address
of the DNS server, it can ask the DNS  server to send the node, its public
key. Then the node can encrypt a secret key with this public key and then
encrypt the whole message using this secret key and AES or other symmetric
algorithms. The DNS server then decrypt the secret key with its own private
key and decrypt the whole DNS message by using this secret key. This
provides the data confidentiality during DNS updates or also it can be used
during DNS resolving. (if necessary) 

If you don't know anything about CGA, I try to explain it in a very simple

Note that all values are in hexadecimal

CGA parameters= 

Sha1(CGA parameters) = e584448d597e3c927805fc18250598a1d1b71b46
now set bits u and g and sec value so only the first bytes will change

CGA value= 2784448d

Thank you and looking forward to see you all in our talk. Since I cannot
make it and will not be in London, Erik will present in my place but can
answer some questions and I will also follow it in jabber. I hope to see a
fruitful conversations :-)