Re: [dns-privacy] [Ext] DS Hacks

[Ben Schwartz <[e-mail]>]

Hi DPRIVE.  I've written this up as a proper I-D at
https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-00.  Please
review.

In addition to the precise description of how to extend "DS" in this way,
there's also some text explaining how this interacts with DANE and PKI
authentication, making creative use of NSEC for performance.

On Fri, Jul 30, 2021 at 4:49 PM Paul Hoffman <[e-mail]> wrote:

> 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 <[e-mail]> 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
> >
> > 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 [example.com] NS ns1.other-example.com
> > 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.
>
>