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

From: Tony Finch <[email-masked]>
Date: Fri, 6 Nov 2020 00:44:58 +0000

Paul Wouters <[email-masked]> 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.

+1

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Utsire: Northwesterly 4 to 6, becoming variable 2 to 4 later. Moderate
or rough. Rain or drizzle. Moderate or good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Nov 2020 00:59:00 +0000

Brian Dickson <[email-masked]> wrote:
>
> I think a better comparison (better meaning more relevance and closer
> tracking of the transition and operation) would be the transition of SMTP
> to SMTP using TLS without downgrade susceptibility.

Yes. That was made a lot more difficult because it went through an
intermediate step of unauthenticated TLS, so the protocols and
implementations had to be designed to deal with the fact that a very large
proportion of existing server certificates were wrong. I would prefer not
to have to deal with that again.

> First, a simple assertion: DoTA is only possible/available if it is
> configured by the authoritative DNS operator. Thus, the control of the
> state of whether DoTA is available for zones operated by that operator,
> resides entirely with the operator. This also means that, depending on
> how DoTA availability is signalled or detected, the methods of
> correcting faults in the DoTA operation can vary. Thus, selecting
> signalling/detection mechanisms should take the corrective actions
> available into consideration. IMHO this should actually dominate the
> design.

Yes.

> Third, I'll restate it here: The important characteristic is that whatever
> method(s) are used, they need to be completely downgrade resistant to all
> attack mechanisms, and they need to fail safe.

With the caveat that incremental deployment needs to be possible: If a
zone is hosted by multiple authoritative providers, it should be possible
for one of those providers to deploy DoT without the co-operation of the
zone owner or other providers, and without compromising the availability
of the zone.

That implies a zone only gets a guaranteed private transport if all of its
authoritative providers guarantee a private transport.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole: East 4 to 6, occasionally 7 at first. Rough. Showers later. Good.

---

From: Peter van Dijk <[email-masked]>
Date: Sun, 15 Nov 2020 15:08:00 +0100

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.

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

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

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 15 Nov 2020 16:54:14 +0000

> That's quite a far reaching statement, and I believe it likely to be

+1. The analysis in Tony's draft shows that simple assumptions are probably simplistic.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Sun, 15 Nov 2020 12:40:50 -0800

> That's quite a far reaching statement, and I believe it likely to be
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
>

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

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

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

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 16 Nov 2020 11:01:38 +0100

On Sun, 2020-11-15 at 12:40 -0800, Brian Dickson wrote:
> 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]).

Which buys you very little if the name you are looking up is from an
unauthenticated source - like NS names in delegations.

> So, downgrade-resistant, period.

No.
 
Kind regards,

---

From: Brian Dickson <[email-masked]>
Date: Mon, 16 Nov 2020 10:22:35 -0800

On Mon, Nov 16, 2020 at 2:02 AM Peter van Dijk <[email-masked]>
wrote:

> > > > 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.
> > >
Ah, okay, now I understand.

Yes, this is a huge gap in the fundamentals for any privacy architecture
(ADoT), which is rooted in the unsigned nature of NS records regardless of
the security state of a delegation (DNSSEC or not).

This pretty much impacts any solution that relies on either the names or IP
addresses of authoritative servers (the latter served as glue from the TLD).
An on-path active adversary (between recursive and TLD authoritative
server) would be able to modify these unsigned values.
Without any way to obtain them with some degree of protection (transport or
data), there is no path to connecting to the correct server initially over
TLS.

If the domain in question (the delegated domain, not the nameserver
namespace) is DNSSEC signed, it is possible to detect a discrepancy between
the delegation and apex NS records, assuming DNSSEC responses are not
blocked or tampered with.

If the domain in question is not DNSSEC signed, there is no defense against
such an attacker, if the query to the TLD is not protected by transport or
data security.

However, even in the signed zone case, confirming the apex NS records does
require a query to the authoritative server to verify things,
If the IP address used operates on port 853, there is no guarantee the
server responding is the actual authoritative server rather than an
attacker's server, since the name/IP could have been tampered with
initially.

