Subject: [dns-privacy] DS Hacks

From: Ben Schwartz <[email-masked]>
Date: Fri, 30 Jul 2021 11:30:46 -0400

It seems like there's still interest in DS hacks.  Here's how I would do a
DS hack.

1. Use the VERBATIM hash from
https://datatracker.ietf.org/doc/html/draft-vandijk-dnsop-ds-digest-verbatim

2. Use a new Algorithm Number like
https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-delegation-information-signer-00.
This number is named "DS Glue", and MUST only be used with the VERBATIM
hash.

3. In the digest field, encode one "DS glue" record as follows:

struct DSGlueFakeDigest {
  uint16 rr_type;
  DNSName prefix;  // Labels prepended to the DS owner name.
  uint8[] rdata;
}

DS-glue-aware resolvers ignore any unsigned glue with this RR type and
owner name.

4. For ADoX, place NS records (with a prefix like "ns3.") and SVCB records
(with a prefix like "_dns.ns3.") in the DS glue.

What do you think?

--Ben Schwartz

---

From: Shane Kerr <[email-masked]>
Date: Fri, 30 Jul 2021 18:10:41 +0200

On 30/07/2021 17.30, Ben Schwartz wrote:
> It seems like there's still interest in DS hacks.  Here's how I would do 
> a DS hack.
> 
> <https://datatracker.ietf.org/doc/html/draft-vandijk-dnsop-ds-digest-verbatim>
> 
> https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-delegation-information-signer-00 
> <https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-delegation-information-signer-00>.  

So this is generic, and can store any record. We don't need TTL since 
this is just for glue and really shouldn't be cached, and we don't need 
class because we don't ever need class. 😉

This can't store out-of-bailiwick data, which means we can't secure an 
arbitrary NS RRset this way. Converting DNSName from "prefix" to just 
"name" would allow that. This seems useful as it would eliminate a 
potential means for an attacker to get you to connect to their servers 
(which is, spoofing a reply with a bogus NS RRset, since delegation NS 
are not signed in DNSSEC because DNS is stupid).

> 4. For ADoX, place NS records (with a prefix like "ns3.") and SVCB 
> records (with a prefix like "_dns.ns3.") in the DS glue.

--
Shane

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 30 Jul 2021 12:38:24 -0400

On Fri, Jul 30, 2021 at 12:11 PM Shane Kerr <[email-masked]>
wrote:
...

> "name" would allow that.

> > records (with a prefix like "_dns.ns3.") in the DS glue.

This should say "NS records (with a prefix of ".")".  The NS RDATA is
unconstrained.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Jul 2021 17:34:45 +0000

I'm confused here. Are you saying that the DS owner name for an out-of-bailiwick NS would still be the name of that NS? If so, then it seems that you are asking the authoritative to sign a DS record for which it is not authoritative.

A different design that does not require signing records for which you are not authoritative would be to have the DS owner be that of the zone in question, with the DNSName in your structure being as Shane suggested.

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 30 Jul 2021 13:37:43 -0400

On Fri, Jul 30, 2021 at 1:34 PM Paul Hoffman <[email-masked]> wrote:

> I'm confused here. Are you saying that the DS owner name for an
> out-of-bailiwick NS would still be the name of that NS?

No, it would be the owner name of that NS record, which is the child apex.
This is also the owner name of the DS record.  The name of the NS is in the
RDATA.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Jul 2021 18:09:54 +0000

On Jul 30, 2021, at 10:37 AM, Ben Schwartz <[email-masked]> wrote:
> I'm confused here. Are you saying that the DS owner name for an out-of-bailiwick NS would still be the name of that NS?
> 
> No, it would be the owner name of that NS record, which is the child apex.  This is also the owner name of the DS record.  The name of the NS is in the RDATA.

Sorry that I'm being dense. Having some examples with both in-bailiwick and out-of-bailiwick NSs would be useful (at least to me).

--Paul Hoffman

---

From: Robert Evans <[email-masked]>
Date: Fri, 30 Jul 2021 15:29:17 -0400

