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
[email protected]
From: Hosnieh Rafiee
Date: 2015-07-10 17:42
To: [email protected]; yaojk
CC: dns-privacy
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 <[email protected]> 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,
________________________________________
[email protected]
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
