Subject: [dns-privacy] Encrypt the signalings between stub and recursive resolvers under UDP

From: "Zhiwei Yan" <[email-masked]>
Date: Wed, 11 Mar 2015 11:24:55 +0800

Hi, All,
I have a simple idea to support the encryption of the signalings between stub and recursive resolvers under UDP.
My solution is based on asymmetric encryption scheme and the main points are as following: 
   o Firstly, the stub resolver and recursive resolver should generate
      an asymmetric key pair respectively and we denote then as KEY-S
      and KEY-R.  For the KEY-S, the private key is denoted as KEY-S-pub
      and the public key is denoted as KEY-S-pri.  Similarly, for the
      KEY-R, the private key is denoted as KEY-R-pub and the public key
      is denoted as KEY-R-pri.
   o In order to publish the public key of recursive resolver, KEY-
      R-pub can be included in an option of DHCP message or in the RR of
      DNS following DANE protocols.  Anyway, the stub resolver should
      learn the KEY-R-pub during its bootstrap phase and update it
      securely and easily.
   o When the stub resolver sends DNS request message to the recursive
      resolver, the KEY-S-pub should be contained in this message.
      Besides, the DNS request message is encrypted by the KEY-R-pub.
   o After receiving the DNS request message, the recursive resolver
      decrypts the message with KEY-R-pri.  Then the recursive resolver
      records the information in the DNS request message, including the
      KEY-S-pub.
   o When the recursive resolver replies to the stub resolver, it
      encrypts the DNS response message with KEY-S-pub.
  
   Because the DNS request message sent from stub resolver to recursive
   resolver is encrypted by the public key of the recursive resolver,
   only the corresponding recursive resolve can decrypt that DNS request
   message.  In opposite, because the DNS response message sent from
   recursive resolver to stub resolver is encrypted by the public key of
   the stub resolver, only the corresponding stub resolver can decrypt
   that DNS response message.  In this way, the privacy of the exchanged
   messages between stub and recursive resolvers can be guaranteed.

I just want to get some comments from you. 
If you think this solution makes sense, the draft will be published after the IETF meeting.
BR,
Zhiwei Yan

2015-03-11

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 11 Mar 2015 08:31:01 +0100

Hi Zhiwei Yan,

On 03/11/2015 04:24 AM, Zhiwei Yan wrote:
> Hi, All, I have a simple idea to support the encryption of the
> signalings between stub and recursive resolvers under UDP. My
> solution is based on asymmetric encryption scheme and the main
> points are as following:

https://tools.ietf.org/html/draft-wijngaards-dnsop-confidentialdns-03

This draft follows the points you list.  Perhaps, it is one way to
fulfil the details in what you describe?

It was first submitted to perpass, but then moved to the DNSOP WG, and
now, a bit later, it can be considered by the DPRIVE working group.

Best regards,
   Wouter

> o Firstly, the stub resolver and recursive resolver should
> generate an asymmetric key pair respectively and we denote then as
> KEY-S and KEY-R.  For the KEY-S, the private key is denoted as
> KEY-S-pub and the public key is denoted as KEY-S-pri.  Similarly,
> for the KEY-R, the private key is denoted as KEY-R-pub and the
> public key is denoted as KEY-R-pri. o In order to publish the
> public key of recursive resolver, KEY- R-pub can be included in an
> option of DHCP message or in the RR of DNS following DANE
> protocols.  Anyway, the stub resolver should learn the KEY-R-pub
> during its bootstrap phase and update it securely and easily. o
> When the stub resolver sends DNS request message to the recursive 
> Besides, the DNS request message is encrypted by the KEY-R-pub. o
> After receiving the DNS request message, the recursive resolver 
> KEY-S-pub. o When the recursive resolver replies to the stub
> resolver, it encrypts the DNS response message with KEY-S-pub.
> 
> Because the DNS request message sent from stub resolver to
> recursive resolver is encrypted by the public key of the recursive
> resolver, only the corresponding recursive resolve can decrypt that
> DNS request message.  In opposite, because the DNS response message
> sent from recursive resolver to stub resolver is encrypted by the
> public key of the stub resolver, only the corresponding stub
> resolver can decrypt that DNS response message.  In this way, the
> privacy of the exchanged messages between stub and recursive
> resolvers can be guaranteed.
> 
> I just want to get some comments from you. If you think this
> solution makes sense, the draft will be published after the IETF
> meeting. BR, Zhiwei Yan
> 
> 
> 2015-03-11
> 
> 
> 
> _______________________________________________ dns-privacy mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Zhiwei Yan" <[email-masked]>
Date: Wed, 11 Mar 2015 15:58:19 +0800

