Subject: [dns-privacy] Review requested

From: Brian Haberman <[email-masked]>
Date: Tue, 14 Sep 2021 12:25:02 -0400

Hi all,
     In the interest of moving work forward, the chairs would like to
solicit reviews for
https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-02

We are especially interested in implementer and operator views on the
approach described in the draft.

Please review and provide comments to the mailing list, chairs, or authors.

Regards,
Brian & Tim

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 15 Sep 2021 21:54:29 +0300

> approach described in the draft.

- Random idea: EDNS extension (or even a flag) to suppress ordinary glue
  and nameserver references if DSGLUE is available (capability
  advertisment). Would cut the size of the DSGLUE responses to be in line
  with existing (extended) glue (reference) responses.

- Maybe instead of spinning up new IANA registry, it would be enough to
  say that for any DNSGLUE records put in zone, the meaning of the rtype
  when put in DNSGLUE MUST be defined. The recursives MUST ingore any
  DNSGLUE rtype they do not understand either way (version screw
  tolerance.)

-Ilari

---

From: "John Levine" <[email-masked]>
Date: 15 Sep 2021 15:09:12 -0400

It appears that Brian Haberman  <[email-masked]> said:
>-=-=-=-=-=-
>-=-=-=-=-=-

Technically I don't see any problems but I still don't understand the semantics
of signed glue.  When the glue and the authoritative disagree for, say, the A record of
a name server, what do you do?

If you believe the authoritative and discard the glue, what was the benefit of the signed glue?

Signed,
still confused

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 15 Sep 2021 15:24:21 -0400

> a name server, what do you do?

Each RRSet encoded in DS Glue overrides any corresponding RRSet in the
ordinary (unsigned) glue, so you ignore the unsigned A records, whether or
not they agree.

> benefit of the signed glue?

It renders the glue tamper-evident.  If an intermediary tampers with the
signed glue, it will cause an immediate SERVFAIL due to DS validation.  If
an intermediary tampers with the unsigned glue, it will have no effect.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Sep 2021 19:25:17 +0000

> a name server, what do you do?

The wording in the draft isn't super-clear on this, but Ben's responses here and in DNSOP have been. DNGLUE contents are treated exactly like other DNS glue, meaning they are useful for the current operation only. A resolver can just forget they saw them after the current operation is complete.

> If you believe the authoritative and discard the glue, what was the benefit of the signed glue?

You get it in the first query, so you can find authoritative information about whether the nameservers have encrypted transports.

--Paul Hoffman

---

From: "John R Levine" <[email-masked]>
Date: 15 Sep 2021 15:36:02 -0400

> an intermediary tampers with the unsigned glue, it will have no effect.

That makes sense so perhaps the draft could say so more clearly.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 17 Sep 2021 13:43:41 -0400

>   with existing (extended) glue (reference) responses.

Cool idea.  I like it.

