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

[Peter van Dijk <[e-mail]>]

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