Subject: [dns-privacy] New draft on authenticated recursive <-> authoritative

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Feb 2021 16:20:13 -0800

Hi folks,

I wanted to point people to a new draft by Tommy Pauly, David
Schinazi, Chris Wood, and myself that defines a mechanism
for authenticated resolver<->authoritative communication.

At a high level, the design is to use SVCB to indicate that
a given server supports ADo[THQ]. The expectation is that
the SVCB record would be supplied in additional_data along
with the NS records, allowing you to bootstrap to encrypted
transport without incurring additional transport. More details
in the draft, but a few points might be worth fleshing out
here:

- The basic assumption is that the transport to the parent [0]
  is encrypted, thus preventing attackers from substituting
  NS or SVCB [1].

- The draft is agnostic on how the authorative server, and
  is compatible with either TLSA or WebPKI, though there
  are some details to be worked out if we don't mandate
  one or the other.

We missed the draft deadline, so in the meantime the draft can be
found at:

https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html
https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.txt

Comments welcome, etc.

-Ekr

[0] The root may be somewhat tricky here, but there are
some thoughts in the draft.
[1] For reasons laid out in the draft, if this isn't the
case, I'm not sure it's possible to avoid leaking the name
you are resolving, even with DNSSEC.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 24 Feb 2021 10:26:15 -0500 (EST)

> https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html

The idea seems fine. I guess the advantage of SVCB over TLSA is
that you can define the transport, which is a clear advantage
over trying to figure out which transport to try first, or trying
them all at once.

The disadvantage of using SVCB is that, at least for DNSSEC, you
would need to use another lookup to get the TLSA record. But that
is mitigated when using the TLS tls-dnssec extension.

You talk about adding SVCB to the additional data, but in practise
authoritative prefer small lean answers these days to avoid
amplification attacks, so I'm not sure if this is a reasonable
assumption of the future. But I also do not believe 1RTT for
privacy is too much of a price to pay, so I think this is fine.

So I think the cost for DNSSEC authentication is two lookups, but
as these are for the nameservers, and privacy really only works
for nameservers serving very many domains, I do not think this
cost is a big problem. But I do have some concern on this because
for smaller nameservers (eg ns0.nohats.ca serving only a dozen
zones), it will incur and extra cost. And we are seeing search
engines like google now penalizing PageRank based on responsiveness,
so this could actually effect smaller nameservers and push towards
more centralization. But I don't see a way to avoid this.

>   is encrypted, thus preventing attackers from substituting

SVCB is not served by the parent right? You mean the substitution
would be in a second step after substituting the NS records?

Although an attacker with those powers can probably more easilly
just redirect IP that the NS records point to, so it does not need
to sit in the middle of the connection to the parent.

And the defense against this is of course verifying any NS record
using the signed DS record at the parent and confirming the records at
the child.  This costs an extra lookup but gains you security. Unsigned
child zones are always vulnerable, and I personally find that to be out
of scope to mitigate.

If you are thinking of using tls-dnssec to the nameserver, then
some extra lookups are prevented, which is good. Maybe you can
help the ISE by doing a review of draft-dukhovni-tls-dnssec-chain, as
the ISE is having some trouble trying to get enough expert reviewers.

Note that the draft for tls-dnssec is not https://datatracker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extension
but https://tools.ietf.org/html/draft-dukhovni-tls-dnssec-chain as it is
unfortunately no longer a TLS WG item. We do plan to update the document
based on some feedback of the ISE, but did not make it before the
cut-off.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Feb 2021 10:45:01 -0800

> is mitigated when using the TLS tls-dnssec extension.

Right. That is my assumption.

> assumption of the future.

A basic assumption here is that you are doing TLS to the referring
authoritative. Otherwise things kind of fall apart for reasons laid
out in the security considerations. So in this case I would assume
that amplification is much less of an issue.

> would be in a second step after substituting the NS records?

I was assuming SVCB was served by the parent in additional_data.
But as a practical matter, substituting NS works as well.

> to sit in the middle of the connection to the parent.

Agreed.

> the child.  This costs an extra lookup but gains you security.