This leads to a few possible conclusions:

   - With no changes to the DNSSEC management of TLDs (protocol and
   implementations), and with no availability of ADoT to TLD servers, an
   on-path active adversary :
      - Can defeat any attempt at privacy (ADoT) for unsigned zones
      - Can at most DOS any privacy mechanism for signed zones
   - The following techniques can alter the prerequisite conditions, each
   of which has deployment/operation concerns:
      - Changes to DNSSEC signing of (at minimum TLD) delegation data (NS
      records and glue A/AAAA records)
         - Many large hurdles to overcome, including standardization,
         implementation, and deployment
         - May not be offered by all (or even any) TLDs
         - Availability of ADoT at TLD servers
         - Protects traffic via TLS
         - May not be offered by all (or even any) TLDs
      - Eliminating the on-path possibility, by obtaining the TLD zone via
      AXFR/IXFR
         - Protecting the TLD zone transfer is possible by either ZONEMD
         signature, or by doing AXFR over TLS
         - May not be offered by all (or even any) TLDs

> > So, downgrade-resistant, period.

I stand corrected.
Downgrade resistant only if the delegation information is protected (NS
names in particular).

Protecting the delegation NS records against an on-path adversary (between
resolver and TLD) does not have any nice solutions.

Brian

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 16 Nov 2020 20:19:54 +0100

On Mon, 2020-11-16 at 10:22 -0800, Brian Dickson wrote:
> Yes, this is a huge gap in the fundamentals for any privacy architecture (ADoT), which is rooted in the unsigned nature of NS records regardless of the security state of a delegation (DNSSEC or not).

Indeed. That's why we designed DOTPIN (whose shortcomings pretty much
come from not being NS-centric!) to not rely on those names.

> This pretty much impacts any solution that relies on either the names or IP addresses of authoritative servers (the latter served as glue from the TLD).
> An on-path active adversary (between recursive and TLD authoritative server) would be able to modify these unsigned values.

Exactly. A TLSA-authenticated ns1.evil.org does you no good.

> Without any way to obtain them with some degree of protection (transport or data), there is no path to connecting to the correct server initially over TLS.

We could twist this into saying that we can solve the problem by also
doing DoT on the root and the TLDs! (But you also mention that below.)

> If the domain in question (the delegated domain, not the nameserver namespace) is DNSSEC signed, it is possible to detect a discrepancy between the delegation and apex NS records, assuming DNSSEC responses are not blocked or tampered with.

Yes - but by then you've already leaked yourdirtysecrets.com to
ns1.evil.org!

> If the domain in question is not DNSSEC signed, there is no defense against such an attacker, if the query to the TLD is not protected by transport or data security.

> However, even in the signed zone case, confirming the apex NS records does require a query to the authoritative server to verify things,
> If the IP address used operates on port 853, there is no guarantee the server responding is the actual authoritative server rather than an attacker's server, since the name/IP could have been tampered with initially.

Yes (examples given above).

> * With no changes to the DNSSEC management of TLDs (protocol and implementations), and with no availability of ADoT to TLD servers, an on-path active adversary :
> * * Can defeat any attempt at privacy (ADoT) for unsigned zones
> * * Can at most DOS any privacy mechanism for signed zones

Yes and yes.

> * The following techniques can alter the prerequisite conditions, each of which has deployment/operation concerns:
> * * Changes to DNSSEC signing of (at minimum TLD) delegation data (NS records and glue A/AAAA records)

I mentioned 'hash of NSSET into DS' in a dprive thread earlier. 
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/
does something like this (including glue, which we don't need for our
problem).

> * * * Many large hurdles to overcome, including standardization, implementation, and deployment
> * * * May not be offered by all (or even any) TLDs

I believe DOTPIN (again, with all its shortcomings) has very few
hurdles in this area.

> * * Availability of ADoT at TLD servers
> * * * Protects traffic via TLS
> * * * May not be offered by all (or even any) TLDs