If I understand correctly, the encoding could cover any below-the-cut
records in the referral response.

For in-bailiwick response, this would be the child NS rrset, glue A/AAAA
records, and SVCB records:

;; Authority
example.com NS ns1.example.com
example.com NS ns2.example.com

;; Additional
ns1.example.com A 192.0.2.1
ns1.example.com AAAA 2001:db8::1
ns2.example.com A 192.0.2.2
ns2.example.com AAAA 2001:db8::2

There could be a DS record that contains encoded RDATA:
rr_type=NS prefix=<empty> rdata="ns1.example.com"
rr_type=NS prefix=<empty> rdata="ns2.example.com"
rr_type=A prefix=ns1 rdata="192.0.2.1"
rr_type=A prefix=ns2 rdata="192.0.2.2"
rr_type=AAAA prefix=ns1 rdata="2001:db8::1"
rr_type=AAAA prefix=ns2 rdata="2001:db8::2"
rr_type=SVCB prefix=_dns.ns1 rdata="ns1.example.com 1 alpn=dot adox=tlsa"
rr_type=SVCB prefix=_dns.ns2 rdata="ns2.example.com 1 alpn=dot adox=pki"

(Or maybe leave out the A and AAAA records, but that makes it easier for
attackers to trick resolvers into talking to malicious endpoints.)

For out-of-bailiwick response, this would be only child NS records.

;; Authority
example.com NS ns1.other-example.com
example.com NS ns2.other-example.com

;; Additional
<empty>

There would be a DS record that contains encoded RDATA:
rr_type=NS prefix=<empty> rdata="ns1.other-example.com"
rr_type=NS prefix=<empty> rdata="ns2.other-example.com"

This referral conveys no authenticated SVCB (only authenticated NS names),
so encryption-aware recursive resolvers would query for SVCB in parallel
with A and AAAA queries for the name servers.

On Fri, Jul 30, 2021 at 2:10 PM Paul Hoffman <[email-masked]> wrote:

> > No, it would be the owner name of that NS record, which is the child
> apex.  This is also the owner name of the DS record.  The name of the NS is
> in the RDATA.
>
> Sorry that I'm being dense. Having some examples with both in-bailiwick
> and out-of-bailiwick NSs would be useful (at least to me).
>
> --Paul Hoffman
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Jul 2021 20:49:22 +0000

Thanks! If this is indeed what Ben meant, that works for me. (Apologies for being That Kind Of Person who mostly thinks in examples...)

Given the discussion yesterday, we would also want a signal for "authenticate me or die" versus "I'm fine if you can't authenticate me", but that's an easy detail to add to the format.

--Paul Hoffman

On Jul 30, 2021, at 12:29 PM, Robert Evans <[email-masked]> wrote:
> 
> If I understand correctly, the encoding could cover any below-the-cut records in the referral response.
> 
> For in-bailiwick response, this would be the child NS rrset, glue A/AAAA records, and SVCB records:
> 
> ;; Authority
> example.com [example.com] NS ns1.example.com
> example.com [example.com] NS ns2.example.com=
> 
> ;; Additional
> ns1.example.com [ns1.example.com] A 192.0.2.1
> ns1.example.com [ns1.example.com] AAAA 2001:db8::1
> ns2.example.com [ns2.example.com] A 192.0.2.2
> ns2.example.com [ns2.example.com] AAAA 2001:db8::2
> 
> rr_type=SVCB prefix=_dns.ns2 rdata="ns2.example.com] 1 alpn=dot adox=pki"
> 
> (Or maybe leave out the A and AAAA records, but that makes it easier for attackers to trick resolvers into talking to malicious endpoints.)
> 
> example.com [example.com] NS ns1.other-example.com
> example.com [example.com] NS ns2.other-example.com
> 
> ;; Additional
> <empty>
> 
> This referral conveys no authenticated SVCB (only authenticated NS names), so encryption-aware recursive resolvers would query for SVCB in parallel with A and AAAA queries for the name servers.