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

["Hosnieh Rafiee" <[e-mail]>]

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
proposal.

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
example:

Note that all values are in hexadecimal

CGA parameters= 
e387d788a9e529701ba9baf0bb3694de20051abcab8c7dc000e581e41c6891dd5c06fee6f3ab
149bcf00d18d90534606354b8b8d7511ff90552393f974082732f16b646a97d336190c26d5e1
0347422ebfd6da4036d1e363f9de5c85091448b330ca8b541d246c378de29e9f37b19c072974
2d0a04ac0befe2e5069dd16cea03762b6d621d5d15fbf00131a5ee48f91d5a46396af46d01e6
17010001


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 :-)

-----------smile----------
Hosnieh