It's DNSSEC all over again.

> * * Eliminating the on-path possibility, by obtaining the TLD zone via AXFR/IXFR
> * * * Protecting the TLD zone transfer is possible by either ZONEMD signature, or by doing AXFR over TLS
> * * * May not be offered by all (or even any) TLDs

Last time I checked, TLD operators where not very eager to drop whole
zone dumps on the world. Also, some zones are simply too large for
this. Ignoring those issues, yes, ZONEMD and/or XoT would solve the on-
path problem.

> Downgrade resistant only if the delegation information is protected (NS names in particular). 

Indeed, and the privacy properties then still depend on what the NS
names (and their IPs) tell you. (Some of that goes for DOTPIN as well,
of course).

> Protecting the delegation NS records against an on-path adversary (between resolver and TLD) does not have any nice solutions.

I like 'hash of NSSET [in DS]'.

Now perhaps you see why I offered these possibly-useful puzzle pieces earlier:

* https://tools.ietf.org/id/draft-vandijk-dnsop-ds-digest-verbatim-00.txt
* https://tools.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt

Both of these make room for non-hashing variants of 'authenticate data that is unsigned today'.

:-)

(If you'd like to have more puzzle pieces, https://github.com/PowerDNS/parent-signals-dot has some additional semi-rambly thoughts in the area, although most of it has made it into conversations on DPRIVE and DNSOP meanwhile).
 
Kind regards,

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 Nov 2020 23:30:30 +0000

Peter van Dijk <[email-masked]> wrote:
> > scalable, and facilitates DNSSEC signing, at little to no incremental
> > cost and little to no operational complexity
>

Yes. However I think the relative cost of TLSA lookups is much less when a
resolver implements delegation revalidation because then it's fetching
authoritative A and AAAA anyway, so it can fetch TLSA concurrently.

https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/

> Not downgrade-resistant, until NS names in delegations become signed.

Or until the parent nameservers support authenticated encrypted
transports.

Even so I think delegations should be signed.

A (the?) major issue with this whole ADoT effort is the bad trade-off
between a delegation-centric design (where the DoT signal is in the parent
zone) which has really formidable deployment obstacles, and really
troublesome scalability issues; or a DNS-hosting-provider-centric design
which has poor performance and downgrade weaknesses.

If (big if) we think it's worth upgrading the DNS delegation model (and
EPP, and all the registries and registrars, and all the IPAM databases and
user interfaces, and documentation and textbooks), can we also tackle the
scalability problem? By "scalability" I mean the need for a hosting
provider to update NNNNN delegations when a server cert changes. And there
are decades old problems keeping delegation NS and glue and DS records
correct. (A large chunk of the "it's always DNS" meme comes from how hard
it is to understand delegations and update them correctly.) This whole
area is a massive pain in the arse sorely in need of universal automation.

Any serious attempt at improving delegations needs to deal convincingly
with the quesion of why support for CDS, CDNSKEY, and CSYNC is so
appallingly bad.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Utsire, South Utsire: Southwesterly 5 to 7. Rough, occasionally very
rough later. Occasional rain. Good, occasionally poor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Nov 2020 10:01:28 -0500 (EST)

> with the quesion of why support for CDS, CDNSKEY, and CSYNC is so

Because IETF does not enforce sunsets of old stuff. The market has no
strong reason to move to support this new stuff, as there is a first
mover disadvantage with too many players. Look at Cloudflare, who is
very willing to do all these new things, and they are stuck with old
software/people at (sub)Registrars and Registries.

This is also why DNSSEC is not ubiquitous.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Nov 2020 10:14:02 -0500 (EST)

On Mon, 16 Nov 2020, Brian Dickson wrote:

> Yes, this is a huge gap in the fundamentals for any privacy architecture (ADoT), which is rooted in the unsigned nature of
> NS records regardless of the security state of a delegation (DNSSEC or not).

The IP connection to (small) nameservers will always leak information,
even if perfectly encrypted and obtained without privacy. Just by
connecting to say ns1.nohats.ca, any observer knows you are connecting
to either "nohats.ca" or "libreswan.org".

