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

On Sun, Nov 15, 2020 at 6:08 AM Peter van Dijk <peter.van.dijk@powerdns.com>
wrote:

> On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote:
> > The most unambiguous signal possible, is the presence of a TLSA record
> on _853._tcp.<NS_name>.
>
> That's quite a far reaching statement, and I believe it likely to be
> wrong.
>
>
I think we can move this part of the discussion to the larger
thread/document started by Tony Finch.

> > Using NS names in a separate zone or zones (for each DNS operator) is
> scalable, and facilitates DNSSEC signing, at little to no incremental cost
> and little to no operational complexity
>
> The incremental cost for a resolver (doing a full resolution process
> for the TLSA records of one or more NS names) is not small, and neither
> are the latency costs. For 'popular' name servers, this cost can mostly
> be amortised, leaving the penalty with any domain hosted on a NSset
> that only has a few domains.
>

Okay, so my statement implied "to the operator of the name server(s)", not
the resolvers.

Resolver operators need to make their own decisions on whether to offer
privacy services, including whether there are any limits on which authority
servers they implement those privacy services towards.

I don't believe anyone has stated that there would not be any latency cost
or other cost (e.g. compute) for privacy services.

So, IMHO, any discussion on those costs needs to be done in relation to the
other attributes, such as "correctness" of the proposal.
Correctness would involve things like:

   - accommodating multiple server operators with different privacy
   settings (yes/no)
   - anycast dns server addresses where specific anycast instances may have
   different privacy settings (yes/no)
   - ability to differentiate privacy settings at a zone level via some
   mechanism
   - correct source of truth for privacy settings (i.e. must be the dns
   server operator, not the zone owner, to be the actual source of truth)
      - A clear example of the reason this source of truth is required, can
      be seen in the problem with NS records configured by the zone
owner rather
      than the DNS server operator: lame delegations.
   - cost to authoritative server operators (and scalability)

Again, this discussion should proceed in the other thread (Tony Finch's).

>
> > Using TLSA records at _853._tcp.<NS_NAME> in a signed zone provides an
> unambiguous signal to use optionally TLSA, in a downgrade-resistant manner.
>
> Not downgrade-resistant, until NS names in delegations become signed.
>

That's a moot point.
TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC
6698 section 4.1 (Determining whether a TLSA RRSet can be used MUST be
based on the

   DNSSEC validation state (as defined in [RFC4033
<https://tools.ietf.org/html/rfc4033>]).

So, downgrade-resistant, period. (Use of TLSA presupposes signed, in
other words.)

> (I proposed some solutions for that in other threads; Fujiwara has
> [independently, I think] now written a draft resembling one of those
> solutions
>
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/?include_text=1
> )
>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>