Does that work for this case? My reasoning was that it was too late.
For instance, you're looking up example.com and you receive
NS=ns.attacker.example.
At this point (1) the attacker knows you want example.com and (2) you then
have
to query ns.attacker.com for the signed NS records, so ns.attacker.com
learns
it (even if you didn't already know). So this is useful for concealing
whether
you want a.example.com or b.example.com, but not if the only domains anyone
wants are www.example.com and example.com, right?

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Wed, 24 Feb 2021 14:06:21 -0500 (EST)

> that amplification is much less of an issue.

It would be interesting to know if implementors of current DNS software
already use different strategies for populating the Additional Section
based on the transport (UDP, UDP with COOKIE, TCP).

> But as a practical matter, substituting NS works as well.

Oh. I don't see how that can really be done. Because .ca has no way
to publish something for ns0.nohats.ca. You would basically be creating
a new type of GLUE record. That would need support in EPP, RDAP, all
the Registrar WebGUI's etc etc.  I don't think that is realistic.

Additionally, you would be serving out of zone data on an authoritative
server. Which is quite different from a recursive server that is giving
you additional data from a different zone than the QNAME, because it
knows you'll ask for it anyway (and it has that data in its cache).
The auth server has no cache. It would require new code. Again, I don't
think that is realistic. You'd be better of encoding this into another
NS record or DS record - which has been proposed in the past.

> For instance, you're looking up example.com and you receive NS=ns.attacker.example.
> At this point (1) the attacker knows you want example.com and (2) you then have
> to query ns.attacker.com for the signed NS records, so ns.attacker.com learns
> it (even if you didn't already know). So this is useful for concealing whether

It's the price to pay. The only way to avoid that is the somehow encode
the public key of the nameserver in the parent zone, so that you can
verify the TLS connection _before_ you send the DNS query for the target
domain. That works for all zones other than where the nameserver lives
in the same zone (eg TLS to ns0.example.com always reveals you want to
talk to example.com, but TLS to ns0.largeisp.com does not reveal which
domain you are going to query for).

We went through that discussion with overloading the DS record. I
pointed out that there is another attack you need to defend against in
that case. If the TLD is untrustworthy and adds DS records pointing to
its own nameservers that will forward your queries, they will still see
everything. And if you hardware TLS they can censor you as well. The
way out of that is to verify the DS record and the parent with a CDS
copy of the record at the nameserver, and only continue with your real
DNS query after confirmation. This at least forces the rogue parent
to have to modify the DS record set, which we could run DNSSEC
Transparancy on.

It seemed the DS record idea stalled, because the authors didn't really
like the additional RTTs needed. I still think it is the least worst
solution to authenticat the path from parent to child nameserver,
without introducing new RRTYPEs that require new procesing rules
that take years to deploy.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Feb 2021 20:14:10 +0000

The idea of doing discovery in a new type of glue in the parent seems interesting. For the unauthenticated use case, it potentially removes a round trip, and doing so is quite valuable. If the WG likes the idea of new-glue-type-in-parent, Peter and I can add it to the draft covering unauthenticated ADoT to keep the two use cases in sync.

Question: why does this draft use an SVCB record instead of a TLSA record for that new glue? The only advantage I see is that SVCB can indicate the DoH template, but the WG has so far not shown interest in DoH over DoT. If DoH is not desired, using TLSA would give the authenticated use case the key to match against, and do so with the same security properties.

A deeper question for the WG is the draft's elevation of unsigned records received in authenticated TLS as trustworthy. This WG has gone back and forth on this idea over the years, and I thought we ended up with no such elevation. If I'm wrong, or if the the WG shifts back to wanting that, that's great. Peter and I could then make the draft that now covers just unauthenticated DNS actually be about opportunistic DNS (optional authentication).

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Feb 2021 12:44:02 -0800

On Thu, Feb 25, 2021 at 12:15 PM Paul Hoffman <[email-masked]>
wrote:

> The idea of doing discovery in a new type of glue in the parent seems
> interesting. For the unauthenticated use case, it potentially removes a
> round trip, and doing so is quite valuable. If the WG likes the idea of
> new-glue-type-in-parent, Peter and I can add it to the draft covering
> unauthenticated ADoT to keep the two use cases in sync.
>
> Question: why does this draft use an SVCB record instead of a TLSA record
> for that new glue? The only advantage I see is that SVCB can indicate the
> DoH template, but the WG has so far not shown interest in DoH over DoT.

There are (at least) three reasons:
1. Semantically, TLSA does not mean "I support TLS", but rather "if you are
to do TLS, do it this way. SVCB means something different.
2. It's not clear that the certificate binding properties of TLSA are
desirable in the glue in this case, for a number of reasons, including the
"getting out of sync" problem that Ben Schwartz pointed out, and the
possibility that  we will want to use WebPKI.
2. SVCB does not just let you signal DoH versus DoT it also allows you to
signal DoQ, which has obvious advantages. In addition, if it becomes
necessary to signal what kind of credentials the server has. SVCB has a
natural way to add that.

A deeper question for the WG is the draft's elevation of unsigned records
> received in authenticated TLS as trustworthy. This WG has gone back and
> forth on this idea over the years, and I thought we ended up with no such
> elevation. If I'm wrong, or if the the WG shifts back to wanting that,
> that's great.

I don't think it's a matter of "trustworthy" or "untrustworthy", but rather
that if the referring server is untrustworthy than in many if not most
cases there will be marginal privacy benefit to establishing encrypted
transport. The reasons for this are laid out in the security considerations
(
https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html#name-security-considerations)
but briefly  in a great number of cases the resolver just wants to resolve
the A/AAAA/CNAME for the child domain or a trivial subdomain (e.g., "www")
so (1) a malicious referring domain already has this information before it
even responds and (2) the malicious server can still lie about the unsigned
NS records, which one needs to use in order to get the signed NS records,
by which time you've again revealed the child name.

Peter and I could then make the draft that now covers just unauthenticated
> DNS actually be about opportunistic DNS (optional authentication).

I think trying to figure out what edits to make to which drafts is
premature. Let's first decide what we are trying to do and how.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Feb 2021 21:10:26 +0000

On Feb 25, 2021, at 12:44 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Thu, Feb 25, 2021 at 12:15 PM Paul Hoffman <[email-masked] <mailto:[email-masked]>> wrote:
> Question: why does this draft use an SVCB record instead of a TLSA record for that new glue? The only advantage I see is that SVCB can indicate the DoH template, but the WG has so far not shown interest in DoH over DoT.
> 
> 1. Semantically, TLSA does not mean "I support TLS", but rather "if you are to do TLS, do it this way. SVCB means something different.

Fair point. However, given that we get to say what a particular usage of a particular RRtype is, that is not fatal.

> 2. It's not clear that the certificate binding properties of TLSA are desirable in the glue in this case, for a number of reasons, including the "getting out of sync" problem that Ben Schwartz pointed out, and the possibility that  we will want to use WebPKI.

OK. From the wording about authentication in the draft, I figured you would actually want DNS-based public keys, even with the general problem of TLSA and getting out of sync.

> 2. SVCB does not just let you signal DoH versus DoT it also allows you to signal DoQ, which has obvious advantages.

TLSA also lets you signal DoQ. If it didn't, we would have rejected it out of hand.

> In addition, if it becomes necessary to signal what kind of credentials the server has. SVCB has a natural way to add that.

Well, you said that in your draft, but I don't see that as a possibility in Ben's draft. It could be added, but there is no extension mechanism there.

> A deeper question for the WG is the draft's elevation of unsigned records received in authenticated TLS as trustworthy. This WG has gone back and forth on this idea over the years, and I thought we ended up with no such elevation. If I'm wrong, or if the the WG shifts back to wanting that, that's great.
> 
> I don't think it's a matter of "trustworthy" or "untrustworthy", but rather that if the referring server is untrustworthy than in many if not most cases there will be marginal privacy benefit to establishing encrypted transport.

That's a better phrasing than my shorthand; agreed.

> The reasons for this are laid out in the security considerations (https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html#name-security-considerations [ekr.github.io] <https://urldefense.com/v3/__https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html*name-security-considerations__;Iw!!PtGJab4!tX921UZjQGXS55wAOrtbw-opH3qkVrpzieoyLjMLPdY_GagY8gv6l_AiQsvIvAIoiUYWx7ldTQ$>) but briefly  in a great number of cases the resolver just wants to resolve the A/AAAA/CNAME for the child domain or a trivial subdomain (e.g., "www")  so (1) a malicious referring domain already has this information before it even responds and (2) the malicious server can still lie about the unsigned NS records, which one needs to use in order to get the signed NS records, by which time you've again revealed the child name.

That, plus the encrypted channel prevents malicious record substitution.

> 
> Peter and I could then make the draft that now covers just unauthenticated DNS actually be about opportunistic DNS (optional authentication).
> 
> I think trying to figure out what edits to make to which drafts is premature. Let's first decide what we are trying to do and how.

Both can happen at the same time.

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 25 Feb 2021 16:22:23 -0500

On Thu, Feb 25, 2021 at 4:11 PM Paul Hoffman <[email-masked]> wrote:

>
> In addition, if it becomes necessary to signal what kind of credentials
> the server has. SVCB has a natural way to add that.
>
>
> Well, you said that in your draft, but I don't see that as a possibility
> in Ben's draft. It could be added, but there is no extension mechanism
> there.
>

The standard SVCB extension mechanism applies, so this could be defined at
some later time.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Feb 2021 13:25:25 -0800

On Thu, Feb 25, 2021 at 1:10 PM Paul Hoffman <[email-masked]> wrote:

> 1. Semantically, TLSA does not mean "I support TLS", but rather "if you
> are to do TLS, do it this way. SVCB means something different.
>
>

No, because there are existing deployments, so we can't just retcon the
meaning.

> OK. From the wording about authentication in the draft, I figured you
> would actually want DNS-based public keys, even with the general problem of
> TLSA and getting out of sync.
>

The document is intended to be agnostic about WebPKI versus TLSA. Can you
point out what makes you think it favors it?

In any case, it's quite different to have the TLSA records in the parent
and in the server, because the server can ensure they don't get out of sync
with itself in a way that is harder than with the parent.

> signal DoQ, which has obvious advantages.
>
>

I think it depends what you mean by "signal". TLSA can signal the
certificate which is to be expected for a QUIC connection, but AFAICT it
has no way to indicate that the server supports QUIC, whereas with SVCB you
can do this with ALPN (h3, doq). Your draft has a TODO here, so I'm not
sure what you have in mind.

> in Ben's draft. It could be added, but there is no extension mechanism

Huh? You just define a new SvcParamKey:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-03#section-14.3

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Feb 2021 21:45:59 +0000

We can disagree about what the WG can and cannot change, but the are really not necessary. You say that SVCB in the parent glue is sufficient for your needs, and it certainly is sufficient for those of unauthenticated encryption. I think that authoritative SVCB in the child would also be as good of a signal for unauthenticated encryption as the TLSA that we used based on the WG input.

--Paul Hoffman

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 27 Feb 2021 19:51:41 +0200

> No, because there are existing deployments, so we can't just retcon the

I still think that there should be new RRTYPE that lives in nsname node
and carries service info. Putting it anywhere else means it can get out
of sync. Not that it is fully coherent even then, but at least one could
get rid of most coherence issues.

> point out what makes you think it favors it?

I also read the document as seemingly preferring WebPKI (through not
explicitly saying so).

My views of using WebPKI being a very bad idea have not changed:

- WebPKI does not support service scoping.
- WebPKI fundamentially relies on DNS authoritatives, causing circular
  dependency if used for DNS recursive<->authoritative communications.
- WebPKI has the rootstore mess.
- Using WebPKI would cause issues to both DNS system and WebPKI itself,
  due to change mismatch.

> with itself in a way that is harder than with the parent.

All the possibilities of relation between child, parent and nsname are:

1) Nsname is in child zone
2) Nsname is in descendant of child zone.
3) Nsname is in parent zone
4) None of the above.

