Subject: Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

From: Peter van Dijk <[email-masked]>
Date: Wed, 03 Jun 2020 15:08:42 +0200

Hello Christian,

On Sat, 2020-05-30 at 23:00 -0700, Christian Huitema wrote:
> I am wondering how using the signalling that you propose affects
> experimentation with DoQ? I assume that with your proposal, we could
> either have several DS records with different "algorithm" values, or a
> single record with a flag somewhere stating that both TCP/DoT and
> UDP/DoQ are supported. Have you thought about that?

We have definitely thought about that! The way this signaling protocol is structured means that we cannot see DNSKEY flags until we have established some encrypted connection (in our case, DoT). So flags are out. I think it would be simplest to allocate one 'algorithm' number per protocol. This would also allow protocols other than DoT to perhaps use the various DNSKEY/DS fields for different semantics.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Paul Wouters <[email-masked]>
Date: Wed, 3 Jun 2020 11:51:07 -0400 (EDT)

> We have definitely thought about that! The way this signaling protocol is structured means that we cannot see DNSKEY flags until we have established some encrypted connection (in our case, DoT). So…

I had a discussion with Viktor Dukhovni about the concepts of the draft.

We kind of came to the following conclusion:

If you need EPP and/or Registry and Registrar support for new things,
this is not really going to get deployed at scale. (and we need scale
to hide)

Syncing between domain owner and nameserver operator for public keys is
basically impossible. While it might work manually for one domain,
imagine GoDaddy or Cloudflare wanting to change their DoT key. They have
to get all their domain DS records updated. We can hope for CDS, but is
that realistic?

All of the draft (storing DoT signal plus pubkey in DS record) is
basically the same as storing this in a TLSA record at the nameserver
name, except it saves a few RTTs. But saving those RTTs is really not
that important if you do this at the large nameserver hosters, for which
a recursive presumbly already has a working DoT connection open because
it is serving so many more other domains.

It really makes much more sense to signal the capability of nameservers
with nameservers, and not with the domains they serve. Then if someone
uses ns0.nohats.ca, ns1.cloudflare.com and ns2.godaddy.com, those
hosters can all maintain their keys themselves and update their
nameservers without needing to inform or get consent from their millions
of domain name owners.

So we kind of concluded this was a neat hack, but we shouldn't really
think it leads to realistic at scale stable deployments.

Let's just use TLSA records on the nameservers. It is logically where
this information is authoritative for.

Paul and Viktor

---

From: Robin Geuze <[email-masked]>
Date: Tue, 9 Jun 2020 10:52:44 +0200

Hello Paul,

I wanted to take a step back and explain the reasoning behind this 
implementation and why we didn't pick a different implementation.

So lets start at the beginning, why do we want to encrypt the 
communication between then resolvers and the authoritatives in the first 
place. There are two main reasons for encrypting things. One is 
authentication. DNSSEC already covers this aspect, at least in the sense 
of data authentication, it does not guarantee sender authenticity, I'll 
come back to this aspect later. One important aspect of the way DNSSEC 
works is that the parent zone is assumed to be trustworthy. We use that 
same assumption, since going around it would require a completely 
separate system, not unlike the CA system.

So the second reason to encrypt things is confidentiality. This is what 
the draft is meant to accomplish. Ideally this would mean we would get 
encryption all the way from the root to the eventual authoritative 
nameserver. This seems unlikely, so for this draft, and any other 
efforts to use DoT, we also need QNAME minimization to be used. To 
ensure confidentiality we need to ensure that the nameserver we are 
talking to is the actual nameserver we want to talk to. Like I said 
before DNSSEC does not offer that guarantee, primarily due to the fact 
that while DS records are signed in the parent zone, NS records are not, 
and thus can easily be spoofed by an attacker.

So we need some way to identify the nameservers we should talk to. 
Luckily we already have a mechanism for this, TLSA! So the simplest way 
to implement this would be to just put a TLSA record at 
_853._tcp.<nameserver>. There are a few problems with this approach 
though. Like I said before NS records are not to be trusted coming from 
the parent, this means that the TLSA record you get is initially not 
trustworthy either. You can establish the authenticity by requesting the 
NS records from the child as described in 
draft-huque-dnsop-ns-revalidation. This approach could work. But 
depending on the data you are trying to request it could lead to a 2 
times increase in queries at the very least, if you chain a bunch of 
nameservers that have yet more nameservers it at some point becomes 
problematic, because you need to request the TLSA record for each of 
them. And mind you, this slow down would be for all domains, not only 
those supporting DoT.