Hi, Wouter,
Your proposal provides a useful scheme to publish and fetch the public key of the server.
It's the most important point of my solution, I mean, only when the client gets the public key of the server, it can then encrypt the request information and its own public key in the request message.
BR,

2015-03-11 

Zhiwei Yan 

发件人： W.C.A. Wijngaards 
发送时间： 2015-03-11  15:31:15 
收件人： dns-privacy 
抄送： 
主题： Re: [dns-privacy] Encrypt the signalings between stub and recursiveresolvers under UDP 
 
Hi Zhiwei Yan,
> solution makes sense, the draft will be published after the IETF
_______________________________________________
dns-privacy mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-privacy
.

---

From: "Bucuti, Theogene" <[email-masked]>
Date: Wed, 11 Mar 2015 09:01:22 +0000

Wouter,

This is a preliminary test of a solution that is close in functionality to [https://tools.ietf.org/html/draft-wijngaards-dnsop-confidentialdns-03] and Yan's idea, along with some performance comparisons.
First, a special DNS Op Code is used to mark queries in "Discovery mode", allowing a client to indicate its intention to obtain the server's public key while performing normal DNS resolutions.
In response to a query in discovery mode, a server that supports the encryption protocol includes its public key to the response, which the client caches accordingly.
Subsequent DNS transactions may then be protected as follows:
Option A:
(1) Client uses the recursive resolver's public key to encrypt DNS requests, including the client's secret key in each request;
(2) The recursive resolver encrypts the answers with the client's secret key.
Option B:
(1) Same as in [A(1)], with an option to opt in a temporarily cached secret;
(2) If the recursive resolver allows cached secrets, the temporary secret is exchanged during the next transaction; otherwise same as in [A(2)];
(3) With a shared secret, subsequent queries and responses will be encrypted using the shared secret key.

The referenced paper details the options above, with a brief performance comparison in relation to normal DNS. The analysis shows that (B) is about three times slower than normal DNS, but more than two times faster than A.
The problem with (B) is the burden to the server to keep states, which (A) does not have, but (B) avoids using asymmetric encryption in transactions and the inclusion of a client's key in every request.

Can someone let us know what they think about the above protocol?

Thanks,

Theogene.
________________________________________
From: W.C.A. Wijngaards [[email-masked]]
Sent: Wednesday, March 11, 2015 02:31
To: [email-masked]
Subject: Re: [dns-privacy] Encrypt the signalings between stub and recursive resolvers under UDP

Hi Zhiwei Yan,

Best regards,
   Wouter

---

From: Warren Kumari <[email-masked]>
Date: Wed, 11 Mar 2015 05:55:30 -0400

On Wed, Mar 11, 2015 at 3:31 AM, W.C.A. Wijngaards <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Zhiwei Yan,
>

And a reminder to all to please read this draft -- many folk already
have (during the perpass / pre-IETF times) but it will be discussed at
the meeting in Dallas, so re-reading it have the info fresh would be
good.

W

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJU/+81AAoJEJ9vHC1+BF+NUfkQAK+l5gu3bvbFDz5UYTvs2ZAn
> UNsM3WbJocFLBQVqS/Ky/dMX15RxnR1fBn9AwCKn6095hgU8OXjsiwUFx4+J48uI
> 0Oy4OjfgrDchPYh8XnqFUVYmeVFzBwmsqRZnmwxRWoMZGzk4iBARlBBCF9VVW/Kl
> qYREdv4J0GJSMJSQQjZ728+EIsyJqhUr0yNZQ3XaokM9hGNUpy6/IvfzSosmoEeT
> im01bB5Oa4eO3cM+oTu9btzEJueePA8CrBtF98U18IBp0EhhF9lJP7xF/psrsiYx
> p9oip9Y30BDDsYbjacNDdp9c35JRAemLLfQJa2MxW/O7cBiRZsOL3yTZUZ9590xz
> uNh8/B2JCl6hs54hd7cpkuPMPrMhBc39t79n3dwdfgQph0w2M3VmlL/0DIxMeOBv
> ixnVVfIejh/1trUo0q4mb84L2Gq92GFxQ8gwQTgiveEM6Eff6APEoTP6FZ3w9mE5
> UFehPq5EwUjSz9pKWVNQrdojaXNP+CTs5HKYXVKkdh6xah0+J0iP80gp0JBiGM7Y
> 34E0PhXxCm8LdglCbp/v6IDOCTT+O9wGeZ/P21HtFJAv8CW/NWbTRr7trL7N4rYU
> F8tU5Yjaw8SFgug575yqXfv9vacTMCZVKK1S0IfdIvCn+UQl34F5rqDLaE5uStN+
> kwdVXLAxnduq8h5EZ8i7
> =5/cq
> -----END PGP SIGNATURE-----
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 11 Mar 2015 12:11:41 +0000

Looking forward to discussions on the draft in a few weeks.
-- 
Glen Wiley

Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Mar 2015 08:26:13 -0400

The proposal is a reasonable approach and not overly complex. The question
that concerns me though is how the client authenticates the resolver.
Without authentication, encryption is useless because you could be having
the conversation with Mallet.

Using DNSSEC for that is problematic since the credentials in DNSSEC are
designed to be ephemeral. Even PKIX certs, limited to 60 months becomes a
real problem. And both approaches have circular dependency issues.

Another concern that I have is that the protocol has to protect resolver
hosts from a Denial of Service attack. That means that the hosts cannot
perform any function that provides an attacker with 'leverage' unless the
request passes authentication first.

So the first thing I think is necessary in any proposal is to separate out
the problem of how the client-resolution service context is established
from the mechanism used to enhance the DNS packets. The second part of the
proposal is very straightforward. A simple framing scheme using the tools
already present in the TLS toolkit can be devised and implemented in few
hours. Supporting parallel UDP and TCP or even UDP and HTTPS schemes is not
a major overhead.

The hard part is how you decide to set up the initial relationship between
the client and the resolver and how long you want it to last.

---

From: 延志伟 <[email-masked]>
Date: Wed, 11 Mar 2015 21:07:28 +0800 (GMT+08:00)

Hi, Phillip,
You are right. 
In order to make this solution work securely and efficiently. Except the issues you mentioned, the key rollover schemes for both client and recursive server should be designed.
BR,
Zhiwei

在 2015-03-11 20:26:13，"Phillip Hallam-Baker" <[email-masked]> 写道：

>The proposal is a reasonable approach and not overly complex. The question that concerns me though is how the client authenticates the resolver. Without authentication, encryption is useless because you could be having the conversation with Mallet.
>
>
>Using DNSSEC for that is problematic since the credentials in DNSSEC are designed to be ephemeral. Even PKIX certs, limited to 60 months becomes a real problem. And both approaches have circular dependency issues.
>
>
>Another concern that I have is that the protocol has to protect resolver hosts from a Denial of Service attack. That means that the hosts cannot perform any function that provides an attacker with 'leverage' unless the request passes authentication first.
>
>
>
>
>So the first thing I think is necessary in any proposal is to separate out the problem of how the client-resolution service context is established from the mechanism used to enhance the DNS packets. The second part of the proposal is very straightforward. A simple framing scheme using the tools already present in the TLS toolkit can be devised and implemented in few hours. Supporting parallel UDP and TCP or even UDP and HTTPS schemes is not a major overhead.
>
>
>The hard part is how you decide to set up the initial relationship between the client and the resolver and how long you want it to last.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 11 Mar 2015 15:14:51 +0200

> the conversation with Mallet.

Well, not useless, but much less useful.
 
> request passes authentication first.

Denial of Service against network or Denial of Service against server?

The first can be addressed by limiting ratio of outbound to inbound data
before client IP address is verified.

The second presumably entails rate-limiting number of asymmetric key ops
(since even moderate server can handle full-duplex 10Gbps symmetric
encryption).

> hours. Supporting parallel UDP and TCP or even UDP and HTTPS schemes is not

I would split the thing into three layers for recursive service:

1) Server recon