- Cases 1) and 2) need glue.
- Both 1) and 4) are common.
- gTLDs look to be limited to either 2) or 4).
- ccTLDs can do whatever they want, and at least some do 1).

And it is the nsname node that currently carries the IP addresses of the
nameserver (A/AAAA records).

And it is not obvious to me that contacting nameserer in the clear to
obtain its encrypted transport information (in case child is
authoriative for its nsname) blows the cover: There is no obvious to
me way to tell if it is in-zone nameserver or out-zone nameserver of
another zone. And I consider nsnames as blown anyway.

> sure what you have in mind.

I think that allowing signaling DoH versus DoT and DoH3 versus DoQ is
unnecressary, as DoH(3) seems to only bring complexity over DoT/DoQ,
seemingly without any significant benefits. And I consider already the
complexity of DoQ scary.

- The traffic stands out like sore thumb due to endpoints involved.
- Without server push, DoT and DoH have the same capabilties: out-
  of-order request-response on stream transport.
- Server push is effectively dead, and the only thing it would add is
  allowing sending negative responses without DNSSEC (with suitably
  advanced resolved). But it would be easy to add capability to send
  negative responses to DNS, and such capability would be useful outside
- Similarly, without server push DoQ and DoH3 have the same
  capabilities: full out-of-order request-response. Not sure if HTTP/3
  has server push, but if it does, what it adds would be the same as
  in HTTP/2 case.
 