So a much cleaner, and more efficient sollution, would be to put a TLSA 
record for the specific domain somewhere. Ideally this would be in the 
parent zone, for example on a _dot label. However, that would mean that 
registry would need to implement a completely new concept, we would need 
a new EPP RFC, which knowing the average deployment time for new 
technologies by registries, would mean we would be done by the time hell 
is frozen over.

Another solution would be to put the TLSA record in the child zone. This 
could work, it would require only 2 additional queries (QNAME 
minimization remember). However, the downside is that your initial 
communication with the authoritative will still be plain text. You could 
solve this by putting a chain in the TLS handshake, however you would 
still need some way to signal that DoT should be attempted in the first 
place, otherwise resolvers would be wasting a lot of time probing which 
authoritatives support DoT.

So we are back to ideally signaling something via the parent. The only 
way to do this securely and without registries having to make large 
changes would be to use the DS record. The simplest way to accomplish 
this would be to just add a dummy DS record with an algorithm DoT. 
However, that still leaves the problem of getting some way to 
authenticate the sender. We could use the methods described above, 
however the problem of the initial communication remains. Stuffing the 
TLSA chain into the TLS Hello would solve that, but it would be a very 
complex solution to a simple problem.

This is where our idea comes from. “Hey, if we are going to be abusing 
the DS record anyway, why not put a hash of the key in there”. It is a 
simple solution, it will most likely be relatively easy to implement for 
registries (they only need to add a new algorithm number in some cases, 
the hashing method remains the same), and the amount of code needed in a 
DNSSEC resolver is minimal. It also requires no extra queries, which is 
a nice bonus.

So in summary, we think this solution is the simplest, and has the 
highest chance of deployment, due to it requiring minimal effort from 
all parties involved. Other solutions are definitely possible, however 
this is as far as I call tell the only one, outside TLSA records in the 
parent, that allows full start to finish encryption.

Regards,

Robin Geuze

On 03-06-2020 17:51, Paul Wouters wrote:
>> We have definitely thought about that! The way this signaling 
>> protocol is structured means that we cannot see DNSKEY flags until we 
>> have established some encrypted connection (in our case, DoT). So 
>> flags are out. I think it would be simplest to allocate one 
>> 'algorithm' number per protocol. This would also allow protocols 
>> other than DoT to perhaps use the various DNSKEY/DS fields for 
>> different semantics.
>

---

From: Shumon Huque <[email-masked]>
Date: Tue, 9 Jun 2020 12:37:43 -0400

On Tue, Jun 9, 2020 at 11:49 AM Robin Geuze <[email-masked]> wrote:
[...]

> parent, that allows full start to finish encryption.

Hi Robin,

I can certainly understand the reason for repurposing/abusing the DS record
for this.

I think TLSA in the child zone could be made to work though, so I think
it's
still worth thinking about some more. Here's my suggestion:

Place the TLSA record at the zone name, i.e. at the apex of the child zone,
rather
than at the NS server names: _853._tcp.example.com/IN/TLSA.

That solves the name authentication problem because the nameserver names
aren't authenticated in the referral, but the zone name is authenticated
via the
signed DS RRset.

We'd still want to have per server certificates/keys since if any single
name
server is compromised, we want to be able to surgically rekey only the
compromised server without having to rekey the entire NS set. But this is
easily done by having multiple TLSA records in the set - only one has to
match.

The initial bootstrapping problem can be addressed by using the TLS
DNSSEC chain extension, which can deliver the zone's TLSA
RRset on first contact, in-band in the TLS handshake. You mention the
possibility of "stuffing the TLSA chain in TLS" - I wanted to make sure
you knew the design work for this mechanism is already done:

   https://tools.ietf.org/html/draft-dukhovni-tls-dnssec-chain-01

(I do understand if people might balk at this being quite complex ..)

Using the TLSA RR means that we can now support the full semantics
of TLSA: EE cert, auth, local TA issued cert, or PKIX/WebPKI constraints.

That leaves the secure capability discovery problem. We could still use
a new DS algorithm for this - only a 1-bit signal is needed, so it minimizes
the abuse, and allows the full complement of TLSA capabilities to work.

Shumon Huque

---

From: Peter van Dijk <[email-masked]>
Date: Tue, 09 Jun 2020 19:26:24 +0200

Hi Shumon,

On Tue, 2020-06-09 at 12:37 -0400, Shumon Huque wrote:
> I think TLSA in the child zone could be made to work though, so I think it's 
> Place the TLSA record at the zone name, i.e. at the apex of the child zone, rather
> aren't authenticated in the referral, but the zone name is authenticated via the
> signed DS RRset.

What SNI do you then use when connecting to a name server?

>    https://tools.ietf.org/html/draft-dukhovni-tls-dnssec-chain-01

I know that that is exactly what Robin referred to :)

> of TLSA: EE cert, auth, local TA issued cert, or PKIX/WebPKI constraints.