Determine what the server supports, perform validation of server/provoder
public key, determine server IP addresses if needed. Save the results
in client configuration.

Moderate complexity is available here, along with nvRAM programming,
but no secure nvRAM.

2) Association establishment

Use client configuration (from recon) to establish a temporary symmetric
key (association) for encrypting requests and replies.

If request is piggybacked on association establishment, care has to
be taken to avoid DoS (network) attacks and using replay attacks to
decrypt requests.

The complexity here needs to be low. In practicular, no nontrivial
certificate parsing, no nvRAM programming.

3) Symmetric operation

Use established assocation to encrypt DNS requests and replies.

The operation here is essentially constrained, which means extremely
low CPU, pRAM[1] and ROM usage. No nvRAM available at all. Asymmetric
crypto can't be used.

For authoritative service, presumably server recon is done by
querying the parent server and piggybacking requests on assoication
establishment becomes more important.

> the client and the resolver and how long you want it to last.

Also, to note: Relationships involving longer-term secrets on client
are not really feasible without changing the client side a lot since
currently DNS config is public, and all programs are expected to be
able to read it for their own stub resolvers.

[1] 
CPU => Central Processing Unit: Refers to amount of computation done.
sRAM => scratch RAM: Memory that only lasts very short tern.
pRAM => persistent RAM: Memory lasting moderate term (but still volatile)
nvRAM => non-volatile RAM: Memory that persists across restarts.
secure nvRAM => nvRAM with confidentiality protection.
nvRAM programming => Writing to nvRAM.
ROM => Read-only Mmeory: Firmware or program executable image.

