Subject: [dns-privacy] Next steps for draft-rescorla-dprive-adox

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 May 2021 14:31:27 -0700

Hi all,

Now that we've had some time to let the ideas settle, I'd like to
discuss what would be required in order for the WG to adopt
draft-rescorla-dprive-adox-latest.

>From my perspective, the primary open question is the wisdom of having
some kind of record in the parent domain. For the reasons I indicated
in my presentation and in Section 6, if we are unable to securely
indicate the use of ADoX in the parent, it will not be possible to
protect many queries (i.e., those for the apex). I note that this is
also embodied in:

https://www.ietf.org/archive/id/draft-pp-dprive-common-features-00.txt
and
https://www.ietf.org/archive/id/draft-ietf-dprive-unauth-to-authoritative-00.txt

While I understand that there are people who have reservations about
whether it will be practical to popuate the parent, I think the
analysis cited above suggests that there will be comparatively little
value in attempting to have a non-opportunistic mode without this
feature (regardless of which record it is encoded in).

So, from my perspective, the question is:

1. Do we want a non-opportunistic mode? [My answer, of course, is yes]
2. Is this proposal a plausible starting point for that?

If the answer to both of those question is "yes", then I'd like to
ask for adoption. If not, can we try to dig into each of them?

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 May 2021 21:36:36 -0400 (EDT)

On Tue, 11 May 2021, Eric Rescorla wrote:

> some kind of record in the parent domain.

> whether it will be practical to popuate the parent

This is not about some people having reservations. As I explained
before, you are talking about:

- Updating DNS resolvers understand a new DS-like record on the 'wrong'
   end of the zone cut (incompatible with RFC 3597)
- Updating DNS auth server code to serve a new DS-like on the 'wrong'
   end of the zone cut (incompatible with RFC 3597)
- Update all the DNS servers run these new DNS resolvers
- Adding a new EPP extension to transport the new record to the
   Registrar
- Adding a new EPP extension to transport the new record from the
   Registrar to the Registry
- Registrars updating their code (libraries and webgui)
- Registries updating their code (libraries)
- Updating ICANN contracts about allowed RR types
- Writing CDS/CDNSKEY style auto-updating for this new record
- Updating zone file verification tools to not barf on record being
   out of bailiwick

Last time, I recommended you talk to people at the REGEXT working
group, Registries/Registrars and DNS hosters, our ICANN liaison or SSAC.

Did you contact any of these people to ask about the feasability of
your proposal?

> 2. Is this proposal a plausible starting point for that?

No it is not. If a TLD that falls under ICANN policues would suggest
running software that supports this proposed record, it would surely
trigger an RSTEP review, and wearing my ICANN RSTEP reviewer hat, I
would strongly advise not reject the TLDs technical proposal.

This has nothing to do with what I want. I _want_ this record or similar
solution to work, but it just realistically cannot work. That is also why
people (including me) who are normally very strict against overloading
have suggested the only way to signal something at the parent is via
overloading the NS or DS record in some way. And using DS is better
because it is signed and can be verified at the child.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 May 2021 19:06:04 -0700

> because it is signed and can be verified at the child.

I'd like to make sure I understand your point. Is it simply that this
information should
be encoded in NS or DS? If so, I don't particularly object to that. I don't
have a strong
opinion about how this signal is spelled.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 May 2021 22:27:40 -0400 (EDT)

On Tue, 11 May 2021, Eric Rescorla wrote:

> I'd like to make sure I understand your point. Is it simply that this information should
> be encoded in NS or DS? If so, I don't particularly object to that. I don't have a strong

DS records and glue (NS,A,AAAA) are the only child records served by the parent.

So .ca will publish (redundancy removed for readability):

nohats.ca.		86400	IN	NS	ns0.nohats.ca.
ns0.nohats.ca.		86400	IN	A	193.110.157.102
ns0.nohats.ca.		86400	IN	AAAA	2a03:6000:1004:1::102
nohats.ca.		21599	IN	DS	1321 8 2 B7890A1E7B4CE1D671795D5FD46A71F229C58025587BEC4EEB70CCDA 9233011C
nohats.ca.		21599	IN	RRSIG	DS 8 2 86400 20210516110615 20210509013859 43854 ca. <blob>

