Subject: [dns-privacy] Fwd: New Version Notification for draft-schwartz-dprive-name-signal-00.txt

From: Ben Schwartz <[email-masked]>
Date: Tue, 8 Jun 2021 11:09:04 -0400

Hi DPRIVE,

A few years ago(!), Warren Kumari proposed a hacky way to signal ADoT
support by choosing a special nameserver name [1].  Since then, folks have
proposed a ton of different ways to indicate ADoT support, making use of
the nameserver name, DS record fields, or new RR types.

Warren and I recently revisited that old idea, and felt that it might fill
a gap in some of the active proposals, so we reworked it into a new
proposal (intended status: experimental) that better matches the WG's
adopted drafts.

Enjoy responsibly,
Ben Schwartz

[1]
https://mailarchive.ietf.org/arch/msg/dns-privacy/RbaImWVdtEZN_VqWBYGqVWP3eqk/

---------- Forwarded message ---------
From: <[email-masked]>
Date: Tue, Jun 8, 2021 at 10:48 AM
Subject: New Version Notification for
draft-schwartz-dprive-name-signal-00.txt
To: Benjamin M. Schwartz <[email-masked]>, Warren Kumari <
[email-masked]>

A new version of I-D, draft-schwartz-dprive-name-signal-00.txt
has been successfully submitted by Benjamin M. Schwartz and posted to the
IETF repository.

Name:           draft-schwartz-dprive-name-signal
Revision:       00
Title:          Nameserver Access Modes with Encryption Held in
Alphanumeric Configuration Keys
Document date:  2021-06-08
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/archive/id/draft-schwartz-dprive-name-signal-00.txt
Status:
https://datatracker.ietf.org/doc/draft-schwartz-dprive-name-signal/
Html:
https://www.ietf.org/archive/id/draft-schwartz-dprive-name-signal-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-schwartz-dprive-name-signal

Abstract:
   Some recent proposals to the DPRIVE working group rely on the use of
   SVCB records to provide instructions about how to reach an
   authoritative nameserver over an encrypted transport.  These
   proposals will be difficult to deploy until the parent domain's
   delegation software has been modified to support these records.  As
   an interim solution for these domains, this draft proposes encoding
   relevant signals in the child's NS-name.

The IETF Secretariat

---

From: Peter van Dijk <[email-masked]>
Date: Thu, 10 Jun 2021 09:12:26 +0200

Hello Ben (and Warren),

On Tue, 2021-06-08 at 11:09 -0400, Ben Schwartz wrote:
> Hi DPRIVE,
> 
> A few years ago(!), Warren Kumari proposed a hacky way to signal ADoT support by choosing a special nameserver name [1].  Since then, folks have proposed a ton of different ways to indicate ADoT support, making use of the nameserver name, DS record fields, or new RR types.
> 
> Warren and I recently revisited that old idea, and felt that it might fill a gap in some of the active proposals, so we reworked it into a new proposal (intended status: experimental) that better matches the WG's adopted drafts.

a lot of ideas have been thrown around over the years, and most of
those were not discussed well because they were not written down in
drafts; a lot of goalposts were moved without having clear pictures of
the full scope of several ideas.

So, thank you for typing this one in so we can discuss it! I also much
appreciate Appendix A which summarises several other proposals very
succinctly and explains which bits this draft does better compared to
those.

Obviously, and the draft mentions this, this is a terrible terrible
hack. But that's no reason to hate it. It matches some of the use cases
better than "cleaner" solutions.

The encoding with the single letters is neat. Tying it to SVCB, at
least to have familiar well defined terms to explain what the letters
do, makes sense to me. I note that there are no further words on actual
SVCB records. I can imagine combining your draft (a quick, immediate
signal that causes encryption without waiting for an SVCB lookup, be it
synchronously or asynchronously) with actual `_dns` SVCB records as
described in other recent drafts (the adox draft, and my and Paul's
-common draft). Further down this email the reasons for that should
become clearer.

Paul disagrees with me on tying your explanation to SVCB, and says: "a
resolver operator does not need to implement this as part of SVCB.
Also, it isn't really SVCB because it is default-port only, and it
doesn't handle any other SVCB extensions. It should be called "aext--"
instead, and scrub any SVCB parsing ideas." He also brings up the
chance that the signals in this label might disagree with the signals
in the SVCB record, so untying it from there will cause less
consternation and still have the same semantics.

Going through the draft bit by bit, here are my thoughts (based on
discussion with several other people):

Abstract: definitely agree that parent side SVCB is unlikely to make
sense, ever.