No, because you don't know the name server names with certainty, so you're still limited to pinning the key, the last cert in the chain, or using a private CA. WebPKI most certainly is out, because ns.attacker.org could also get a cert from the same public CA.
 
Kind regards,

---

From: Shumon Huque <[email-masked]>
Date: Tue, 9 Jun 2020 13:44:00 -0400

> What SNI do you then use when connecting to a name server?

Well, the client could just use the zone name as the SNI, no? You can assign
certificates with the same name but different keys to each of the
nameservers.
Or if the administrator is willing to do shared certificates/keys, that
would
work too.

> I know that that is exactly what Robin referred to :)

Ok, I just wanted to make sure.

> No, because you don't know the name server names with certainty, so you're
> still limited to pinning the key, the last cert in the chain, or using a
> private CA. WebPKI most certainly is out, because ns.attacker.org could
> also get a cert from the same public CA.
>

Here again, if the protocol expects only the zone name, we could
adapt. For example, I could deploy a DANE-TA CA, and use that to
issue individual certs for the zone name. So I don't think we are
actually limited to just pinning the EE cert's keys (even if that may
turn out to be the most popular deployment choice).

Shumon.

---

From: "John Levine" <[email-masked]>
Date: 9 Jun 2020 14:31:22 -0400

>certificates with the same name but different keys to each of the

That sounds quite painful for servers that serve hundreds or thousands of zones.

I am assuming these would be self-signed certs. If you want them
signed there's an additional bootstrap problem since the CA everyone
uses, Let's Encrypt, needs working DNS to sign a cert.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 9 Jun 2020 15:21:05 -0400

On Tue, Jun 9, 2020 at 2:31 PM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:

That's a good point John. It might pose an impediment for them. Anyway,
I'm not suggesting we adopt my idea yet. I'm just trying to talk through the
possibilities and pros & cons first.

> uses, Let's Encrypt, needs working DNS to sign a cert.

My assumption is that most would be self signed, or self-issued by the
domain (DANE-TA). I did mention the possibility of supporting the
PKIX modes earlier too, but now that I think about it, there are
additional issues there. An org may be willing to handout public CA
issued certs for their main domain name to outsourced nameserver
operators. So to be acceptable, this would need to have more
compartmentalized security properties, such as the use of things
like SRVName SAN or similar application specific certificate identities,
which rules out public CAs, since none of them support those.

Shumon.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Jun 2020 16:33:52 -0400 (EDT)

On Tue, 9 Jun 2020, Robin Geuze wrote:

> So lets start at the beginning, why do we want to encrypt the communication 
> between then resolvers and the authoritatives in the first place. There are 
> two main reasons for encrypting things. One is authentication.

I disagree. Setting up a TLS connection to a trusted source for DNS data
does not mean I want or should need to blindly trust that source. DNSSEC
(origin authenticity) is orthogonal to transport security. Setting up
DoT - especially between recursive and authoratative DNS servers has
nothing to do with authentication. For that, we can only rely on DNSSEC.

> important aspect of the way DNSSEC works is that the parent zone is assumed 
> to be trustworthy. We use that same assumption, since going around it would 
> require a completely separate system, not unlike the CA system.

I agree.

> So the second reason to encrypt things is confidentiality.

That is the only reason. The document Introduction Section also really
only mentions "no protection against snooping".

> This is what the 
> draft is meant to accomplish. Ideally this would mean we would get encryption 
> all the way from the root to the eventual authoritative nameserver. This 
> seems unlikely, so for this draft, and any other efforts to use DoT, we also 
> need QNAME minimization to be used.

I agree.

> To ensure confidentiality we need to 
> ensure that the nameserver we are talking to is the actual nameserver we want 
> to talk to. Like I said before DNSSEC does not offer that guarantee, 
> primarily due to the fact that while DS records are signed in the parent 
> zone, NS records are not, and thus can easily be spoofed by an attacker.

The draft does not actually do this, because it does not verify at the
child that the parent didn't make up the special DS record (See my MAY
vs MUST disussion)

> So we need some way to identify the nameservers we should talk to.

