From: Ted Hardie
Date: 2015-07-07 23:17
To: yaojk
CC: dns-privacy
Subject: Re: [dns-privacy] Fw: Fw: New Version Notification for
draft-zuo-dprive-encryption-over-udp-00.txt
Howdy,
A couple of questions. First, the document appears to say that the stub gets
the public key of the recursive resolver from the certificate authority
infrastructure, and it cites RFC 5280; that would tell you how to identify a
public key from within a cert, but I'm not clear on how you expect the stub to
get the cert. Can you explain.
[Jiankang Yao]
Yes, the current version of this draft does not cover how the stub gets the
cert. We will clarify it in the next version.
Second, the draft says this:
If the query name is very common and not
relating to user privacy, the stub resolver can do name resolution
through traditional unencrypted way and thus does not need to
implement the approach proposed in this draft. While if the query
name relates to user privacy, the stub resolver can use the method
presented in this draft to encrypt the DNS queries. And accordingly,
the recursive server also encrypts the DNS response with the public
key extracted from the DNS query.
This provides a flag to attackers on what traffic is "sensitive" and should be
avoided. Also, the draft does not suggest the rate at which the stub should
change its associate public key, but it clearly should do so or it will create
a long-lived association of identity with the queries that impacts privacy.
[Jiankang Yao]
the current mechanism is that stub puts its public key into the DNS packet
encrypted with Public key of the resolver when the stub sends the query to
the resolver each time. so the stub can change its public key anytime before
sending its query.
Yes, it is bett that the draft suggests some rate for the assoicated stub
public key.
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.
thanks a lot!
Jiankang Yao _______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