There may be need for simpler transport optimized for low resource use,
only intended for transporting DNS QUERY messages and their responses.

> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-03#section-14.3

The kinds of credentials I see as possibly useful:

- No credentials (oppurtunistic-only)
- Server will staple its credentials with DNSSEC chain/signature.
  (there should be only one mechanism for this, e.g. subset of
  draft-dukhovni-tls-dnssec-chain).
- Hash of server hostkey.
- Hash of self-signed root certificate.

And there is obviously issues with trusting values if this information
is not protected with DNSSEC, including the case where records are sent
as glue, as glue is never signed.

-Ilari

---

From: Paul Wouters <[email-masked]>
Date: Sun, 28 Feb 2021 22:09:06 -0500 (EST)

> 1. Semantically, TLSA does not mean "I support TLS", but rather "if you are to do TLS, do it this way. SVCB means something

We tried hard to make it mean "You should only use TLS", but the webpki
people freaked out and blocked the DANE WG until this compromise was
reached. In my opinion, any client that publishes TLSA records for a
service means that you should reach it over TLS and hard-fail. No
one really means "you may do TLS but if insecure cleartext is your cup
of tea, that's fine with me too".

> No, because there are existing deployments, so we can't just retcon the meaning.

That would be the retcon of "If you can do TLS, please prefer TLS over
insecure cleartext" instead of the original meaning "This is my TLS. It
is secure but you are welcome to use this completely insecure
version instead - I claim no preference"