>   DNSGLUE rtype they do not understand either way (version screw

This would be OK with me.  However, there might be value in DSGLUE creation
tooling (not the parent zone) enforcing the RR type restriction, which
might be easier if there is a registry.  That could help avoid errors and
reduce the likelihood of breakage as more RR types are added.

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 20 Sep 2021 16:53:16 +0200

Hello.

> If the parent zone also implements authenticated encryption, this 
> provides sufficient protection for the glue records, but many 
> important parent zones seem unlikely to implement authenticated 
> encryption in the near future.

I'm not very convinced about the motivation so far.  Let me look 
top-down in the tree.

1: the root seems unlikely to support encryption, but we already do have 
ways of serving/prefetching the whole root zone locally including all 
glue, which is superior also in other respects like leaking random typos 
(and it's standardized and implemented).  So far the best security for 
root glue in there is https with web PKI, I think, but that's not so bad 
for privacy and ZONEMD is supposed to get deployed in there soon, 
resulting in DNSSEC-secure glue.  ZONEMD is standardized as well, and 
implementations are coming around already.

2: communication to TLD servers.  I believe we have very 
privacy-interesting data in QNAMEs there already, arguably even the most 
sensitive parts.  That seems unavoidable, unless sensitive services want 
to move, e.g. grouped into specialized SLDs, and there will hopefully be 
the alternative of moving into supporting TLDs.  And if a TLD offers 
encrypted service, I can't see much use for the proposed DSGLUE, as we 
got assurance because of the QNAMEs already.

DSGLUE sure is way easier to implement and operate than encrypted 
authoritative DNS, but I'd really hope that we can skip this step and 
get (some) encrypted TLDs.

Note that proxying and forwarding cases won't suffer from this either.  
They don't communicate with auths directly, so they don't need any of 
the glue information.  They have to rely with this privacy aspect on the 
final layer talking to auths.

--Vladimir | knot-resolver.cz

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 20 Sep 2021 12:12:46 -0400

On Mon, Sep 20, 2021 at 10:53 AM Vladimír Čunát <[email-masked]>
wrote:

> glue

I agree: local root (plus ZONEMD) is sufficient to authenticate root glue.

> sensitive parts.

In general, I agree.  However, there are some cases where the lower labels
are more sensitive (e.g. tumblr.com).

...

> And if a TLD offers

There are two key reasons for DSGLUE: authentication and RR type
flexibility.  In this model, it's not enough to secure the existing glue RR
types; we also need to convey the nameserver's ADoT configuration during
(in-bailiwick) delegation.

There seem to be many participants in the WG who believe that getting new
glue RR types into parent zones (and especially TLDs) is a very distant
prospect.

> get (some) encrypted TLDs.

Yes, I think we will get *some*, but I think it will be a very long time
before we get *most*.  Having an intermediate solution to protect lower
labels during that transition seems worthwhile to me.

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 20 Sep 2021 18:38:54 +0200

On 20/09/2021 18.12, Ben Schwartz wrote:
> There seem to be many participants in the WG who believe that getting 
> new glue RR types into parent zones (and especially TLDs) is a very 
> distant prospect.

Right, I underestimated that aspect.  Who knows, maybe this new-RR-type 
problem would even apply to the root zone itself.

But overall I'm still not sure whether this is worth separating from 
companion draft(s) that will be needed for auth encryption. Or at least 
I'd rather consider this draft in combination with each, as a "working 
package".

---

From: Petr Špaček <[email-masked]>
Date: Wed, 22 Sep 2021 13:47:29 +0200

Here is a review with my BIND hat on:

> 3.  Proposal
> 
>    This draft proposes a way to convey a glue RRSet inside a DS record,
>    enabling authenticated delivery of arbitrary RR types as part of the
>    delegation response.

Nit: Multiple RR sets, not just one. Also see below discussion about 
"glue" and siblings.

> 3.1.  Encoding

The non-standard RR format worries me - it requires yet another parser 
to save ~ 8 bytes per RR. I'm not sure if it is worth the trouble. Maybe 
it is, but it increases the complexity and fragility of the whole thing.

> 4.2.  In-bailiwick referral

I believe the document needs to consider also sibling glue:

The in-bailiwick definition in
https://datatracker.ietf.org/doc/html/rfc8499#page-25:
includes sibling glue:
>       "In-bailiwick" names are divided into two types of names for name
>       servers: "in-domain" names and "sibling domain" names.

A real-world sibling glue example:

$ dig @d.gtld-servers.com youtube.com NS
;; QUESTION SECTION:
;youtube.com.			IN	NS

;; AUTHORITY SECTION:
youtube.com.		172800	IN	NS	ns2.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.		172800	IN	AAAA	2001:4860:4802:34::a
ns2.google.com.		172800	IN	A	216.239.34.10

Currently, this glue cannot be encoded as in-bailiwick, even though it 
_is_ in-bailiwick of com.
Now what?
- Should the resolver ignore sibling glue if DSGLUE is present? Then we 
are missing protection.
- Or should auth add an unsolicited google.com DSGLUE to the response? 
Then we are asking for trouble with delegation cycles and/or packet bloat.
- Or ...?

A related problem is how registries handle sibling glue. I think this 
needs serious rethinking:
- How does DSGLUE relate to host objects in a registry?
- Would registries be okay with accepting DSGLUE, which overrides 
sibling glue generated by registry from other sources?

This situation needs serious thought because sibling glue is extremely 
common in com. Summary based on com. zone file serial 1630540823:

RRs         | 392 220 980 |
NS RRs      | 373 888 200 | of all delegations |
delegations | 156 365 332 | 100,0 %            |
delegations with NS name in the delegated domain | 522 066     | 0.3 %   |
delegations with NS name in another com domain   | 126 182 455 | 80.7 %  |
delegations with NS name outside com domain      | 38 442 739  | 24.6 % |

Average number of NS records per delegation: 2.4.

> 3.3.  Allowed RR types
>    Recipients implementing this specification MUST accept the NS, A, and
>    AAAA RR types in DSGLUE.  Support for the other allowed RR types is
>    OPTIONAL.
> 
>    Recipients MUST ignore any unauthenticated TLSA records.

Nit: I think readers might appreciate list of optional RR types defined 
in this document.

> 6.2.  Publishing DSGLUE records
> 
>    In order for the child to publish DSGLUE records, the parent must
>    allow the child to publish arbitrary DS records or have specific
>    support for this specification.
> 
>    If the parent supports CDS [RFC8078], child zones MAY use CDS to push
>    DSGLUE records into the parent.  Note that CDNSKEY records cannot be
>    used, because (1) the child cannot publish CDNSKEY records with the
>    required owner name and (2) the child cannot guarantee that the
>    parent will use the VERBATIM digest to produce the DS record.

Is there any indication/information that registries doing CDNSKEY are 
willing to support also CDS for this purpose? I think e.g. CZ is going 
CDNSKEY only because it allows them to select DS hash and to do checks.

> 6.4.  PKI and DANE for Authenticated Encryption
>       TODO: Move some of this text into a different draft.

I agree with the TODO. IMHO it does not belong here. Let's focus on how 
to get signed data from a parent to a resolver and not prescribe its 
semantics in _this_ document.

Similar to Vladimir Cunat, I'd instead consider this draft in 
combination with drafts that describe the uses of DSGLUE as one "working 
package." It is hard to see all interactions without that.

-- 
Petr Špaček  @  ISC

---

From: Petr Špaček <[email-masked]>
Date: Thu, 23 Sep 2021 18:53:29 +0200

On 20. 09. 21 18:12, Ben Schwartz wrote:
> On Mon, Sep 20, 2021 at 10:53 AM Vladimír Čunát 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hello.
> 
> In general, I agree.  However, there are some cases where the lower 
> labels are more sensitive (e.g. tumblr.com <http://tumblr.com>).

I do not dispute there are sites that might benefit, but I think we have 
to keep the big picture in mind.

1] The second label is very often sensitive. To me, a non-sensitive 
second label seems more of an exception.

2] Keep in mind that changing the domain name of an existing site is 
next to impossible, so there is a lot of stuff firmly bolted to com. and 
also other existing TLDs (and domains).

3] I guess .com itself contains roughly 1/2 of all second-level domains 
on this planet. Consequently, if we design something that will not work 
in com. for any reason (be it fragility, scalability, performance, 
operational complexity or cost, ...), then we are practically doing 
useless work.

