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

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 7 Jul 2015 14:16:20 +0800

Dear all,

   We have uploded a draft (below) about encryption of message through PKI mechanism over UDP.

  any comments are welcome.

From: internet-drafts
Date: 2015-07-02 17:30

A new version of I-D, draft-zuo-dprive-encryption-over-udp-00.txt
has been successfully submitted by Jiankang Yao and posted to the
IETF repository.

Name: draft-zuo-dprive-encryption-over-udp
Revision: 00
Title: Approach on encrypting DNS message over UDP
Document date: 2015-07-02
Group: Individual Submission
Pages: 10
URL:            https://www.ietf.org/internet-drafts/draft-zuo-dprive-encryption-over-udp-00.txt
Status:         https://datatracker.ietf.org/doc/draft-zuo-dprive-encryption-over-udp/
Htmlized:       https://tools.ietf.org/html/draft-zuo-dprive-encryption-over-udp-00

Abstract:
   This document offers an approach to encrypt DNS queries and responses
   between the stub resolver and the recursive server over UDP to
   protect user privacy.  The public key of the recursive server is
   distributed to the stub resolver through the Certificate Authority
   infrastructure, and the public key of the stub resolver is sent to
   the recursive server together with the DNS query where the public key
   is inserted to the additional section of the DNS query.  Then the
   recursive server encrypts the DNS responses sent to the stub resolver
   with the public key of that stub resolver, and similarly the DNS
   query sent to the recursive server is encrypted by the stub resolver
   with the public key of that recursive server and thus the user
   privacy is protected.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Jul 2015 07:17:22 -0700

The introduction to this draft implies that it has less latency than DNS-over-DTLS, but gives no measurements in the body of the draft. Are such comparisons available so the WG can balance this against the DNS-over-DTLS proposal? Such a comparison is important, given that what you are proposing is a new encryption protocol, as compared to using the well-established DTLS.

--Paul Hoffman

---

From: Ted Hardie <[email-masked]>
Date: Tue, 7 Jul 2015 08:17:27 -0700

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.

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.

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).

thanks again,

Ted

On Mon, Jul 6, 2015 at 11:16 PM, Jiankang Yao <[email-masked]> wrote:

>   *From:* internet-drafts <[email-masked]>
> *Date:* 2015-07-02 17:30
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-zuo-dprive-encryption-over-udp-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-zuo-dprive-encryption-over-udp/
> Htmlized:
> https://tools.ietf.org/html/draft-zuo-dprive-encryption-over-udp-00
>
>
> Abstract:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
>

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 8 Jul 2015 11:28:21 +0800

thanks for your kind comments.
About the latency comparison, we will do more experiments and report it to the WG when it is available.

Jiankang Yao

From: Paul Hoffman
Date: 2015-07-07 22:17
To: yaojk
CC: dns-privacy
Subject: Re: [dns-privacy] New Version Notification for draft-zuo-dprive-encryption-over-udp-00.txt
The introduction to this draft implies that it has less latency than DNS-over-DTLS, but gives no measurements in the body of the draft. Are such comparisons available so the WG can balance this against the DNS-over-DTLS proposal? Such a comparison is important, given that what you are proposing is a new encryption protocol, as compared to using the well-established DTLS.

--Paul Hoffman

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 8 Jul 2015 15:21:03 +0800

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. 

    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

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 9 Jul 2015 00:16:17 -0700

> About the latency comparison, we will do more experiments and report it to the WG when it is available.

A quality DNS-over-DTLS implementation will do TLS session resumption, and refresh its session keys only for forward secrecy.

-d

---

From: Ted Hardie <[email-masked]>
Date: Thu, 9 Jul 2015 11:04:04 -0700

On Wed, Jul 8, 2015 at 12:21 AM, Jiankang Yao <[email-masked]> wrote:

> *[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?

regards,

Ted

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 10 Jul 2015 16:57:15 +0800

From: Ted Hardie
Date: 2015-07-10 02:04
To: yaojk
CC: dns-privacy

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-masked]

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 10 Jul 2015 09:42:54 +0000

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

regards,

________________________________________
[email-masked]

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 10 Jul 2015 10:47:45 +0000

Follow up,

I think I missed a part that look a bit incorrect.
<snip>
a key agreement value encryption (the session key)....
</snip>

Moreover, the use of CA means that all recursive resolvers need to either pay to a public CA to sign their values so that all clients' stub resolver can verify the server or there is a need to manual exchange of this key. I am not sure how much practical is to have a public CA for each single recursive resolvers and what is the cost of this model and if it is manual key exchange then again back to old problem and old story which is trusted anchors 

Best,
Hosnieh

---

From: Ted Hardie <[email-masked]>
Date: Fri, 10 Jul 2015 10:11:00 -0700

Howdy,

On Fri, Jul 10, 2015 at 1:57 AM, [email-masked] <[email-masked]> wrote:

>
> *From:* Ted Hardie <[email-masked]>
> *Date:* 2015-07-10 02:04
> *To:* yaojk <[email-masked]>
> *CC:* dns-privacy <[email-masked]>
> *Subject:* Re: [dns-privacy] Fw: Fw: New Version Notification for
> draft-zuo-dprive-encryption-over-udp-00.txt
> 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.
>
>
​You may want to update section 2.2, then.  I read its description of the
RDATA option as being a separable segment, ​and other readers may be
similarly confused.

Thanks for the clarification,

regards,

Ted

> regards,
>
>
> ------------------------------
> [email-masked]
>
>
>
>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 16 Jul 2015 16:58:55 +0800

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

 
Best,
Hosnieh

From: Ted Hardie
Date: 2015-07-10 02:04
To: yaojk
CC: dns-privacy

regards,

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 16 Jul 2015 09:22:09 +0000

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: [email-masked] [mailto:[email-masked]]
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 ，

Thanks for your comment!

regards

________________________________
[email-masked]<mailto:[email-masked]>

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

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-masked]<mailto:[email-masked]>> wrote:

regards,

________________________________________
[email-masked]<mailto:[email-masked]>