Re: [dns-privacy] Fw: Fw: New Version Notification for draft-zuo-dprive-encryption-over-udp-00.txt

[Hosnieh Rafiee <[e-mail]>]

Dear  Zuopeng,

Thanks for your response.

So, if you change your algorithm to use symmetric keys that approach, then it is similar to what CGA-TSIG is doing, for CGA-TSIG either UDP (if the message size doesn’t exist) or TCP can be used as a transport layer.

And if you use DTLS, it appears that it is similar to the other draft related to DTLS,

It appears that I have problem to differentiate your work from the already existing drafts.

Best,
Hosnieh



From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, July 16, 2015 10:59 AM
To: Hosnieh Rafiee
Cc: dns-privacy; yaojk
Subject: Re: RE: [dns-privacy] Fw: Fw: New Version Notification for draft-zuo-dprive-encryption-over-udp-00.txt

Hi ，

As for the performance consideration, we may update this draft: just add a symmetric key into the additional section in the DNS query packet.
Then the recursive resolver will use this symmetric key for encryption and the stub will use it for decryption.
 In this way, we can reduce computational cost with asymmetric keys.

As for the possibility of an attacker to retrieve information about the query from the header, i think it will be no use because there is no user infomation in the header.

The advantages of the draft is that:
- for every single DNS query(not for persistent connections), the resolution latency would be lower because there is no key agreement process.
- the approach in this draft works for both TCP and UDP while TLS only works for TCP and DTLS only works for UDP;
- this approach is easy to implement. If using DTLS, the server need to maintain a session talbe which would be complicated. If using TLS, maximum number  of concurrent connections would be a problem.

Thanks for your comment!

regards

________________________________
[e-mail]<mailto:[e-mail]>

From: Hosnieh Rafiee<mailto:[e-mail]>
Date: 2015-07-10 17:42
To: [e-mail]<mailto:[e-mail]>; yaojk<mailto:[e-mail]>
CC: dns-privacy<mailto:[e-mail]>
Subject: RE: [dns-privacy] Fw: Fw: New Version Notification for draft-zuo-dprive-encryption-over-udp-00.txt
Hi All,

The part of your approach is really familiar to me...carrying public key in the same message and adding it in the additional section, encrypting the DNS message
Have you take a look on https://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig  draft or aware of this work (section 12.4.  CGA-TSIGe (DNS privacy))?

The disadvantages of the draft-zuo-dprive-encryption-over-udp-00 is that
- Using asymmetric encryption for the whole message except for the header.  The performance consideration is not convincing. For approaches like TLS, it only uses public key cryptography for a key agreement. Or for CGA-TSIG, it uses only a random number with defined size as a session key and only encrypt that value.
I had some researches before on the encryption with symmetric and asymmetric algorithms. The performance of asymmetric algorithm is not really comparable to symmetric especially the decryption process. This result in delay for the end system while not fully cover privacy because of DNS header.
- Possibility of an attacker to retrieve information about the query from the header as you use the full header dissimilar to CGA-TSIG


Furthermore, do you think it is necessary of using a new format for keys when there are existing formats such as DNSKEY that all carry public key.

Best,
Hosnieh


From: Ted Hardie
Date: 2015-07-10 02:04
To: yaojk
CC: dns-privacy
Subject: Re: [dns-privacy] Fw: Fw: New Version Notification for draft-zuo-dprive-encryption-over-udp-00.txt
On Wed, Jul 8, 2015 at 12:21 AM, Jiankang Yao <[e-mail]<mailto:[e-mail]>> wrote:

It's also not clear to me, given that the stub public key is sent in the query to the recursive resolver how you avoid an attacker standing up a back-to-back user agent which strips that option, substitutes its own public key, gets the data and then passes it on.  (It may be, of course, that this attack is out of scope).
[Jiankang Yao]
 Yes, the attacker standing up a back-to-back user agent can strip that option, substitute its own public key, get the data and then pass it on.
 but I think that it should be no use because the attacker can not know the contents of the DNS packet send by the stub.
​I think I wasn't clear enough about the attack.  If the attacker strips the option and sends it with its own public key​, it can decrypt the response.  It can send its version in advance of sending the original packet along, so it can see the response and potentially drop packets that match some policy.  (If they are acceptable, it just sends the queued packet along).  It can also be done along side the original packet, to enable tracking without applying policy.  That's mildly detectable, since the recursive resolver would see multiple queries, but it would be pretty easy to obfuscate by generating new client public keys and varying the query interval.
Does that make sense?
[Peng Zuo]
since the whole DNS query packet(except the DNS header) is encrypted by the stub using the public key of the recursive resolver, the dns packet structure becomes invisable to attackers, attackers could not locate the additional section of the DNS query, so i think it would be difficult for the attacker to substitute it with its own key.

regards,


________________________________________
[e-mail]<mailto:[e-mail]>