Background: 'synchronous binding check' - Paul and I of course proposed
an asynchronous one, which avoids the latency hit, but it means less
communication will be encrypted.

We don't feel that this is an "interim" solution because we don't think
parent-side SVCB is likely to ever come, or be very useful if it both
unsigned and rarely available. We propose that this be the actual,
long-term solution.

Flag form: proposal: drop this, and allow resolvers to query for SVCB
always. That way, outdated parent side information only 'hurts' for a
short while. It also makes clear that resolvers who really want to know
about the signals can maybe get a signed SVCB back from the child.

Menu form: 'first label' - we not see why this would be a requirement.
As an example, TSIGs requirement to be the last record in a DNS packet
made writing the XPF draft harder than should be necessary. Demanding
to be leftmost hinders future expansion. As we discovered with xn--, it
is essentially easy to look for specially-tagged labels anywhere in a
name.

QUESTION: do we need more than 36 codepoints? Answer: we don't think
so. (If we do, we can create another foo-- label form.)

QUESTION: should we be able to encode svcparams? Answer: the current
candidates for that are, I think, 'port' and 'dohpath'. We don't think
we need them, particularly if there are SVCB records in the child.

Implementation requirements: says 'MUST also support adox', and that
makes sense if the WG treats this as an interim solution; but we are
not not optimistic. In DNS protocol terms, we don't think parent side
SVCB has any significant benefits over this proposal anyway.

Security Considerations: authenticated NS names etc. etc. - yes, this
proposal will not deliver authenticated encryption (but neither will
parent side SVCB). The text above the question is clear on the
tradeoff.

Operational considerations: no comment on the existing text, but there
is another concern that was also brought up around DOTPIN. As A.4
mentions 'creates challenges during TLS key rotation', there is a very
similar challenge, and that is 'the auth operator wants to get rid of
DoT' (or DoQ or whatever) - and its smaller sibling, 'the auth operator
really wants to move from DoT to DoQ because it is so much lighter on
resources' or whatever. Because delegation NSsets are a zone property,
an auth operator does not have full control over what is signalled for
their servers. It can, of course, remove svcb--dotq.ns1.example.com
from the example.com zone, but then anything delegated to that name
just breaks. Proposal: allow resolvers to downgrade (in contradiction
with the current second half of section 5). Then say: if svcb--t was
ever signalled, the auth operator promises to at least send TCP RST for
any connection attempt to port 853. Similar for DoH (443) and DoQ (the
QUIC protocol has a CONNECTION REFUSED error code). This way, the
downgrade in a resolver can be swift, instead of having to wait for
timeouts.

- Peter van Dijk & Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Jun 2021 11:35:58 -0400

On Jun 10, 2021, at 03:12, Peter van Dijk <[email-masked]> wrote:
> unsigned and rarely available.

Thanks for saying this. Although this is very obvious to those in the DNS/ICANN space, it seems the authors of SVCB still haven’t acknowledged this. It is important as it is pretty fundamental to the solution space.

> We propose that this be the actual,
> long-term solution.

I understand the desire but I don’t agree as this signal is insecure, and foresee TLDs abusing this as potential nation state monitor / privacy leak. It is also dangerous when used via resolvers.

I still prefer something with DS than can be signed, and validated by the child as their intend via CDS. With transparency monitoring.

If we are using overloading, might as well overload securely.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Jun 2021 18:37:32 +0000

On Jun 10, 2021, at 11:35 AM, Paul Wouters <[email-masked]> wrote:
> I understand the desire but I don’t agree as this signal is insecure, and foresee TLDs abusing this as potential nation state monitor / privacy leak.

Please say more. I don't see how this proposal leaks anything that could not be trivially determined by probing.

> It is also dangerous when used via resolvers.

Please say more. To me, it is only useful for resolvers.

> If we are using overloading, might as well overload securely.

If you write up a draft, I'm happy to send responses to particular statements in the draft. I don't see how such a DS could be specified in a way that would get more than a trivial amount of deployment. I would be happy to be wrong, given that DS is signed in the parent.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Jun 2021 15:17:43 -0400 (EDT)

> Please say more. I don't see how this proposal leaks anything that could not be trivially determined by probing.