The only way out of that is a distributed decentralized DNS cache. We
have those, but they are under control of commercial enterprises, and
most of them fall under 1 country's government.

> Protecting the delegation NS records against an on-path adversary (between resolver and TLD) does not have any nice

This is basically the same problem as ESNI. Except ESNI fixed it by
pulling information from (encrypted) DNS :)

Paul

---

From: Tony Finch <[email-masked]>
Date: Wed, 18 Nov 2020 18:29:20 +0000

> This is also why DNSSEC is not ubiquitous.

Yes, but I don't mean answer the question of what the difficulties are (we
know the answers, I hope), I mean "deal with", counteract or avoid the
difficulties. Any new work needs to be deployable: the IETF is supposed to
be about running code, after all. If a proposal is heading in a direction
that we know from past experience is not likely to be successful, then it
needs a really solid argument why this time will be different.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole, Lundy, Fastnet: West or northwest 6 to gale 8, occasionally severe gale
9 in Lundy and Fastnet, decreasing 3 to 5 later. Rough or very rough,
occasionally moderate later. Showers. Moderate or good.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 18 Nov 2020 11:12:56 -0800

> Even so I think delegations should be signed.

So, the parental NS records are not authoritative, and thus not supposed to
be signed.

Has anyone ever experimented with how a signed delegation NS would be
handled by resolvers? (This might vary by resolver software and possibly
version.)

The signer field would differ between the delegation RRSIG and the apex
RRSIG (on what would otherwise be very similar RRSETs).
I.e. if you had zone.example.net NS ns1.something.example.com (and
friends), the apex RRSIG would have signer name zone.example.net, and the
non-apex delegation RRSIG would have a different (shorter) signer name.

Actually doing this as a protocol spec change would probably require that
the delegation RRSIGs would need to be cached differently (in the same way
the NS records are cached differently), and used accordingly.

The standardization of DNSSEC was before my time, so I don't know to what
degree this was discussed back then.
As much as making changes to those RFCs would be difficult and potentially
controversial, this might be the path of least implementation difficulty.
The big thing would be the signing overhead on large authoritative
(delegation-mostly) zones.

And I'm not sure whether the DPRIVE use case is enough of a "new
requirement" to justify changing the spec. But I think that is open to
consideration at least.

Fodder for discussion rather than a serious proposal, at least at this
point.

Brian

---

From: Tony Finch <[email-masked]>
Date: Wed, 18 Nov 2020 19:50:40 +0000

> So, the parental NS records are not authoritative, and thus not supposed to

Yes, that was the logic, but it was a mistake :-)

> RRSIG (on what would otherwise be very similar RRSETs).

Yes, like RRSIG(NSEC).

A change of this kind would need an algorithm bump to indicate support for
the new semantics, like the bump from 5 to 7 to indicate support for
NSEC3. This has the caveat that a signer will want to wait for a large
enough proportion of validators to upgrade to support the new algorithms
before the signer bumps its algorithm, because old validators will treat
the new algorithms as insecure.

> requirement" to justify changing the spec. But I think that is open to

Yes, that's why I'm talking about it :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Tyne, Dogger, Fisher, German Bight, Humber: Southwest 6 to gale 8, veering
north 7 to severe gale 9. Rough or very rough, occasionally high for a time.
Rain or showers. Moderate or good.

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 18 Nov 2020 21:36:14 +0100

> to either "nohats.ca" or "libreswan.org".

But not what subdomain, if any, of those you are visiting. I do
recognise that this is on the long tail of things we can try to
protect.

> The only way out of that is a distributed decentralized DNS cache.

I always imagined that, given DNSSEC, we could bittorrent our way out
of this. Then later people imagined we could blockchain our way out of
this - but it hasn't happened yet.

> pulling information from (encrypted) DNS :)

That's "protecting the NS records against snooping", if I understand you correctly. The other problem is protecting the delegation NS records against meddling, for which various partial solutions have been provided but we have zero standardised today.
 