> In any case, it's quite different to have the TLSA records in the parent and in the server, because the server can ensure they don't get
> out of sync with itself in a way that is harder than with the parent.

Also, the parent is really the wrong location. For libreswan.org, the
nameserver is ns0.nohats.ca and the parent is .org. Clearly, if
ns0.nohats.ca does TLS, there is no way scalable automated way for
ns0.nohats.ca to tell the .org registry anything. At best, you can
do something with CDS/DS or CDNSKEY/DNSKEY in the zone that communicates
to the parent. But this uptake so far as been non-existig. I don't
see why SVCB would do better. It has all the same problems, in addition
of requiring new DNS Auth server code to be deployed to add SVCB as
either glue records (hard) or as authenticated at the parent records,
which is even harder, because it requires changes to all DNS resolver
code similar to DS - the only child record in existence today that
lives at the parent's side of the zone cut.

All these have been discussed before, and the conclusion was really
that the only way to do this is to either:

1) make it a nameserver name record, not a record that lives at the
paret dns zone.

2) encode 1) using a DS and hope automated CDS starts happening for
this soon.

> TLSA also lets you signal DoQ. If it didn't, we would have rejected it out of hand.

DoQ didn't exist when TLSA was done. TLSA records are discovered based
on their port. If DoQ uses a standard port, then TLSA can be used. You
would have a TLSA for DoQ and a TLSA for DoT. It would not be possible
to do DoH, but as people said, nameserver IP's are public knowledge and
easilly blocked, there is no advantage to using DoH here at all anyway.

> I think it depends what you mean by "signal". TLSA can signal the certificate which is to be expected for a QUIC connection, but AFAICT
> it has no way to indicate that the server supports QUIC, whereas with SVCB you can do this with ALPN (h3, doq). Your draft has a TODO
> here, so I'm not sure what you have in mind.

Yes it does. Let's say DoQ gets ports 453. Your nameserver's DoQ TLSA
would be:

_doq._453.ns0.nohats.ca.	IN TLSA 3 1 <Base64BLOB>

And your DoT would be;

_dot._853.ns0.nohats.ca.	IN TLSA 3 1 <Base64BLOB>

If people dislike that you have multiple DNS queries to find these
services, you could use something like:

_dns.ns0.nohats.ca.	IN TLSA 3 1 <Base64BLOB>

And then within the certificate encode a EKU or SAN in a standarized way
to relay the ports and protocols for encrypted DNS offered.

Paul