A nationstate could add unsigned NS glue to their zone for domains they
are interested in and trigger people('s resolvers) to go to "their"
secure transport IP and do logging.

If you use DS, they would at least have to sign for it _and_ you can
verify the DS via CDS so now such a parent would have to do a lot more
and leave cryptogrpahic evidence of their efforts.

> If you write up a draft, I'm happy to send responses to particular statements in the draft. I don't see how such a DS could be specified in a way that would get more than a trivial amount of deploy…

We had several proposals written up. I don't think at this point we need
more or updated draft text. We need to decide on what we want to signal,
how many RTTs we are willing to take, and whether or not to attempt to
protect in-bailiwick data.

I feel an insecure signal to signal privacy is the wrong starting point.
With DoH and DoT channels being used in the forwarding chain, we should
really insist on a signal that can be secured and not tampered with. We
are seeing an increase in nation states taking over whole products or
companies to MITM. Another Crypto AG or ANOM might already be running.

A secure signal can only feasably happen within a DS record encoding, as
that is the only secured record we have at the parent. If your position
is that starting from DNSSEC is futile, then we've already given full
control of DNS privacy to the browsers and they will just run with the
current "anycast means privacy" or "oblivious DoH" as the method, so in
that case we are done and no need to work on a draft anymore.

So in a way, we are in a BoF stage for this, not in a WG/draft stage
where it is useful to write down draft text. This is really where I
miss physical IETFs to go brainstorm with people in a single room or
bar.

Paul
ps. the above reasons are also why I am not enthousiastic about
anonymous DNS privacy as proposted in your draft. It does not add
enough privacy/security features compared to what's out there now.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 10 Jun 2021 21:01:35 -0400

On Thu, Jun 10, 2021 at 3:18 PM Paul Wouters <[email-masked]> wrote:

> >> I understand the desire but I don’t agree as this signal is insecure,
> and foresee TLDs abusing this as potential nation state monitor / privacy
> leak.
> >

I am personally quite interested in this kind of "DNSSEC Transparency"
logging, to try to catch misbehaving parents, but at the moment this is a
hypothetical.  This accountability mechanism is not in place today, and I
do not think that we should introduce it as a requirement for DPRIVE.
Specifically, I do not think "non-repudiability" of secure delegations is a
requirement for this working group at this time.

Our problem is hard enough without stacking it on top of other hard
problems.

...

> really insist on a signal that can be secured and not tampered with.

I agree.

> We
> that is the only secured record we have at the parent.

The ADoX draft starts from an alternative view, based on three observations:
* It's possible to get secured glue records from the root (e.g. with Zone
Digest).
* If the parent does ADoT, this also secures the glue records.
* While it may be difficult to get many TLDs to do ADoT, this is often a
prerequisite anyway: for most domains, the TLD+1 is the most sensitive
label.

I believe in this view.  However, I would also like to see a signal encoded
in the DS record, to support domains whose parent doesn't offer ADoT.  I
believe encoding the relevant information in NS and SVCB records actually
supports this, via a mechanism like DiS [1] or "CNSRRSIG" [2].  I would
like to see a version that (1) can protect the parent NS, (2) can protect
glue-like SVCB records, (3) is compatible with loosely coherent updates to
the glue, and (4) can be published today via CDS or CDNSKEY.  If we are
careful about exactly what we hash in each DS record, I think this is
possible.

[1]
https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-delegation-information-signer
[2] https://mailarchive.ietf.org/arch/msg/dnsop/WsnbedpaNuK5bXI35L2wlk7e3rA/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Jun 2021 01:48:37 +0000

> secure transport IP and do logging.

This is a problem with unsigned NS, not unsigned labels in the name.

> and leave cryptogrpahic evidence of their efforts.

Is your proposal "DS in parent and matching DNSKEY in the child"?

> more or updated draft text.

What you gave in your eariler is not sufficient for useful analysis, thus not for comparison. See my question above, for example.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Jun 2021 18:37:04 -0400 (EDT)

> This is a problem with unsigned NS, not unsigned labels in the name.

Whereever the unsigned data at the parent is, that does not matter. It
could be the imaginary SVCB record at the parent. The problem is that
a nationstate can just add them to their TLD glue, and the child cannot
opt out of resolvers following the path from root to TLD to TLD's
resolver.

> Is your proposal "DS in parent and matching DNSKEY in the child"?

DS in parent and matching CDS in child. No need to pollute the child's
DNSKEY RRset and complicate validation.

> What you gave in your eariler is not sufficient for useful analysis, thus not for comparison. See my question above, for example.

We had a long discussion with Peter van Dijk's proposal on what to
encode in the DS or not. Eg do we add pubkey or not. Please read
the archive. If we reach agreement on what to encode and how to encode
it, it can be written as draft. Maybe even as update to Peter's draft.

Paul