If you trust the parent TLSA connection and the parent to produce the right
content, then you do identify the nameservers already despite its lack
of RRSIGs, if you connected to that parent securely (and privately).
If you do not trust the parent, they can just give you any DS record they
want, pointing to their own (or their government's) DoT servers.

> Luckily we 
> already have a mechanism for this, TLSA! So the simplest way to implement 
> this would be to just put a TLSA record at _853._tcp.<nameserver>. There are 
> a few problems with this approach though. Like I said before NS records are 
> not to be trusted coming from the parent, this means that the TLSA record you 
> get is initially not trustworthy either.

This is incorrect. The TLSA lookup of the _nameserver_ name is
independent of the lookup of the _domain_ you are doing, for which
you get the (unsigned) NS records. So the TLSA record is trusted. What
you meant to say is the NS glue records are untrusted, and I agree.
But they are just as untrusted as the DS record, because it is the
same entity publishing them - the parent. And we assume we have a secure
and authenticated and private connection to that parent.

Sure, you can (MAY or MUST) confirm the DS record with a child's CDS
record, but unfortunately doing that query is where you would leak
the domain name you are trying to hide when talking to this target
nameserver over DoT via the special DS record. So that does not help
you against a malicious parent. So you might as well trust the unsigned
NS and signed DS records.

> You can establish the authenticity 
> by requesting the NS records from the child as described in 
> draft-huque-dnsop-ns-revalidation.

An attacker might not be able to give a false answer, but they don't
need to. They just needed your query for you to lose your privacy.
If you query for any child zone information at what you _think_ is the
nameserver, you have leaked that information to that nameserver
operator. Even if it is the wrong one.

> This approach could work. But depending on 
> the data you are trying to request it could lead to a 2 times increase in 
> queries at the very least, if you chain a bunch of nameservers that have yet 
> more nameservers it at some point becomes problematic, because you need to 
> request the TLSA record for each of them. And mind you, this slow down would 
> be for all domains, not only those supporting DoT.

My argument against the drafts focus on reducing RTTs was that if you
are making these queries to nameservers serving so few domains that you
do not have those TLSA nameserver records cached, that those nameservers
are serving so few domains that just revealing that you connect to them
reveals the small set of domains hosted there already. You can super
privately connect to ns0.nohats.ca, but there are only 50 domains hosted
there.  It's pretty easy to figure out which one you were going for.

If the domain is at cloudflare, dreamhost, google, amazon, etc, then
those TLSA record queries you would need to do for the nameserver names
are a cost you incur once, and with proper pre-fetching (as for example
implemented with unbound) you would never incur a delaying cost again
after resolving the first domain's DoT nameserver TLSA record. The next
tens of thousands or millions of domains that use that same nameserver
TLSA record require 0 RTT lookups.

> record for the specific domain somewhere. Ideally this would be in the parent 
> zone, for example on a _dot label. However, that would mean that registry 
> would need to implement a completely new concept, we would need a new EPP 
> RFC, which knowing the average deployment time for new technologies by 
> registries, would mean we would be done by the time hell is frozen over.

I agree with this (except for the much cleaner and more efficient parts)

> could work, it would require only 2 additional queries (QNAME minimization 
> remember).

This would not work. Querying for TLSA records in the child zone already
reveals the domain you are interested in. If you are still on an
unauthenticated (but private) DoT channel, you cannot send any query
that would reveal the target domain name.

> However, the downside is that your initial communication with the 
> authoritative will still be plain text. You could solve this by putting a 
> chain in the TLS handshake, however you would still need some way to signal 
> that DoT should be attempted in the first place, otherwise resolvers would be 
> wasting a lot of time probing which authoritatives support DoT.

It is not a "lot of time" for the larger domain hosters which are the
only places where you could hide within the large domain crowds for
anonymity. See above.

> So we are back to ideally signaling something via the parent.

This is the premise I disagree with. And without this premise, this
draft is only about shaving off 1 or 2 RTTs of super large scale
nameservers, and that goal is (in my personal opinion) not worth the
hassle for squaring a round bit of information in a square DS record.

> So in summary, we think this solution is the simplest, and has the highest 
> chance of deployment, due to it requiring minimal effort from all parties 
> involved.

A TLSA record on the nameserver for DoT is simper, and does not need any
RFC so it has a higher chance of deployment.

And another point you don't take into consideration is the previous MAY
vs MUST discussion. To prevent a country wide DoT Firewall being rolled
out by a TLD inserting rogue DS records pointing to their national DoT
firewall, you would have to confirm the DS record at the child. So while
your proposal might win 1 or 2 RTTs, to do it securely, you lose at
least 1 RTT to verify that DS record from the parent at the child.

> Other solutions are definitely possible, however this is as far as 
> I call tell the only one, outside TLSA records in the parent, that allows 
> full start to finish encryption.

Again, you are not making explicit that it is possible using TLSA
records at the nameserver locations as well, except that you don't
like the additional RTTs.

On top of that, you need special support at Registry and Registrar
level for getting "bogus" DS records accepted (via EPP, CDS/CDNSKEY or
registrar/registry webgui. This on its own will prevent wide spread
adoption of this document. Then you have the cases where people spread
their nameserves over different providers, and they will use different
DoT public keys. Imagine being cloudflare and 50 million domains have
DoT public keys in DS records at their parents. As long as one domain
did not update, they cannot update their TLS key on the DoT server.
In reality, they will never be able to change the private key of their
DoT servers. If the public key lives on ns0.cloudflare.com, they can
go ahead and update this whenever it is needed. They just need to update
their own TLSA record.

The TLSA at nameserver solution requires no EPP, no RFC, no synchronization
between nameserver operators or between registries and nameserver
operators and can be implemented right now.

I also initially thought this was a cool idea and worth doing. But as I
said in my email mentioning my discussion with Viktor, we realised
the cost of the complexity added to save perhaps 1RTT are going to
prevent this from being deployable at scale. And without scale, you
don't get the anonymity DoT can provide.

Paul

---

From: Christian Huitema <[email-masked]>
Date: Tue, 9 Jun 2020 20:43:44 -0700

On 6/9/2020 12:21 PM, Shumon Huque wrote:
> On Tue, Jun 9, 2020 at 2:31 PM John Levine <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     In article
>     <[email-masked]
>     <mailto:[email-masked]>>
>     you write:

There are two tests that matter: first, verify that the NS record is
genuine and that the designated server is indeed the server chosen by
the target domain; two, verify that the TLS connection terminates at the
specified server. It is tempting to take a shortcut and merely verify
that the TLS connection terminates at a server authorized by the target
domain, but I don't think that's a good idea. John pointed out a
management issue: the server would have to manage a large set of
certificates, one for each domain it serves. But on top of the
management issue, there are also performance issues and privacy issues.

TLS authenticates the server during the connection handshake. That means
one authentication per connection. In the case of a resolver accessing
several domains served by the same big server, that means establishing
separate TLS connections for each target domain, instead of establishing
just one connection. That will clearly impact performances, but there is
also a privacy aspect. In the absence of SNI encryption, the SNI can be
observed. If the SNI just carries the name of the name server, no big
deal. But if it carries the name of the target domain, the exchange
reveals that this particular resolver queried that particular domain.
Mix that with observation of the traffic to the recursive resolver, and
you have an interesting privacy leak.

In fact, even if SNI encryption is used, you still have a privacy leak.
Third parties can observe that a request to the recursive resolver
triggered a new connection to the authoritative server, and can infer
that the query was for a rarely used domain served by that server. Not
quite as bad as leaking the actual name of the target domain, but still
a piece of information that can be used for further inferences.

It seems prudent to require that a single connection between a recursive
resolver and an authoritative server can be used for requests to all
domains served by that authoritative server. That's better for both
performance and privacy.

-- Christian Huitema

-- Christian Huitema

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 10 Jun 2020 12:07:37 +0200

On Tue, 2020-06-09 at 16:33 -0400, Paul Wouters wrote:
> I disagree.

You could have saved yourself a lot of words by not cutting out the
very next sentence of Robin's email, that said "DNSSEC already covers
this aspect".

> only mentions "no protection against snooping".

There are two main reasons for encrypting things in general. There is
one reason for encrypting things in DPRIVE context. Robin was just
providing some context for his explanation.

> child that the parent didn't make up the special DS record (See my MAY

I'm still chewing on 
https://mailarchive.ietf.org/arch/msg/dns-privacy/v8qUTMNVW_9W25GUXVStr2_Jk-A

If we believe there is a real danger, that verifying with the child
that the DS is correct, fixes, then we should do that. But I have
trouble seeing that that danger is real.

> of RRSIGs, if you connected to that parent securely (and privately).

I think we can currently assume that data from a parent is
authenticated (by DNSSEC) but not private (because there is no DoT to
the TLDs today). Any proposal that wants to support incremental
deployment will have to assume traffic to parents is not private.

> same entity publishing them - the parent.

They are not just as untrusted, and the distinction between them is
core to any discussion about privacy or authenticity.

The DS records, as published by the parent, can be verified against the
parent's DNSKEY; if they verify, we know that we are seeing the DS that
the parent intended to publish. Thus, the DS records are as trusted as
the parent is.

The NS records, as published by the parent, cannot be verified against
anything. They are as trusted as the insecure path between the resolver
and the parent, i.e. not trusted at all.

>  And we assume we have a secure

But we don't have that. All we have today is DNSSEC, which
authenticates the DS but not the delegation NS.

> you against a malicious parent.

The malicious parent saw your query for yourweirdfetish.tld
milliseconds before that anyway. The client-side confirmation DS query
does not leak more than that.

> My argument against the drafts focus on reducing RTTs

The draft does not have a focus on reducing RTTs at all! It just so
happens that, in its current form, it does not add roundtrips, which is
a nice feature. It is not in any way a strict requirement. If currently
unmet requirements need to be met with extra roundtrips, so be it.

> only places where you could hide within the large domain crowds for

Are you suggesting to have -no parent side signal at all-? Because that
won't fly. Resolvers don't have time to go around knocking at DoT ports
to see what happens.

> adoption of this document. 

The document explicitly uses the 'pseudo-DNSKEY'-indirection to make it
very easy for registrars to accept this - no harder than a new actual
DNSSEC signing algorithm. 13/14 have made it in; 15/16 are getting
there; I am sure TBD can get in there too.

> Then you have the cases where people spread

That's a choice - if a domain operator does not read their email, there
can be consequences. The same applies for DNSKEY changes, just at,
granted, a wildly different scale. I'm still hoping that the
operator/registry problem will get fixed in some useful way, like
CDS/CDNSKEY becoming supported in more than two-three TLDs.

> DoT servers.

They can if they combine it with an NS rename, but it's not super
pretty.

> If the public key lives on ns0.cloudflare.com, they can

I'm looking forward to reading a single, complete, coherent description
of that protocol, because I've been unable to piece it together
completely from your various emails - which tells me it does need an
RFC. If there are no roadblocks, and it can be implemented right now,
why isn't it implemented right now?

Kind regards,

---

From: Shumon Huque <[email-masked]>
Date: Wed, 10 Jun 2020 07:55:01 -0400

On Tue, Jun 9, 2020 at 11:43 PM Christian Huitema <[email-masked]>
wrote

> genuine and that the designated server is indeed the server chosen by the
> target domain; two, verify that the TLS connection terminates at the
> specified server. It is tempting to take a shortcut and merely verify that
> the TLS connection terminates at a server authorized by the target domain,
> but I don't think that's a good idea. John pointed out a management issue:
> the server would have to manage a large set of certificates, one for each
> domain it serves. But on top of the management issue, there are also
> performance issues and privacy issues.
>
> observed. If the SNI just carries the name of the name server, no big deal.
> But if it carries the name of the target domain, the exchange reveals that
> this particular resolver queried that particular domain. Mix that with
> observation of the traffic to the recursive resolver, and you have an
> interesting privacy leak.
>

Hi Christian - yes, the zone name leakage issue would necessitate
SNI encryption in this design. Coupled with the fact that real privacy
means hiding in a large crowd (i.e. locating the zone name servers on
large DNS hosters serving thousands of zones, whose name server
names and addresses reveal no obvious connection to the zone name),
and the resulting certificate management issues that John pointed out,
this idea looks less attractive.

The more I think about all the privacy leaks that have to be plugged at
the DNS and application layers, Tor increasingly looks better as a
general purpose solution (either as a network to funnel DNS messages
through, or even better, having zone operators locate authority servers
inside Tor as hidden services). It has a significant performance cost,
but real privacy always does.

Shumon

---

From: Paul Wouters <[email-masked]>
Date: Wed, 10 Jun 2020 09:37:23 -0400

> but real privacy always does.

You don’t really mean tor, but you mean a shared pool of resolvers used by a large group that breaks the one on one relationship between queries and answers.

It’s fine if we connect to that using DoT or DoH.

I said it before, we need to have something like pool.ntp.org for DNS recursives. Where instanced also feed each other and do prefetching. Unfortunately, the competition here is large free DNS providers who kind of do the same thing but for different reasons and for which we don’t know what their privacy and filtering policies will be in 10 years, even if we trust them now.

The problem is detecting and ejecting rogue nodes before they can do real harm.

Paul

---

From: Shumon Huque <[email-masked]>
Date: Wed, 10 Jun 2020 09:59:24 -0400

On Wed, Jun 10, 2020 at 9:37 AM Paul Wouters <[email-masked]> wrote:

> You don’t really mean tor, but you mean a shared pool of resolvers used by
> a large group that breaks the one on one relationship between queries and
> answers.
>

Well, not as good as Tor's onion routing, or real mix networks, but that
would be a step in the right direction. But pervasive network adversaries
that can observe both sides of the traffic and perform traffic correlation
attacks are still a threat.

So, ideally something should be done on the authoritative server side too.
If we configure zones on large shared hosting providers, then the hosting
provider becomes the privacy adversary or the point of coercion.

Shumon.

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 10 Jun 2020 16:16:40 +0200

>>> > The more I think about all the privacy leaks that have to be plugged at the DNS and application layers, Tor increasingly looks better as a general purpose solution (either as a network to funnel DNS messages through, or even better, having zone operators locate authority servers inside Tor as hidden services). It has a significant performance cost, but real privacy always does.

>> You don’t really mean tor, but you mean a shared pool of resolvers used by a large group that breaks the one on one relationship between queries and answers.  It’s fine if we connect to that using DoT or DoH.

> Well, not as good as Tor's onion routing, or real mix networks, but that would be a step in the right direction.

How does this differ from the two already-competing “oblivious DNS” proposals?

I’m generally for them, but to actually offer any security, they require that the ingress and egress nodes be operated by different parties.  Which is fine for _me_, as long as I can find a counterparty, but what about for someone else, who needs to find two parties, and needs some way to ensure that they’re not in cahoots?  Anyway, I like the idea, but I haven’t yet seen any proposals that get much beyond hand-waving about the practical aspects.

                                -Bill

---

From: Shumon Huque <[email-masked]>
Date: Wed, 10 Jun 2020 10:50:24 -0400

On Wed, Jun 10, 2020 at 10:17 AM Bill Woodcock <[email-masked]> wrote:

>
> >>> > The more I think about all the privacy leaks that have to be plugged
> at the DNS and application layers, Tor increasingly looks better as a
> inside Tor as hidden services). It has a significant performance cost, but
> real privacy always does.
>
> >> You don’t really mean tor, but you mean a shared pool of resolvers used
> by a large group that breaks the one on one relationship between queries
> and answers.  It’s fine if we connect to that using DoT or DoH.
>
> would be a step in the right direction.
>

I haven't followed recently. Has a draft been submitted to DPRIVE?

I’m generally for them, but to actually offer any security, they require
> that the ingress and egress nodes be operated by different parties.  Which
> is fine for _me_, as long as I can find a counterparty, but what about for
> someone else, who needs to find two parties, and needs some way to ensure
> that they’re not in cahoots?  Anyway, I like the idea, but I haven’t yet
> seen any proposals that get much beyond hand-waving about the practical
> aspects.
>

Yes, the collusion risk between the ODNS and RDNS operator is a significant
weakness, although I suspect that might be deemed acceptable for many folks.

Shumon.

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 10 Jun 2020 17:08:14 +0200

> On Jun 10, 2020, at 4:50 PM, Shumon Huque <[email-masked]> wrote:

> I haven't followed recently. Has a draft been submitted to DPRIVE?

Not to the best of my knowledge, but I am also not following closely.  It seems to be an idea that people are coming up with.  Uh, independently inventing.

> Yes, the collusion risk between the ODNS and RDNS operator is a significant weakness, although I suspect that might be deemed acceptable for many folks.

It seems to be acceptable for folks who choose to shine the TOR spotlight on their packets.  But that doesn’t make it sufficient for something newly-engineered.

                                -Bill

---

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2020 11:33:35 -0400

>>     That sounds quite painful for servers that serve hundreds or

I think this will work for NS with names in the zone.  Still scratching my 
head about NS in other zones.

On a referral, the parent server sends TLSA records as glue along with 
the NS and DS in the referral.  The client connects to the one of those NS 
and checks the cert with TLSA.  It then retrieves the signed NS and TLSA 
from the child to ensure that they match the unsigned ones from the 
parent.  To resist downgrades, if a client gets a referral without a TLSA 
but finds a TLSA in the child zone, it (wave hands a little) complains and 
reconnects using TLS.

I don't think that leaks anything beyond what you can tell from the fact 
that it's making connections to port 853. It doesn't leak what name is 
being referred.

The bad news is that authoritative servers have to be adjusted to send
TLSA as glue, and registry provisioning systems have to handle TLSA glue 
as well as A and AAAA.

For NS with names out of the zones, I guess the client looks for a TLSA 
when it looks for A and AAAA.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Brian Dickson <[email-masked]>
Date: Wed, 10 Jun 2020 11:55:16 -0700

> head about NS in other zones.

So, this seems to be failing to converge on the obvious aspects of all of
this, particularly scalability and TLS session persistence.

Use the NS name on the delegation (which is unsigned), assume that NS name
has not been altered in transit, and make a TLS connection to that NS
(which hosts the domain the client wants to query.)
If that NS name is in a domain protected with DNSSEC, its TLSA record can
be trusted after validation. At that point, it is then safe to do the
TLS-protected query for the target DNS information.

Doing things this way means resolvers can leverage persistent TLS
connections to the large providers' name servers (to make queries for all
the domains that share an NS), which is a win-win between the resolvers and
auth operators.
(Persistent TLS >> individual TLS connections per query. Or at least
resuming TLS connections versus new TLS set-up.)

