> -----Original Message-----
> From: dns-privacy <[email protected]> On Behalf Of Paul
> Hoffman
> Sent: Friday, October 30, 2020 4:46 PM
> To: Eric Rescorla <[email protected]>
> Cc: [email protected]
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Revised opportunistic encryption
> draft
>
> On Oct 30, 2020, at 12:32 PM, Eric Rescorla <[email protected]> wrote:
> >
> >
> >
> > On Fri, Oct 30, 2020 at 10:03 AM Paul Hoffman <[email protected]>
> wrote:
> > On Oct 30, 2020, at 9:11 AM, Paul Wouters <[email protected]> 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. 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.
>
> > 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.

This is an important point. Privacy can't increase the risk of a loss of 
availability, especially as we move closer to the DNS root.

Scott

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

Reply via email to