All in all, while DSGLUE might offer some protection for some sites, 
let's not overestimate its impact.

For this reason, I share Vladimir's skepticism.

Petr Špaček

> flexibility.  In this model, it's not enough to secure the existing glue 
> RR types; we also need to convey the nameserver's ADoT configuration 
> during (in-bailiwick) delegation.
>

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 23 Sep 2021 14:17:33 -0400

...

> second label seems more of an exception.

I think this clarifies an important requirements question for the working
group: do we intend to enable authenticated ADoT for names whose TLD
doesn't do ADoT?  If yes, we need a way to authenticate the NS name and a
signal for ADoT support.  If no, we can rely on the parent's ADoT to
authenticate the glue (as suggested in draft-adox).

> operational complexity or cost, ...), then we are practically doing

Are you saying that DSGLUE "will not work in com"?  I'm not aware of any
reason why this would be true.  DSGLUE is designed to work without any
changes to registries or TLDs.

> let's not overestimate its impact.

Consider this alternative framing: while sensitive-third-label domains may
be rare overall, they certainly outnumber domains whose TLD supports ADoT,
and that is likely to be true for at least several years.  (Wikipedia says
"As of May 2019, Tumblr hosts over 465 million blogs".)

If you believe that most major TLDs will support authenticated ADoT and
SVCB glue records within a few years, then we probably have all the pieces
we need.  Otherwise, I think we should add DSGLUE so we don't have to wait
forever.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Sep 2021 22:50:30 +0000

> Please review and provide comments to the mailing list, chairs, or authors.

The follow-up discussion has been hard to follow because some people are assuming one or the other use case for recursive-to-authoritative encryption, and then further assuming problems with deployment. 

Unauthenticated recursive-to-authoritative does not need the DSGLUE proposal in order to succeed. However, if DSGLUE is standardized and implemented, resolvers using unauthenticated recursive-to-authoritative will encrypt more of their traffic, which is a good thing.

Fully-authenticated recursive-to-authoritative requires DSGLUE or a similar mechanism in order to be able to set up authenticated resolution in a timely fashion (that is, without further record searching or probing).

These two considerations make me think that completing the DSGLUE proposal will help increase the amount of encryption of DNS traffic, and is therefore a good thing.

--Paul Hoffman