However, the first step has a problem:
Without a secure way of obtaining the first element (the unsigned NS name
being used), the only way to confirm the authenticity of that NS name, is
to make a TLS connection to the name server, and getting the apex NS
records for the target zone.
That leaks information to an attacker ONLY if the attacker has successfully
caused the resolver to get the wrong NS name at the first step.

There is a method for preventing that: if the delegating name server (e.g.
TLD) supports DNS-over-TLS-to-Authority (DoTA), and the resolver obtains
the unsigned NS over a TLS connection.
(The other method that comes to mind, is obtaining the delegation zone
itself, e.g. via AXFR, with some method of protecting the data integrity,
such as TSIG, or ZONEMD.)

The details involved in getting the TLSA record for the NS name are left as
an exercise for the reader (but are easy enough to figure out, they're
literally an exercise in 4033/4034/4035.)

The best practice for large providers will likely be to have glueless
delegations for the domain(s) under which these NS names reside, and
possibly having the nameserver names for the domains serving those names,
themselves be glueless (indirectly glued).
I.e. the intersection set of NS values used for the served domains of
customers, and the NS values used for the domains used by the operators,
under best practice should be the empty set, so no glue is needed for
customer domains.

But TL;DR: big providers will want to only use TLSA records for their NS
names, not for their client's, and generally are very unlikely to offer the
ability for clients to use "vanity" name server names for the IP addresses
of their name servers.
(The reason for this is mostly about how EPP handles host records needed
for maintaining TLD glue, and scalability of management of all of that.)

