Subject: [dnsext] please review - DNS data integrity and confidentiality

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 3 Mar 2014 20:35:38 +0100

Dear All,

CGA-TSIG (http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig ) will be
presented as a last item of intarea (Session 2014-03-04 1300-1400: Viscount)

          intarea WG Agenda
          IETF 89
          TUESDAY, March 4, 2014
          1300-1400 Tuesday Afternoon Session I

I ask you all, DNS experts, please review this draft and attend intarea
session (tomorrow , Tuesday, at 13:00 - 14:00). Even though you might have a
meeting, please try to attend the 15 last minutes of intarea since it will
be the last item that will be presented there. Please consider reviewing
this draft so that we have fruitful discussions :-)

For those who didn't read my long note:
The area that this draft covers

- secure authentication during different scenarios especially the
authentication of the resolvers, without extra efforts, and by the support
of this algorithm or during updating PTR or FQDN record in a secure manner.

- privacy and confidentiality: People in IETF are looking for a  solution
for confidentiality as I heard discussion in this group and application
area. This can be a solution for this. This is especially helpful in the
unsecure environment where you want to have a privacy while browsing
different websites. So you need to have a data encryption between the
resolver and your computer. What your computer need to know is only the IP
address of the resolver, CGA-TSIG handle the other parts. :-) 

The other use case for confidentiality is in a zone transfer scenario or
dynamic update. The data exchange between the master and slave should be
encrypted to keep these data from prying eyes.

So, this draft answers to the need of both data integrity and
confidentiality and prevent IP spoofing without extra effort.

Hope to see you all tomorrow :-)
Thanks,
Hosnieh

---

From: Carsten Strotmann <[email-masked]>
Date: Tue, 04 Mar 2014 15:07:08 +0100

Hello Hosnieh,

(I've only responding on DNSEXT, if one of the other lists is more
approriate, let me know).

> CGA-TSIG (http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig ) will be

I've read your draft and attended the INTAREA session today. I'm at this
moment have not a full understanding of the concept, but it is
interesting and there is some need.

Some questions:

11.1 Generation of secret key (Page 17)

> It is possible to use the current DNSKEY RR (RFC 3757) to send the
> public key of the DNS server.

My understanding of the DNSKEY RR is that (at least in the context of
DNSSEC) the DNSKEY RR is bound to a specific DNS zone, but not to a DNS
server. The draft indicates that the DNSKEY is somehow used to
identify/authenticate the DNS server. Which DNSKEY record would that be
(out of which zone)?

> It encrypts this
>   secret key using the DNS server public key. This allows only the DNS
>   server to decrypt this secret key.

This implies some private key being online on the DNS server. Which
private key would that be?

11.2 DNS message generation (Page 17)

> The node MUST encrypt all DNS message sections that required
>   protections using the secret key generated in last section and AES
>   symmetric algorithm. 

It is probably not good to hardcode an particular cipher algorithm
(AES).

Probably more questions will come up once I read the draft again and
work with the proof-of-concept implementation.

Best regards

Carsten Strotmann

-- 
Sent with my mu4e

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 4 Mar 2014 22:56:13 +0100

Hi Carsten,

Thanks a lot for your comments. Please find my answer as follows

> identify/authenticate the DNS server. Which DNSKEY record would that be

The encrypted secret key is sent to the other node in TSIG RR in a same
packet that CGA-TSIG is sent. So, there is no need for extra packet for
sending the secret key. But for key exchange (in the confidentiality
scenario), there is a need to send public key so that the other node can
encrypt this secret key.  I thought to use TKEY (which is not related to
DNSSEC but related to TSIG) but as you mentioned about DNSKEY (The draft
does not talk about this option), there is a need to modify TKEY RR  to
adapt to CGA-TSIG. So, I guess the best option here is something like the
following scenario to avoid any changes to DNS RRs

Node A wants to ask node B for its public key. Node A includes TSIG RR with
the algorithm set to CGA-TSIGe and set the CGA-TSIG data length to zero.
Node B receives this packet and check the algorithm type. Because it is
CGA-TSIGe (CGA-TSIG with encryption), it does not assume to find any query
or update in the DNS packet and consider this packet as asking for its
public key.  Node B, includes his public key in CGA-TSIG data structure of
the packet and set the algorithm type to CGA-TSIGe. Node A receives this
packet, since it was the answer to his own key request, it retrieves the
public key of Node B from CGA-TSIG data structure, generates a secret key,
encrypts this secret key with node B public key and encrypt the whole query
request with this secret key and sign these messages with its own private
key and include its own publickey and other CGA parameters in CGA-TSIG and
sends this message to Node B. Node B Receives this message and process the
verifications and decrypt the packet.

So, in this case we no longer need to use any TKEY in first step as well.

Any thought?

> This implies some private key being online on the DNS server. Which
private
> key would that be?

No it is not a private key. It uses different algorithm and it is only a
random number that generates by Node A. However, Node A uses this value and
AES algorithm (or any other symmetric algorithm) to encrypt the DNS message
and put it back in the DNS sections (update,  prerequisite, etc)

> It is probably not good to hardcode an particular cipher algorithm (AES).

Right. I need to consider an algorithm type in CGA-TSIG data structure for
symmetric algorithm. I will include it to the draft.

> Probably more questions will come up once I read the draft again and work
> with the proof-of-concept implementation.

Thank you again,
Best,
Hosnieh