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

["Jiankang Yao" <[e-mail]>]

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