Unsigned NS records for the delegation are a huge problem in the
architecture of DNSSEC, and consequently also for TLS (regardless of
whether TLSA or WebPKI is used -- the problem is the name itself which is
not cryptographically protected.)
DoTA or AXFR (with TSIG or ZONEMD) or other ways of obtaining the unsigned
NS values in such a way as to protect the data integrity are the only
available fix currently.
The long term ideal solution would be to fix the DNSSEC (and possibly DNS)
design, but I don't see that as happening any time soon.

Brian
P.S. This is a general observation, not an assertion of a position of a
particular operators' practice per se.

---

From: "John Levine" <[email-masked]>
Date: 10 Jun 2020 15:29:02 -0400

In article <CAH1iCir5KaEr6JU5exF7VRQ2yYe6xZ-cLmwmXg3yM=[email-masked]> you write:
>the unsigned NS over a TLS connection. ...

Right.  We have to bootstrap somehow and this seems about as good as we can ask for.

>literally an exercise in 4033/4034/4035.)

The principle is easy. What's hard is the Provisioning Crudware(TM)
that will have to be updated to handle TLSA glue. You might see this
as a dealbreaker, with the alternative being to abuse DS or some other
record that we hope the Crudware already handles.

>for maintaining TLD glue, and scalability of management of all of that.)

