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

[Paul Hoffman <[e-mail]>]

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

Again, some folks might want to take the risk of a hierarchical failure in order to get additional authentication of data beyond what DNSSEC gives you. If so, a document stating that use case and a protocol to go with it would help find who else wants that.

--Paul Hoffman