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

From: Ben Schwartz <[email-masked]>
Date: Fri, 6 Aug 2021 11:21:35 -0400

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Aug 2021 16:12:36 +0000

(Changing the thread subject because it now feels like much less of a hack)

On Aug 6, 2021, at 8:21 AM, Ben Schwartz <[email-masked]> wrote:

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

I like this draft a lot. I suspect there will be tweaks, but I hope the WG adopts it as the way to signal in the parent. It works well for the fully-authenticated case, and is also useful for the unauthenticated case to cause more encryption.

--Paul Hoffman

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 6 Aug 2021 21:43:36 +0300

> authentication, making creative use of NSEC for performance.

I am confused about the NSEC parts. 

- Usually NSEC lists the next name and present types for current name.
- In this draft, it seems to be  list of types that are not present.
- In this draft, I do not see any explanation on how the name in the
  NSEC record should be set. In the examples, it seems to be the set
  to full owner name.
- The draft mentions NSEC3 too, but as far as I can see, no
  explanation or examples of its use.

-Ilari

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 6 Aug 2021 15:05:05 -0400

The NSEC and NSEC3 records are supposed to work exactly as usual.  I didn't
provide any examples of NSEC3 because I didn't dare to attempt to write
NSEC3 records by hand.

I think you're right, and the NSEC examples are wrong.  Would you kindly
review this change to fix them:
https://github.com/bemasc/ds-glue/pull/1/files ?

Thanks,
Ben

On Fri, Aug 6, 2021 at 2:44 PM Ilari Liusvaara <[email-masked]>
wrote:

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Aug 2021 16:16:00 +0000

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

Peter and I talked yesterday, and we see how to update draft-ietf-dprive-unauth-to-authoritative to incorporate "if you're a validating resolver, you SHOULD process DSGLUE during the NS lookup so that you might be able to encrypt the first time". This model seems to be the best so far to give the needed information in the parent. It would be good to hear if the WG wants to go in this direction.

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 10 Aug 2021 13:25:34 -0400

I've now uploaded
https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-01, with
clarifications and corrections based on comments from Paul Hoffman and
Ilari Liusvaara (thanks both).

On Tue, Aug 10, 2021 at 12:16 PM Paul Hoffman <[email-masked]>
wrote:

> Peter and I talked yesterday, and we see how to update
> draft-ietf-dprive-unauth-to-authoritative to incorporate "if you're a
> validating resolver, you SHOULD process DSGLUE during the NS lookup so that
> you might be able to encrypt the first time". This model seems to be the
> best so far to give the needed information in the parent. It would be good
> to hear if the WG wants to go in this direction.
>
> --Paul Hoffman_______________________________________________
> dns-privacy mailing list
> [email-masked]

---

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 19 Aug 2021 18:54:34 +0200

Ben,

I've reviewed the draft, thanks for writing it up. I do think it's an
excellent shot at addressing the problem of authenticated encryption,
and very mature already. Speaking as a TLD registry operator, i agree
that the glue provisioning path is extremely slow to upgrade, so
"staying under the radar" by using an existing, reasonably well
deployed RR type is the only feasible "fast" way forward (for medium
values of "fast", as it will take some time and effort for the new
algorithm type to be enabled). Getting wide deployment for an EPP
extension to provision SVCB directly would take at least a decade..  -
So, i like this alternative a lot.

However, i'm a bit more cautious when it comes to generalizing DS-GLUE
to other use cases, particularly conveying NS records. It's cool to
have a generic mechanism to convey arbitrary records, but once those
records overlap with a "legacy deployment", we need to be very very
careful about the interactions between those two channels (eg. domain
name owners expecting they can safely remove the NS records from the
registry, because they supply those records in DS-GLUE already). I
think there should be some text in the draft about this in future
revisions. Maybe we should even restrict DS-GLUE to a set of
pre-defined use cases.

best,
Alex

On Tue, Aug 10, 2021 at 7:26 PM Ben Schwartz
<bemasc=[email-masked]> wrote:
>
> I've now uploaded https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-01, with clarifications and corrections based on comments from Paul Hoffman and Ilari Liusvaara (thanks both).
>
> On Tue, Aug 10, 2021 at 12:16 PM Paul Hoffman <[email-masked]> wrote:
>>

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 19 Aug 2021 13:14:25 -0400