-Ilari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Mar 2015 13:25:24 -0400

> Well, not useless, but much less useful.

OK, yes. Promiscuity is good. Everyone is for it nowadays.

What I should have said is that we can't have a protocol that only supports
promiscuity and does not support long term relationships.

> Denial of Service against network or Denial of Service against server?

Both.

> before client IP address is verified.

Well we could pad requests... Or we could respond with a cookie challenge
if the response is too much larger than the request.

But in general, limiting the utility of the DNS is not the way to stop
amplification attacks. Authenticating requests is. That could be as simple
as a cookie or nonce but we should require some authentication as baseline.

> (since even moderate server can handle full-duplex 10Gbps symmetric

Yes, Curve 25519 is fast enough for normal DNS client-resolver security but
not fast enough that the DoS attack vector can be ignored.

> Moderate complexity is available here, along with nvRAM programming,

Agreed. For this I propose using JSON over HTTPS and aligning the protocol
with ACME as far as practical.

I have a draft but I don't particularly care about the details.

> key (association) for encrypting requests and replies.

OK, what I currently do is to establish a Kerberos style key in step 1
which allows me to skip this step. But again, this is not something I am
fixed on. Given the progress in CFRG on ECC, I think using Curve25519 makes
a lot of sense.

> be taken to avoid DoS (network) attacks and using replay attacks to

Yep.

> certificate parsing, no nvRAM programming.

I don't see a need for certs at this level.

> low CPU, pRAM[1] and ROM usage. No nvRAM available at all. Asymmetric

Agreed. At this stage the protocol has to be stateless. So kerberos style
tokens for session description.

> establishment becomes more important.

That part worries me much less as once something is in my DNS resolver
cache I am going to refresh the records automatically on expiry rather than
wait for the first request after expiry.

Cold cache requests are going to be pretty rare with this approach.

> able to read it for their own stub resolvers.

That is potentially an issue on UNIX and certainly makes a good case for
your second stage.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 11 Mar 2015 19:46:24 +0200

> if the response is too much larger than the request.

For network-DOS, allow association to be established, but refuse the
piggybacked query. Real client can immediately repeat the query.
 
> as a cookie or nonce but we should require some authentication as baseline.

You mean level of "can receive packets sent to claimed source?
 
> not fast enough that the DoS attack vector can be ignored.

Now, if one wanted to do verification of client IP before committing real
crypto resources, that would require cookies.

> fixed on. Given the progress in CFRG on ECC, I think using Curve25519 makes

Another reason this step is there is to minimize long-lived secrets,
especially on client.

> I don't see a need for certs at this level.

I was thinking if to do one or two-level key scheme (the load for
server is the same either way). 

> Cold cache requests are going to be pretty rare with this approach.

Of course, there are lots of DNS servers around... 

> That is potentially an issue on UNIX and certainly makes a good case for

Is the DNS config currently secured (as in confidentiality) on Windows?

(not that making daemons / services with private config files is impossible
on either, just something that I think should be avoided in this case).

-Ilari