Subject: [dns-privacy] Opportunistic encryption between recursive and authoritative servers

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Sep 2020 20:38:36 +0000

Greetings. The discussion of encrypting the recursive to authoritative traffic keeps getting bogged down due to lack of use cases. Puneet and I would like to propose a specific use case (the desire to encrypt much more traffic, even if there could be an active attacker in the middle). With that in mind, we wrote up <https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic>. The abstract says:
  This document describes a method for a DNS recursive resolver to use
  opportunistic encryption when communicating with authoritative
  servers.  The method here is optional for both the recursive resolver
  and the authoritative server.  A motivating use case for this method
  is that more encryption on the Internet is better, and opportunistic
  encryption is better than no encryption at all.  Nothing in this
  method prevents use cases that require better encryption.

We would like DPRIVE to adopt this, and we are open to suggestions on how to improve the protocol.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Sep 2020 20:03:00 -0400 (EDT)

> We would like DPRIVE to adopt this, and we are open to suggestions on how to improve the protocol.

And as I've told you before, your use case of "opportunistic encryption"
makes no sense here. The DNS allows for publication of public keys without
any further infrastructure. You need your TLS certificate for encryption
anyway. Why not just stuff that public key into DNS via a TLSA record?

This is not rocket science. We already do TLSA for email at large scale
now. To do it for DNS is the same except it's even simpler because the
protocol we are protecting is the protocol used for authentication of
the encryption.

As the document already indicates, there is NO difference in setup for
the authoritative server. It needs a TLS certificate. It can use humans
of shell scripts to set this up once using self-signed certificates,
or it can just run an ACME client to automate this.  That is, it is
easier to get a public valid TLS certificate for your DNS server, than
it is to install a self-signed one.

On the client, it is doing TLS authentication as part of the protocol
anyway, and just "throwing away the results". So nothing is saved there
from code complexity other than not looking if the CA cert used is in
its local (system) store of trusted certificates.

Opportunistic encryption to authoritative servers is just too silly.

I am strongly opposed to doing this work.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 Sep 2020 00:13:06 +0000

On Sep 11, 2020, at 5:03 PM, Paul Wouters <[email-masked]> wrote:
> makes no sense here.

And many people disagreed with you.

> The DNS allows for publication of public keys without

Primarily because that is only of value to resolvers that are validating, and that's the small minority of resolvers.

Secondarily because "just stuff" leads to errors that will lead to resolvers failing to get answers.

> now.

You somehow missed the word "opportunistic" in that sentence.

> Opportunistic encryption to authoritative servers is just too silly.

Many people disagree.

> I am strongly opposed to doing this work.

You continue to say that without writing up your use case for review in this WG (or anywhere, as far as I can tell). The best way to support your use case it to write it down, not just snipe at those who have written theirs down.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Sep 2020 21:00:14 -0400

> Primarily because that is only of value to resolvers that are validating, and that's the small minority of resolvers.

Which of large resolver operators is not validating ? Which of the stock opensource resolvers is not validating with a default configuration ? 

Arguably the only ones left not validating are phones and we are busy giving them DoH and DoT to servers that do that for them.

I think your argument does not hold.

> Secondarily because "just stuff" leads to errors that will lead to resolvers failing to get answers.

That’s not different from web servers. It’s 2020, if you still require an unencrypted or in authenticated protocol, you are doing it wrong. Surely, we should not be designing for it.

The only reason to do opportunistic encryption is when authentication or identity management is hard. This is simply not true for authoritative DNS servers.

> You somehow missed the word "opportunistic" in that sentence.

SMTP was largely opportunistic due to fear and complexity of getting certificates working. Since ACME that is no longer the case and it is as easy to setup postfix with acme as it is using selfsigned certs. At this point I would also argue against opportunistic for SMTP, although the case for SMTP is stronger due to mail relays within networks that cannot gets a public cert because they are not public.

> You continue to say that without writing up your use case for review in this WG (or anywhere, as far as I can tell). The best way to support your use case it to write it down, not just snipe at tho…

How do I write up a use case of “don’t overengineer for complex crypto that might accidentally skip authentication of your encryption and cause security vulnerabilities to support people who can only create selfsigned certificates for their DNS server” ?

Paul

---

From: James <[email-masked]>
Date: Sat, 12 Sep 2020 15:19:26 +0200