Kind regards,

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 18 Nov 2020 21:42:20 +0100

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/

As I understand the draft, the revalidation can happen in parallel to
the actual query the user is waiting for. Any setup/discovery of secure
transports would have to happen before that, so I'm not sure we can say
'on top of delegation revalidation, TLSA lookups are basically free'.

> Or until the parent nameservers support authenticated encrypted

The design choice that DNSSEC did not make, a long time ago.

> Even so I think delegations should be signed.

It would solve a *lot* of problems.

> which has poor performance and downgrade weaknesses.

I know DOTPIN has been rejected/shelved/not-adopted for the
deployment/scalability reasons you mention, and also because the
problem space was not mapped out well enough yet, but I still wonder if
perhaps it makes sense to have two solutions to the DPRIVE charter -
one with short paths, few extra queries (like DOTPIN), and one that
works well with '500k domains delegated to one party' - with
delegations signed, or a non-pinning signal (that does not take part in
key rollovers) on the 500k domains, etc.

> area is a massive pain in the arse sorely in need of universal automation.

+100. I've referred to this in other threads - if CloudFlare had gotten
anywhere with their attempts to solve the operator / registrant /
registrar / registry disconnect problem, all of this would be so much
easier.

> with the quesion of why support for CDS, CDNSKEY, and CSYNC is so

Yes, or in the broader sense, my previous paragraph.

Kind regards,

---

From: Tony Finch <[email-masked]>
Date: Wed, 18 Nov 2020 22:24:23 +0000

> 'on top of delegation revalidation, TLSA lookups are basically free'.

Yes, this still needs to be thought through more carefully, and measured
in the real world. There are at least a couple of issues that worry me:

  * Exactly how bad is the extra latency?

  * How bad / avoidable are the lurking interop traps?

Likely at least two flavours of the latter: due to asking for TLSA, or
due to deeper iterative resolution into the nameserver's name's zone.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lough Foyle to Carlingford Lough: Southwest 6 to gale 8, veering northwest 7
to severe gale 9, increasing storm 10 for a time in North Channel, decreasing
3 to 5 later. Moderate or rough, becoming rough or very rough, occasionally
high for a time in north. Squally showers. Moderate or good, occasionally
poor.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 18 Nov 2020 21:28:58 -0500

On Wed, Nov 18, 2020 at 3:42 PM Peter van Dijk <[email-masked]>
wrote:

> [...]

At ICANN69's DNSSEC Workshop last month, Steve Crocker issued a
challenge to DNS Operators to organize and become an officially
recognized constituency within ICANN. If that were to happen, then it might
be able to address and solve some of these issues over time, given
adequate engagement.

> Yes, or in the broader sense, my previous paragraph.

At the same workshop, Jim Galvin spoke about some of the structural reasons
why it's challenging for the contracted gTLDs to make progress on supporting
these (and also likely why there has only been adoption at a small number of
ccTLDs, who are non-contracted parties). This was in relation to CDS and
CDNSKEY. As far as I can tell, no-one has shown any interest in CSYNC to
date.

Shumon.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 18 Nov 2020 19:43:40 -0800

On Wed, Nov 18, 2020 at 6:29 PM Shumon Huque <[email-masked]> wrote:

> On Wed, Nov 18, 2020 at 3:42 PM Peter van Dijk <
> [email-masked]> wrote:
>

At the same Workshop, in our presentation I mentioned that we (GoDaddy) are
intent on providing CDS/CDNSKEY support.
This is to work around the logjam which is the RRR system and its
structural limitations.
Specifically, we will support our Registrar customers who are not DNS
customers, by polling them for CDS/CDNSKEY records no matter who hosts
their DNS.
We will then submit those via EPP (which we can do only because we are
their Registrar).

Nothing about this is rocket science, nor is it anything any other
Registrar cannot do.

It's a hack, but it moves the DNSSEC ball forward, and doesn't require any
new DNS "stuff" or Registry changes.

Brian