Thanks for the review, Alex.  I've just released a new revision that
addresses some of your comments:

https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-02

The main change in this revision is the removal of the NSEC approach to
authenticated nonexistence.  This proved too complicated for me to get
right in the examples, and implementers told me that it would not be easy
to implement, as I had hoped.  Instead, draft-02 encodes each RRSet as a
unit, and authenticates nonexistence by encoding an empty RRSet.

On Thu, Aug 19, 2021 at 12:54 PM Alexander Mayrhofer <
[email-masked]> wrote:
...

> to other use cases, particularly conveying NS records.

I don't think we can avoid placing NS records in DSGLUE.  Authenticating
the NS records is crucial for both out-of-bailiwick and in-bailiwick
delegations.

> It's cool to
> revisions.

OK, I've added that text here:
https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-02#section-6.1

Maybe we should even restrict DS-GLUE to a set of
> pre-defined use cases.

draft-02 now does this, by opening a registry of allowed RR types.  As we
reach an understanding of how to interpret other RR types in DS Glue, we
can add them to the registry.

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 27 Aug 2021 15:24:55 +0200

Ben,

[responses inline - sorry for the vacation-induced late reply!]

On Thu, Aug 19, 2021 at 7:14 PM Ben Schwartz <[email-masked]> wrote:
>
> Thanks for the review, Alex.  I've just released a new revision that addresses some of your comments:
>
> The main change in this revision is the removal of the NSEC approach to authenticated nonexistence.  This proved too complicated for me to get right in the examples, and implementers told me that it would not be easy to implement, as I had hoped.  Instead, draft-02 encodes each RRSet as a unit, and authenticates nonexistence by encoding an empty RRSet.

I can't speak as an implementor, but looks good (and logical) to me!

>
> I don't think we can avoid placing NS records in DSGLUE.  Authenticating the NS records is crucial for both out-of-bailiwick and in-bailiwick delegations.
>

True. You do mention in the draft that if the parent allowed for
authenticated encryption, so - in theory - plain glue from such
servers should have similar trust properties as DS-GLUE NS RRSets.
However, implementing that additional state (potentially per RRset)
might be too complex on the resolver side..

My gut feeling tells me we're introducing new failure modes somewhere
here, so that's where my caution came from initially. The text in the
"Interpretation" section is very clear, though, and i can't name a
problematic case right now (cyclically dependent NS records, maybe?).

Hmm, maybe one: Assume AAAA records for a nameserver are authenticated
(from DS-GLUE), A records are not. Resolver prefers DS-GLUE sourced
records, attempts to contact auth server via AAAA address(es), queries
time out. Resolver could now (a) indicate to client that authenticated
glue is exhausted (SERVFAIL?), (b) attempt to contact the auth server
via unauthenticated A records. It could also fall back to the "normal"
delegation response initially received?

So, as always, the "success case" is pretty straightforward, while the
"failure cases" might be full of painful obstacles (and require most
of the discussion time).

> OK, I've added that text here: https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-02#section-6.1

Perfect. Concise and to the point.

>> pre-defined use cases.>
> draft-02 now does this, by opening a registry of allowed RR types.  As we reach an understanding of how to interpret other RR types in DS Glue, we can add them to the registry.

Sounds good to me. I know that IANA has lots of "idle" registries
(which never get updated), so we could also go for the option of
listing the allowed RR Types in the document itself, and wait for a
future extension of the protocol to UPDATE the base spec (by adding
new records), and eventually creating an IANA registry. But i guess
that's a decision between IANA and the AD..

best,
Alex

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 27 Aug 2021 10:36:24 -0400

On Fri, Aug 27, 2021 at 9:25 AM Alexander Mayrhofer <
[email-masked]> wrote:
...

> I can't speak as an implementor, but looks good (and logical) to me!

Thanks!

...

> delegation response initially received?

I think the interpretation section covers this: the AAAA DS-GLUE replaces
any colliding AAAA glue, and then delegation following proceeds as usual.
The resolver is not instructed to change its behavior based on whether the
A or AAAA glue records were authenticated.  I think this is your option "b".

If you want behavior "a", you have to do the thing shown in
https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-02#section-4.3.