(resending this to the list, apologies Paul)

Thank you for writing this draft. Just two observations:

1. The absence of protocol agility bothers me - whilst I do not think the
use case described in this document lends to DoH in particular being
suitable, DoQUIC and not-yet-existent protocols could also be applicable.
Is there any reason besides simplicity you didn't consider using the ALPN
as identifier?

2. I disagree on the points around authentication and section 2 could be
updated to better encourage adopters to implement matching TLSA records for
the certificate they present during the TLS handshake - with a clear
statement that recursives are not required to query this record type before
TLS negotiation, nor explicitly fail if it mismatches.

- J

On Fri, 11 Sep 2020 at 22:39, Paul Hoffman <[email-masked]> wrote:

> Greetings. The discussion of encrypting the recursive to authoritative
> traffic keeps getting bogged down due to lack of use cases. Puneet and I
> would like to propose a specific use case (the desire to encrypt much more
> traffic, even if there could be an active attacker in the middle). With
> that in mind, we wrote up <
> https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic>.
> The abstract says:
> --Paul Hoffman_______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 Sep 2020 16:33:48 +0000

On Sep 12, 2020, at 6:19 AM, James <[email-masked]> wrote:
> 
> 1. The absence of protocol agility bothers me - whilst I do not think the use case described in this document lends to DoH in particular being suitable, DoQUIC and not-yet-existent protocols could also be applicable.

There is nothing in the current proposal that specifies the protocol that the two sides use. Additional protocol discovery methods can be added; we just didn't have any other desired protocols at this time.

> Is there any reason besides simplicity you didn't consider using the ALPN as identifier?

Simplicity counts. :-) However, if you want to use an ALPN method, this document certainly does nothing to prevent that.

> 2. I disagree on the points around authentication and section 2 could be updated to better encourage adopters to implement matching TLSA records for the certificate they present during the TLS handshake - with a clear statement that recursives are not required to query this record type before TLS negotiation, nor explicitly fail if it mismatches. 

There is no value in opportunistic encryption to use DANE or any other way of authenticating the TLS server. Paul Wouters has said that he does not support encrypting more DNS traffic using opportunistic encryption, but so far has not written up his use case for regular (authenticated) encryption where some DNS lookups would be blocked due to inability to authenticate. Maybe you could write up such a use case and send it to this WG so they can compare use cases?

--Paul Hoffman

---

From: Geoff Huston <[email-masked]>
Date: Sun, 13 Sep 2020 07:27:14 +1000

Paul and Paul (and the WG),

>> Primarily because that is only of value to resolvers that are validating, and that's the small minority of resolvers.

Whats “a resolver”? Is Google’s DNS service one resolver or hundreds? Of Cloudflare’s 1.1.1.1 farm? What about Chinanet’s service where thousands of IP addresses all act in remarkably similar ways? Frankly, any statement about “the majority of” or “the minority of” resolvers is a pretty meaningless statement from such a perspective. Is my recursive resolver at home that answers queries for just me equal in any way to Google’s service which is used by one quarter of the Internet’s users? Yeah they are both resolvers, but thats about it.

> 
> Which of large resolver operators is not validating ?

well we have a good idea of the answer to that question:

Open DNS resolvers that do not perform DNSSEC validation:

114dns (VERY large in China)
dnspai (again, big in China)
onedns
opendns (some instances of Opendns’s cloud, but by no means the entirety)

> Which of the stock opensource resolvers is not validating with a default configuration ? 

I believe there are a few that require the local admin to enable it and the distro has it disabled by default.

> Arguably the only ones left not validating are phones and we are busy giving them DoH and DoT to servers that do that for them.

um, not really. In the US the ISP resolvers that don't validate include AT&T, Cellco, T-Mobile, UUNET, Charter,... It's probably easier to list the major ISPs in the US that do DNSSEC validate : Comcast. In Canada the ISPs resolver systems that don't include BACOM, Rogers, Shaw,…  Further afield, some of the extremely large ISP resolvers in India validate (Reliance Jio), but in China, not.

> I think your argument does not hold.

I find it hard to agree with either assertion about the prevalence of use of DNSSEC validation here.