See above.  It's not just EPP, it's the provisioning system for any DNS server
that delegates a subtree to another server.

R's,
John

---

From: Brian Dickson <[email-masked]>
Date: Wed, 10 Jun 2020 13:59:11 -0700

> >literally an exercise in 4033/4034/4035.)

I wrote "getting" meaning "querying/validating", not setting.

> record that we hope the Crudware already handles.
No, this isn't TLSA glue... this is TLSA below the delegation point for the
authority server's zone (which is serving the NS name and has the TLSA
records for all those NS names).
It's TLSA on the child side of the delegation, which depends on either
trusting, or validating (somehow) the NS record for the delegation for the
zone owner's domain to the providers name server(s).
The TLSA record is for a name which is not subordinate to the zone owner's
domain, it is for a name operated by the DNS provider.

I.e. that is stuff the DNS provider is responsible for, and does not
require the zone owner to deal with.
The zone owner points at the right NS, and other than the initial DS
record, doesn't need to do anything else.

> that delegates a subtree to another server.

The presumption I make is that there is nothing to add for provisioning
this... it is literally piggy-backing on the NS, for getting the name used
for the TLS connection, and getting the corresponding TLSA record.
This still does have the problem to solve, for "protecting" the NS name
which is not signed.
The options I can think of there are DoTA to the TLD, or AXFR with TSIG or
ZONEMD, or direct queries with TSIG to the TLD.
None of these is scalable or nice, and the TSIG one requires de-anonymizing
the recursive operator, or at least registering specific TSIG keys via
unspecified anonymous/pseudonymous methods.

Brian

---

From: "John R Levine" <[email-masked]>
Date: 10 Jun 2020 17:39:11 -0400

> records for all those NS names).

Except that it is in effect glue, because the parent send a copy of the 
TLSA so the client knows what certificate to look for.  The TLSA is also a 
signal that the child supports DoT.

> this...

OK, plan A 1/2 is there's no TLSA glue, the client connects to whatever IP 
the NS purports to be, without trying to validate the certificate at the 
time, then fetches the signed NS and A/AAAA and TLSA and sees if it 
matches what it's seen.

The problem with that is that there is now no signal on the parent side 
that the client should look for DoT in the child.  It might also leak 
more, haven't thought too hard about that.

Regards,