Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Eric Rescorla <[e-mail]>]

On Fri, Oct 30, 2020 at 1:46 PM Paul Hoffman <[e-mail]> wrote:

> On Oct 30, 2020, at 12:32 PM, Eric Rescorla <[e-mail]> wrote:
> >
> >
> >
> > On Fri, Oct 30, 2020 at 10:03 AM Paul Hoffman <[e-mail]>
> wrote:
> > On Oct 30, 2020, at 9:11 AM, Paul Wouters <[e-mail]> wrote:
> >> > I still believe the cost of authenticating a DNS(SEC) server is so low
> >> > these days (with ACME available at no cost and with full automation)
> >> > that this draft is better not done.
> >>
> >> The cost in terms of CPU cycles is indeed low. That is not the cost
> that is being considered when choosing opportunistic encryption. There is a
> real cost to the system if entire zones get server failures due to
> authentication mistakes made by the authoritative servers (not renewing
> certificates, errors in TLSA records, upstream validation problems that
> cause TLSA records not to validate, ...) or resolvers (dropping trust
> anchors that are in use, bad validation logic for TLSA, ...).
> >>
> > How is this different from the transition of the Web to HTTPS?
>
> The DNS data is already authenticated if they are using DNSSEC.


I don't see how this is an operational difference. It's a difference in
value proposition. This whole discussion is predicated on the idea that
encrypting r2a is valuable; if it's not, we can just go home.


Also, because the DNS is hierarchical, even a short-lived authentication
> failure at a particular server will take out the ability to get data for
> all zones beneath that one; this is not an issue in the web.
>

As a practical matter, a TLS failure at a site like Google or Facebook has
a similar kind of impact. But those sites have figured out how to run with
high availability, and I anticipate that the big DNS servers who have a lot
of zones beneath them could do so as well.



> > Sure, there can be misconfigurations of various kinds, but good
> operational practices can minimize these, and in return you get strong
> security.
>
> What extra value is the "strong security"? Is that value worth the risk of
> inability to get data from a zone? In the web world, the decision that the
> value was greater than the risk was based heavily on being able to
> authenticate the data using TLS. We don't have that same balance in the DNS.
>

The value proposition here is the confidentiality of the query. Defending
that against active attacks requires authenticating the server.

-Ekr