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

[Alexander Mayrhofer <[e-mail]>]

Ben,

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

On Thu, Aug 19, 2021 at 7:14 PM Ben Schwartz <[e-mail]> wrote:
>
> 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.

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

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

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

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