The argument that DNSSEC is just a minority corner case does not hold water these days - 25% of the world’s users pass their queries through DNSSEC validating resolvers and will not get an answer if the validation fails. A further 10% of users also use DNSSEC validation and then fail over to non-validating resolvers in the event of validation failure. 1/3 of the total user base of today’s Internet use DNS recursive resolvers that perform DNSSEC validation. Thats not a small minority. There is a lot of DNSSEC validation out there for users and a lot of large resolver systems serving these users.

But 2/3 of users do not use DNSSEC validating resolvers. So it's by means the default case for the DNS.

But DNSSEC validation continues an upward trend and given the standard lifetime of IETF work (2 years and 17 days on average for a draft these days) then the numbers for DNSSEC use will only grow. Accordingly, I have far more sympathy with Paul Wouter’s assertion that bringing in yet another mechanism of opportunistic encryption is one more straw-like adornment to the DNS camel (to use my own interpretation of Paul W’s comments) while a TLSA record could perform the same role, obviating the need for opportunistic encryption to authoritative servers.

regards,

Geoff

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 12 Sep 2020 15:42:31 -0700

I think I largely agree with Paul Wouters here.

>From my perspective, in order to enable non-opportunistic
recursive-to-authoritative DNS we need two things:

1. A way to indicate that the server ought to have TLS.
2. A way to authenticate the server when you get there.

As Paul says (2) is a solved problem, either via WebPKI or TLSA
records.

(2) seems slightly more difficult, and I defer to DNS experts, but
I've seen a number of proposals here ranging from the principled to
the unprincipled (naming the server ns-i-speak-tls.example.com), so I
imagine the problem is soluble.

If you use TLSA records, you obviously need DNSSEC validation, but
that doesn't seem like that big a deal if you're already running a DNS
recursive.

If you use WebPKI, DNSSEC *does* help here in that it prevents whoever
served you the NS records for the authoritative from lying to you, but
it's not essential. For instance, if you do TLS to the authoritative
for .com and it refers you to ns-i-speak-tls.example.com, then an
on-path attacker cannot force you to not speak TLS, so this is a strict
improvement.

I don't deny that opportunistic TLS is of *some* benefit, but given
that non-opportunist is much stronger and doesn't seem much harder,
I don't think we should proceed with it. I especially do not think
that we should proceed with a version where both discovery of TLS
support *and* authenticating the server are optional. If we somehow
find that TLS discovery is difficult, then the right thing to do
is something HSTS-like, where the server has to have a valid cert
(or TLSA) but the client may discover that TLS is required through
an insecure path.

-Ekr

On Sat, Sep 12, 2020 at 9:34 AM Paul Hoffman <[email-masked]> wrote:

> > 1. The absence of protocol agility bothers me - whilst I do not think
> the use case described in this document lends to DoH in particular being
> There is nothing in the current proposal that specifies the protocol that
> the two sides use. Additional protocol discovery methods can be added; we
> just didn't have any other desired protocols at this time.
>
> Simplicity counts. :-) However, if you want to use an ALPN method, this
> document certainly does nothing to prevent that.
>
> There is no value in opportunistic encryption to use DANE or any other way
> of authenticating the TLS server. Paul Wouters has said that he does not
> support encrypting more DNS traffic using opportunistic encryption, but so
> far has not written up his use case for regular (authenticated) encryption
> where some DNS lookups would be blocked due to inability to authenticate.
> Maybe you could write up such a use case and send it to this WG so they can
> compare use cases?
>

---

From: "Brian Hartvigsen (bhartvig)" <[email-masked]>
Date: Mon, 14 Sep 2020 21:44:20 +0000

Point of clarification, all OpenDNS/Cisco Umbrella resolvers do DNSSEC validation and enforcement for all production traffic[1]. Silent validation started almost a year ago. Active enforcement (SERVFAIL on validation failure) has been happening since March 10th. If you are seeing something that indicates otherwise, please reach out.

-- Brian

[1] Somers presented on our then current DNSSEC story at DNS-OARC 32 in San Francisco - https://indico.dns-oarc.net/event/33/contributions/751/attachments/724/1228/20200201_DNSSEC_Recursive_Resolution_From_the_Ground_Up.pptx

On 9/12/20, 15:27, "dns-privacy on behalf of Geoff Huston" <[email-masked] on behalf of [email-masked]> wrote:

    regards,

    Geoff

    _______________________________________________
    dns-privacy mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dns-privacy