If you define a new RRtype, say FOO, and .ca will add:

nohats.ca.              86400   IN      FOO      <data>

Then all DNS software will reject this record as out-of-zone data. It
will just never serve this record until you made software modifications.

That means changing all DNS authoritative servers on the planet.

Then you also need to DNSSEC sign this record or treat is as glue. That
behaviour/expectation has to be added to all DNS recursive/validating
software on the planet.

And then you need to update the mechanism how Registries and Registries
update this FOO record in the parent zone.

You won't be able to rely on these updated for many years to come.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 12 May 2021 15:56:25 -0700

> You won't be able to rely on these updated for many years to come.

I agree, but I still think this draft represents a good approach, and we
should adopt it.

In my view, the WG has been stuck trying to choose between principled
long-term solutions that will take many years to implement, and ugly hacks
that can be deployed quickly.  In fact, I think we should develop both.
This draft is the former, and if we adopt it, we can and should follow with
interim solutions that can "upgrade gracefully" over time.

Adopting this draft, even if we are far from implementation, is important.
To choose good intermediate steps, we first need to know what the endpoint
looks like.  For example, with this draft in place, we could define a flag
in the DS record meaning "use encrypted DNS like in ADoX", with resolvers
querying for the SVCB record in the child if it isn't provided as glue from
the parent.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 May 2021 19:40:24 -0400

On May 12, 2021, at 18:56, Ben Schwartz <[email-masked]> wrote:
> I agree, but I still think this draft represents a good approach, and we should adopt it.
> 
> In my view, the WG has been stuck trying to choose between principled long-term solutions that will take many years to implement, and ugly hacks that can be deployed quickly.  In fact, I think we should develop both.  This draft is the former, and if we adopt it, we can and should follow with interim solutions that can "upgrade gracefully" over time.

The draft is proposing a fundamental change in the processing of the new proposed RR. It is a major protocol change, as opposed to simply adding a new RR TYPE that works under RFC 3597

That work should not be done in this WG. Any fundamental change in how DNS operates belongs on dnsop (well, dnsext but that role was taken on by dnsop)

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 12 May 2021 17:00:42 -0700

On Wed, May 12, 2021 at 4:40 PM Paul Wouters <[email-masked]> wrote:
...

> The draft is proposing a fundamental change in the processing of the new
> proposed RR. It is a major protocol change, as opposed to simply adding a
> new RR TYPE that works under RFC 3597
>

Regarding RFC 3597, this proposal is actually entirely compliant.  The
concerns we're grappling with are due to the lack of RFC 3597 compliance
elsewhere.

That work should not be done in this WG. Any fundamental change in how DNS
> operates belongs on dnsop (well, dnsext but that role was taken on by dnsop)
>

It seems to me that encrypting resolver-authoritative connections is a
fundamental change in how DNS operates.

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 12 May 2021 21:16:03 -0400

To Paul's point, this is the ICANN Base Registry Agreement listing the
permitted "TLD Zone Contents".

https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#exhibitA.1

This is only for gTLDs that have signed this agreement.  The ccTLDs
generally have their own contracts which will vary.

This idea could or should work for all authoritative domains that are not
TLDs.

tim

On Tue, May 11, 2021 at 9:37 PM Paul Wouters <[email-masked]> wrote:

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

---

From: Andrew Campling <[email-masked]>
Date: Thu, 13 May 2021 16:17:40 +0000

On Tue, 11 May 2021, Tim Wicinski <[email-masked]> wrote:

> To Paul's point, this is the ICANN Base Registry Agreement listing the permitted "TLD Zone Contents".

> This is only for gTLDs that have signed this agreement.  The ccTLDs generally have their own contracts which will vary.

> This idea could or should work for all authoritative domains that are not TLDs.

Has there been any discussion with any of the authoritative domains, TLDs or otherwise, to establish whether they are interested in this proposal, willing to implement it etc?

Andrew