Subject: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt

From: [email-masked]
Date: Thu, 13 May 2021 11:07:41 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Home Networking WG of the IETF.

        Title           : Simple Provisioning of Public Names for Residential Networks
        Authors         : Daniel Migault
                          Ralf Weber
                          Michael Richardson
                          Ray Hunter
	Filename        : draft-ietf-homenet-front-end-naming-delegation-15.txt
	Pages           : 38
	Date            : 2021-05-13

Abstract:
   Home owners often have IPv6 devices that they wish to access over the
   Internet using names.
   Outsourcing the DNS servers to a DNS infrastructure protects against
   possible DDoS attacks as well as sudden renumbering of the home
   network.  It has been possible to register and populate a DNS Zone
   with names since DNS became a thing, but it has been an activity
   typically reserved for experts.  This document automates the process
   through creation of a Homenet Naming Authority (HNA), whose
   responsibility is to select, sign and publish names to a set of
   publicly visible servers.

   This document describes the mechanism that enables the HNA to
   outsource the naming service to the DNS Outsourcing Infrastructure
   (DOI) via a Distribution Manager (DM).

   In addition, this document deals with publication of a corresponding
   reverse zone.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-15
https://datatracker.ietf.org/doc/html/draft-ietf-homenet-front-end-naming-delegation-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-front-end-naming-delegation-15

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Daniel Migault <[email-masked]>
Date: Thu, 13 May 2021 14:26:46 -0400

Hi,

Please find the new version that is considering the discussions of the
mailing list as well as comments received from Med.

Yours,
Daniel
---------- Forwarded message ---------
From: <[email-masked]>
Date: Thu, May 13, 2021 at 2:08 PM
Subject: [homenet] I-D Action:
draft-ietf-homenet-front-end-naming-delegation-15.txt
To: <[email-masked]>
Cc: <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Home Networking WG of the IETF.

        Title           : Simple Provisioning of Public Names for
Residential Networks
        Authors         : Daniel Migault
                          Ralf Weber
                          Michael Richardson
                          Ray Hunter
        Filename        :
draft-ietf-homenet-front-end-naming-delegation-15.txt
        Pages           : 38
        Date            : 2021-05-13

Abstract:

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

-- 
Daniel Migault
Ericsson

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 May 2021 11:17:17 -0400

> mailing list as well as comments received from Med.

Daniel, I was just proofreading, and you'll see a pull request "typos"

1. reading at the beginning, I didn't recall if we had concluded that we were
   going to mandate the AXFR to be XoT (AXFR over TLS) or not.
   We later reference [I-D.ietf-dprive-xfr-over-tls], but not section 4.5.1.
   Is it enough to say it in section 5.1?

2. What if the zone template provided by the DM has to change.
   (Because, for instance, the distribution server NS records change).
   Is the template retrieve each time the zone is signed?
   Once? (And never again?...)
   Based upon some TTL?

3. Section 4.6, we say "SHOULD" on TLS, but in which case, what exception are we
   thinking?  I guess we three will have to do another SHOULD/MUST audit.
   Noting that RECOMMENDED ==> SHOULD.

Section 5 has "YYYY" and "XX"... which feels like maybe we forgot to do some
IANA thing.  Maybe we should omit the placeholders?  What does the WG think?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Daniel Migault <[email-masked]>
Date: Fri, 14 May 2021 12:02:36 -0400

>    Is it enough to say it in section 5.1?
<mglt>
In my mind, we were mandating AXFR over TLS. So we should probably clarify
this in section 4.5.1 as well.
</mglt>

> <mglt>
That is a good catch. The TTL of the NS may be a good indication. But we
may also recommend the HNA to check it regularly, like every day or every
week.
</mglt>

> <mglt>
I think we said SHOULD in case some deployment wants to use other means.
The one that come to my mind is if a deployment is willing to use TSIG for
example. I am find moving this to MUST use TLS.
</mglt>

> <mglt>
I think the 4 digit port and 2 digit port  are clearly represented by these
variables, but I am fine we remove these if that bring any confusion.
</mglt>

-- 
Daniel Migault
Ericsson

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 May 2021 22:01:14 +0100

Hiya,

I had a read of this one. My comments (as an individual, not
as chair) below. I'll chat with Barbara to see if we have a
common position on how to handle next steps but am happy to
chat about stuff below whenever.

Cheers,
S.

review of draft-ietf-homenet-front-end-naming-delegation-15
sf, 20210524

general/technical:

#1 This needs significant editorial work, there are too many
grammatical issues, at least some of which lead to ambiguity.

#2 If a home network/CPE isn't robust enough to serve as a DNS
server for it's public zone, then how is it robust enough to
resist attack/DoS on the addresses exposed in that zone? That
seems to me to counter a bunch of the arguments for this
approach, so I'd like to understand the proponents arguments
there. At minimum, any AAAA for an "inside" server/name means
that the CPE's f/w will be subject to the same kind of attacks
that might happen if the CPE was the only/primary DNS server
for the zone.

#3 The arguments about handling "disruption with the ISP" could
do with some more evidence, not necessarily as text in the
draft, but it ought exist - does it? E.g. do we know that
publishing ULAs isn't problematic? Do we know that GUAs in such
scenarios aren't still usable for longish durations given a
realistic pattern of ISP disruption?

#4 My home network is IPv6 renumbered every time there's a
reboot/power outage at the DSLAM, which happens maybe twice a
year. How would this protocol handle that? Would the DM get
overloaded maybe?

#5 The arguments why this is better than DDNS don't convince
me, except for the last one (new RR types).  Given that DDNS is
deployed, what's the chances that this would also get traction?
(Not asking that all be in the document, but I am asking.)

#6 Do the DM/DOI care about the names published? If not, why
not? E.g. say an ISP has the DOI servers "first" in how it
resolves names for a local area, what'd stop some home from
claiming to be windowsupdate.com?

#7 If the DOI sends the DS to the parent, then the DOI can
cheat on the home - why is that ok? If it is ok, then shouldn't
there really be a MUST for the HNA to check that the correct DS
is/was published via some recursive outside the control of the
DOI?

#8 Do the DS TTL and RRSIG expiry times set the limit for how
long the home n/w can handle ISP disruption? If so, be good to
say so. I also wonder if that limits the added-value here or
not.

#9 Requiring mutually authenticated TLS between HNA and DM
(section 3.2 has that MUST, even if it says TLS is only
RECOMMENDED), seems like a circular dependency. How does the
HNA get that client-cert before/at the start?

#10 4.x: I don't understand how we get interop based on all
this.  Wouldn't this kind of thing need a bunch of people to
have implemented and interop'd before we could be confident of
the spec?

#11 I don't understand what problem we're really solving with
the reverse zone stuff, nor do I see the overall thing here
would work where the ISP provides those reverse-IP stanzas for
a zone file but where that ISP has no way to update the
parent's DS record. Are there a set of "just doens't work"
configurations there really?  If so, shouldn't that be either
stated or solved somehow?

#12 Section 10 seems like a mix of generic guidance and
requirements but also things needed for interop (e.g. use DoT
on 853). I'm not convinced that's a good plan if we want
multiple implementations that interop.

specific/editorial:

- abstract: "often" where's the evidence for that? Why do you
   even need to make that (questionable) assertion? Better to
just set out the mechanism.

- abstract: "using names" should probably be "using DNS names
   or similar"

- abstract: documents don't "automate" things

- abstract: "servers" - you don't know, and shouldn't require
   that, the FQDNs published are those of servers.

- abstract: "the naming service" - what's that exactly? Isn't
   this just a new flavour of feeding zones to a DNS
authoritative?

- 1.0: what is "a single universal view"? Are you contrasting
   that with split horizon or something?

- 1.1: Publishing ULAs because of a VPN seems like an odd
   justification. Seems more likely a VPN could/would set a
different DNS recursive for clients and ULAs could be handled
there.

- 1.2: that might be better as an appendix or deleted. It's
   probably a bad idea to name specific commercial DDNS
services.

- section 2: "DOI" isn't a good choice - every RFC has one of
   those and it's not what's defined here:-) If you could avoid
the acronym collision that'd be better. Maybe "domain name
outsourcing infrastructure"/DNOI?

- section 2: I'm not seeing why you need (new?) terms for types
   of recursive resolver. Aren't those already defined
elsewhere?

- 3.1: I have no idea what is meant by: " The ".local" as well
   as ".home.arpa" are explicitly not considered as Public
Homenet zones and represented as Homenet Zone in Figure 1."
That seems like an important thing to be clear about.

  - 3.1: How is backup of KSK/ZSK handled? That's needed in this
    scenario as CPE kit breaks or is discarded. That might or
might not be something needing protocol but it definitely needs
mention.

- 3.2: What DoX implementation supports TLS client auth?

- 3.2: I don't get why a single IP/port is needed for the DM.

- 4.5.1: "MUST send a DNS request of type AXFR associated to
   the Registered Homenet Domain" - what if the domain is
already used/populated/whatever?

- 4.5.1: Where else is there the concept of a "zone template"?
   If nowhere else then I wonder if that concept needs some more
review? (I can well imagine how to make a zone file template
and am sure many have done so, but I bet there are corner-cases
galore.)

- section 5: What are YYYY, ZZZZ and XX supposed to be?  At
   least XX seems to require an IANA action or the re-use of
some port number?

- 5.1: It's not clear that DANE will always be ok there - there
   should be a way to make it work but I don't think I've seen
any worked-out description of using DANE for DoX.

- 5.1: "baked-in" isn't right - typically those lists are
   updated by the OS (e.g. OpenWRT) or via application s/w
update. (My nearest OpenSSL install has an /etc/ssl/certs
directory.)

- 5.1: I'm not clear how exactly pinning via tickets would work
   here but I didn't read RFC8672 just now so maybe it's all
clear from tha - is it?

- section 9: I don't understand: "This leave place for setting
   up automatically the relation between HNA and the DNS
Outsourcing infrastructure as described in
[I-D.ietf-homenet-naming-architecture-dhc-options]."

- section 9: "2001:db8:babe:0001::2" - the string "babe" has
   both innocent and less innocent interpretations, not sure if
you want to risk the latter being some reader's interpretation.

- section 10: you use a different example here from earlier,
   just one is probably better, unless there's a reason they
ought differ.

- 11.1: is a subsection needed there really? (I kinda skipped
   all that text TBH;-)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 25 May 2021 14:22:35 +0200

> deployed, what's the chances that this would also get traction?

I think that's an important point.  I actually asked the very same
question back in 2014:

  https://mailarchive.ietf.org/arch/msg/homenet/CBoLV2St-kSW0vQNE4GtKqRQthA/
  https://mailarchive.ietf.org/arch/msg/homenet/m3tmE8m1pt11YIB5yAtWUMFlv3c/

The authors integrated the discussion as Section 1.2 of the draft, which
is what you are referring to.  I'm not sure if I'm convinced by their
arguments, I suspect that there's some unstated requirement that I don't
undestand.

-- Juliusz

---

From: Daniel Migault <[email-masked]>
Date: Wed, 26 May 2021 13:02:18 -0400

Hi Stephen,

Thanks for the questions / suggestions / comments. Please find some
responses inline. I updated the document [1] and added issues on the git
repo.

Yours,
Daniel

[1]
https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/cc07384cf6a93794f984d3393100e700a306317c#diff-1fb3d4609e8b03755bf2390df10a5ccd792f989796a0b922a273cd63418fcaa5

> that might happen if the CPE was the only/primary DNS server
CPE are optimized for packet l2/l3 packet switching as opposed to
terminate services. Resources of the CPE are estimated for volumetric
attacks that are expected to be handled by the ISP. Hosting DNS changes the
scope on that the CPE becomes an addressable target, subject to application
DoS attacks which it has not been in general designed for and which are
much harder to tackle for an ISP as this is "legitimate" traffic.
The document does not specify the HNA is addressable from inside the
network and Figure 1 clearly separates the authoritative server from the
HNA. Of course this could be implemented this way, but I am wondering if
there is any text that suggests such an approach.  It seems to me that
discussion over the management of the authoritative DNS server on the CPE
is out of the scope of the document. In addition, if an DDoS attack is
handled from inside the homenet, the network admin is more likely to unplug
that device than if performed from the Internet.
</mglt>

> realistic pattern of ISP disruption?
ISP disruption is not an argument but a requirement from RFC7368 section
3.7.5. I think we all experience some connectivity disruption, so I do not
believe there is a need to clarify this exists. The most obvious case is
equipment that goes down for some time.  A transition from one ISP to
another seems to me a bit out of scope of the document. The
document considers renumbering which could be a good start for a more
complex management transition, that sounds to me very specific and out of
scope of the document. We have added a section in the security
consideration that I think covers your concern:
"""
The HNA enables to handle network disruption as it contains the Public
Homenet Zone, which is provisioned to the Homenet Authoritative Servers.

However, DNSSEC validation requires to validate the chain of trust with the
DS RRset that is stored
into the parent zone of the Registered Homenet Domain.
As currently defined, the handling of the DS RRset is left to the Homenet
DNSSEC resolver which retrieves from the parent zone via a DNS exchange and
cache the RRset according to the DNS rules, that is respecting the TTL and
RRSIG expiration time.
Such constraints do put some limitations to the type of disruption the
proposed architecture can handle.
In particular, the disruption is expected to start after the DS RRset has
been resolved and end before the DS RRset is removed from the cache.
One possible way to address such concern is to describe mechanisms to
provision the DS RRset to the
Homenet DNSSEC resolver such as HNCP for example.
Such work is out of the scope of this document and is left from future work.
"""

Similarly, the zone content is also a bit out of scope of the document and
the admin is supposed to be responsible for what he is publishing. The text
mentions the publication of ULA with a may, as an example. I think it is
useful to have this as a consideration but elaborating on this may end up
in a complete book of managing the homenetwork, which I do not think is the
purpose of this - already long - document. Removing the text would not
affect the scope of the document, but I think it is useful information
to avoid some mis-conceptions.
</mglt>

> year. How would this protocol handle that? Would the DM get
As per RFC 8415, 7291, I expect CPE are gradually brought up. However,
assuming such a crowd event happens, it seems reasonable to assume the DM
is able to deal with DNS  SERVFAIL, TLS internal_error, TCP RST, HTTP
503...  I see this as a standard service provided by any cloud provider. It
is also unclear to me how this is different from all CPE reconnecting to a
common service/app such as Google Mail for example.
I do not think additional text is needed here, but maybe you would like
something being added into the Security configuration. Is that what you
had in mind ?
</mglt>

> (Not asking that all be in the document, but I am asking.)
To me scalability a standard interface for (any) DNS RRSet that is scalable
is the most convincing argument. Currently Dynamic DNS consists of multiple
distinct protocols. [1] lists 11 of them, I am not sure Gandi has been
included either [2], not all versions are using TLS. Their usage is mostly
intended for a single or a very limited number of RRsets. The HNA seems
more appropriate for a home network. For example, if all devices have a
client, all devices need to be manually provisioned every time you change
your homenet domain, every time your account/provider changes...
which hardly scales.

[1] https://ddclient.net/protocols.html
[2] https://github.com/rmarchant/gandi-ddns
</mglt>

> claiming to be windowsupdate.com?
The situation is similar as today, the DOI needs to have some guarantees
you really own the domain. The DOI is expected to be a sort of registrar
which could be limited to owning a domain. In the example windowsupdate.com
I hardly see .com doing the delegation to the DOI without strong evidence
that the DOI owns windowsupdate.com.

To me this looks obvious, so we may have underestimated this aspect.  I
have opened an issue, to carefully address this. If you have any text you
would like to see, please feel free to propose it.
https://github.com/ietf-homenet-wg/ietf-homenet-hna/issues/51
</mglt>

> is/was published via some recursive outside the control of the
<mglt>
It is unclear to me if you are referring to a specific paragraph in the
document, but it is likely that the CPE will perform some kind of checks
and a DNSSEC resolution to a domain it owns is likely to be done.
Sure the DOI may cheat, but if that is the case, the DS will hardly provide
any significant protection as the DOI may still respond non DNSSEC to user
users than the homenet. This will make it hard to detect.
I currently do not see this as a major threat, but I might be missing
something.
</mglt>

> say so. I also wonder if that limits the added-value here or
Currently the DS puts some limit to the ISP disruption, but section 3.1
mentions that other mechanisms to enable resolutions to the DNS
authoritative servers may be designed in the future.
This specification does not change the DNS, nor create HNCP mechanisms. If
future usage requires it, specific handling will need to be defined. To my
perspective, such mechanism

We added some specific text in the Security Consideration ( see above
regarding the disruption).

</mglt>

> HNA get that client-cert before/at the start?
I am reading the following text in section 3.2 where we mandate a mutually
authenticated communication and recommend TLS among the other protocols
that can do that. I suspect you added "TLS" when we mentioned mutually
authenticated, but we may also have made a mistake, so please let us know.

"""
The entity within the DOI responsible to handle these communications is the
DM and communications between the HNA and the DM MUST be protected and mutually
authenticated.  While Section 4.6 discusses in more depth the different
security protocols that could be used to secure, it is RECOMMENDED to use
TLS with mutually authentication based on certificates to secure the
channel between the HNA and the DM.
"""

There are two common cases to get the client cert. The first one is out-of
band configuration. The second is using a self signed certificate when the
ISP for example identifies the lines. We believed it was better to mandate
mutually authenticated users at all times to avoid multiple versions /
capabilities of the HNA.
</mglt>

> have implemented and interop'd before we could be confident of
<mglt>
I think this statement overestimates the complexity. The exchanges
described are fairly standard and the space for confusion is limited.  We
have an implementation which I think is sufficient.  The apparent
complexity may come from the use of NSUPDATE itself that we are less
familiar with than AAAA.
</mglt>

> stated or solved somehow?
<mglt>
I do not understand the comment. I suppose the ISP owns the prefix it is
delegating. Please point me to the text that is confusing, I am happy to
clarify it.
</mglt>

> multiple implementations that interop.
I think that section 10 and 14 may be merged together. On the contrary, I
see that defining default values and parameters will help interoperability.
I have created the following issue:
https://github.com/ietf-homenet-wg/ietf-homenet-hna/issues/48
</mglt>

> just set out the mechanism.
correct. often has been removed.
</mglt>

> - abstract: "using names" should probably be "using DNS names
I am fine changing this to DNS names. The reason for having names here was
that most people using these names do not even know they are using DNS
names. In other words, the motivation is more on the names than the use of
DNS. Changed to DNS names.
</mglt>

> - abstract: documents don't "automate" things
changed to :
"""This document describes how to automate the process through..."""
</mglt>

>    that, the FQDNs published are those of servers.
The servers in questions are the DNS servers the text is changed to:

"""This document describes how to automate the process through the creation
of a Homenet Naming Authority (HNA), whose responsibility is to select,
sign and publish DNS names to a set of publicly visible
DNS servers."""

</mglt>

>    this just a new flavour of feeding zones to a DNS
The naming service of a homenet is the ability to respond to (DNS) names
that corresponds to the homenet.  Changed to:
"""the home network naming service."""
</mglt>

>    that with split horizon or something?
 <mglt>
The intent is to mention that all representations publicly available are
expected to be in this Zone.  This contrast with DNS split as well as
various possible resolutions, discovery mechanisms that could be used.
</mglt>

> different DNS recursive for clients and ULAs could be handled
<mglt>
Apparently this is a use case people had, but it is also important in my
view to mention that the type of address does not define the type of
resolution / discovery mechanism.
</mglt>

>    probably a bad idea to name specific commercial DDNS
We removed Dyn, Gandi and added the ddclient link to DDNS.
</mglt>

> outsourcing infrastructure"/DNOI?
Correct. I opened the issue:
https://github.com/ietf-homenet-wg/ietf-homenet-hna/issues/49
</mglt>

>    of recursive resolver. Aren't those already defined
The two resolvers are defined below:

The two resolvers proceed differently, so it seems to us clearer to
position and define them clearly. I do not think we would have a common
understanding with terms defined elsewhere. Typically, some resolvers
resolve internally while others do not. The term public resolver is often
used but also raised some discussions.
"""
   Homenet DNSSEC Resolver:  a resolver that performs a DNSSEC
      resolution on the home network for the Public Homenet Zone.  The
      resolution is performed requesting the Homenet Authoritative
      Servers.

   DNSSEC Resolver:  a resolver that performs a DNSSEC resolution on the
      Internet for the Public Homenet Zone.  The resolution is performed
      requesting the Public Authoritative Servers.
"""
</mglt>

> That seems like an important thing to be clear about.
Changed to:

""" [...] and are represented as Homenet Zone in Figure 1."""
</mglt>

> might not be something needing protocol but it definitely needs
I do not think that this should be mentioned in the architecture overview
section as no mention of the ZSK/KSK have been made.
We add the following section in the security consideration

"""
## Operational Considerations

The HNA is expected to sign the DNSSEC zone and as such hold the private
KSK/ZSK.
To provide resilience against CPE breaks, it is RECOMMENDED to backup these
keys to avoid an emergency key roll over when the CPE breaks.
"""
</mglt>

> - 3.2: What DoX implementation supports TLS client auth?
BIND and Unbound uses OpenSSL which supports client authentication. Note
that the DM can be implemented with a limited set of exchanges.
</mglt>

> - 3.2: I don't get why a single IP/port is needed for the DM.
We did not provide the ability of the DM to be configured as a secondary on
a different IP address than the one used . Similarly we also wanted the
synchronization channel and the control channel to use the same protocol.
This was believed to bring unnecessary complexity. Such capabilities may be
added in the future.
</mglt>

> already used/populated/whatever?
This AXFR is just to retrieve the configuration parameters the DOI expect
to appear in the Public Zone. These parameters are expected to remain
stable, and regularly checked by the HNA.
</mglt>

> and am sure many have done so, but I bet there are corner-cases

<mglt>
The DNS template is used to carry some specific information and explicitly
lists how this information is carried. I do not see corner cases. It is not
a template that is globally applied. The reason we designate it as a
template is that these parameters are likely to be reused by all clients.
</mglt>

>    least XX seems to require an IANA action or the re-use of
YYYY and ZZZZ designate a high port range and XX designates the port
associated to well known port. These port are not defined in this
specification. In this specification XX is likely to designates DoT. The
reason for using the letters is to clearly explain that the Control Channel
and Synchronization Channel cannot be mixed.

The following text should clarify the concern:
"""
The DM Synchronization Channel is used for communication between the HNA
and the DM for synchronizing the Public Homenet Zone.

Note that the Control Channel and the Synchronization Channel are by
construction different channels even though there they may use the same IP
address.
Suppose the HNA and the DM are using a single IP address and let designate
by XX, YYYY and ZZZZ the various ports involved in the communications.

In fact the Control Channel is set between the HNA working as a client
using port number YYYY (a high range port) toward a service provided by the
DM at port number XX (well known port such as 853 for DoT).

"""

</mglt>

> any worked-out description of using DANE for DoX.
The intention of the text is to mention that other mechanisms can be used.
DANE is only used to carry the certificate.
</mglt>

> update. (My nearest OpenSSL install has an /etc/ssl/certs
<mglt>
In this case I imagine the certificate being specific to the HNA
(application) and provisioned as a sort of TA, CA... In particular I do not
think the backed-in should be used for any other purposes. I opened an
issue to clarify that point.
https://github.com/ietf-homenet-wg/ietf-homenet-hna/issues/50
</mglt>

>    here but I didn't read RFC8672 just now so maybe it's all
This is to ensure that the DM you started with remains the same one across
the exchanges.
</mglt>

> [I-D.ietf-homenet-naming-architecture-dhc-options]."
The ISP manages a DOI for the IP prefix domain name, identifies the line to
which the IP prefix is assigned which makes out-of band configuration of
the client unnecessary. Without such out-of-band step, the process can be
completely automated.
</mglt>

> you want to risk the latter being some reader's interpretation.
Thanks. You are correct I prefer not to take the risk. When reading I did
not go further than it is a word and the one I know is a kid's movie, so I
did not pay attention. I changed it to aeae.
</mglt>

>    just one is probably better, unless there's a reason they
Changed to myhome.example. Thanks.
</mglt>

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 26 May 2021 13:15:17 -0400

Hi Juliusz,

I think we responded to the question in 2014 [1]. I am happy to clarify our
text of section 1.2. Could you please point out what in the draft you
believe is wrong and what you would like to be updated.

Yours,
Daniel

[1]
https://mailarchive.ietf.org/arch/msg/homenet/qL5BmPs5LOi281AMTCD_lHt49Is/

-- 
Daniel Migault
Ericsson

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 May 2021 20:37:33 +0100

Hiya,

A few responses below...

On 26/05/2021 18:02, Daniel Migault wrote:
> responses inline. I updated the document [1] and added issues on the
> git repo.
> 
> Yours, Daniel
> 
> [1] 
> On Mon, May 24, 2021 at 5:01 PM Stephen Farrell
> <[email-masked]> wrote:
> 
>> 
>> Hiya,
>> 
>> I had a read of this one. My comments (as an individual, not as
>> chair) below. I'll chat with Barbara to see if we have a common
>> position on how to handle next steps but am happy to chat about
>> stuff below whenever.
>> 
>> Cheers, S.
>> 
>> review of draft-ietf-homenet-front-end-naming-delegation-15 sf,
>> 20210524
>> 
>> general/technical:
>> 
>> server for it's public zone, then how is it robust enough to resist
>> attack/DoS on the addresses exposed in that zone? That seems to me
>> to counter a bunch of the arguments for this approach, so I'd like
>> to understand the proponents arguments there. At minimum, any AAAA
>> for an "inside" server/name means that the CPE's f/w will be
>> subject to the same kind of attacks that might happen if the CPE
>> was the only/primary DNS server for the zone.
>> 
>> <mglt>
> terminate services. Resources of the CPE are estimated for
> volumetric attacks that are expected to be handled by the ISP.
> Hosting DNS changes the scope on that the CPE becomes an addressable
> target, subject to application DoS attacks which it has not been in
> general designed for and which are much harder to tackle for an ISP
> as this is "legitimate" traffic. The document does not specify the
> HNA is addressable from inside the network and Figure 1 clearly
> separates the authoritative server from the HNA. Of course this could
> be implemented this way, but I am wondering if there is any text that
> suggests such an approach.  It seems to me that discussion over the
> management of the authoritative DNS server on the CPE is out of the
> scope of the document. In addition, if an DDoS attack is handled from
> inside the homenet, the network admin is more likely to unplug that
> device than if performed from the Internet. </mglt>

I still don't get it sorry. Shodan and zmap will allow anyone
to find the listening port in many cases, regardless of that
being port 53/853 on the CPE or 443 (or even, gulp! port 80)
on some host further into the homenet.

My point here is not that one ought not provide a listening
process within a homenet, but only that this proposal doesn't
really solve robustness issues.

>> #3 The arguments about handling "disruption with the ISP" could do
>> with some more evidence, not necessarily as text in the draft, but
>> it ought exist - does it? E.g. do we know that publishing ULAs
>> isn't problematic? Do we know that GUAs in such scenarios aren't
>> still usable for longish durations given a realistic pattern of ISP
>> disruption?
>> 
>> <mglt>
> ISP disruption is not an argument but a requirement from RFC7368
> section 3.7.5. I think we all experience some connectivity
> disruption, so I do not believe there is a need to clarify this
> exists. The most obvious case is equipment that goes down for some
> time.  

Sure. To try re-phrase my question: do we have evidence
that the approach proposed here is more robust in that
scenario? Yes I can see that resolving foo.myhome.example
from inside to the HNA should still work, but how much better
will that be *overall* given that foo.myhome.example may be
cached in the stub resolver of clients on the homenet? I'm
wondering if anyone's tried that kind of thing and said
what they found basically. (And similarly wondering if
publishing ULAs in the public DNS has any downsides.)

> A transition from one ISP to another seems to me a bit out of
> scope of the document. The document considers renumbering which could
> be a good start for a more complex management transition, that sounds
> to me very specific and out of scope of the document. We have added a
> section in the security consideration that I think covers your
> concern: """ The HNA enables to handle network disruption as it
> contains the Public Homenet Zone, which is provisioned to the Homenet
> Authoritative Servers.
> 
> However, DNSSEC validation requires to validate the chain of trust
> with the DS RRset that is stored into the parent zone of the
> Registered Homenet Domain. As currently defined, the handling of the
> DS RRset is left to the Homenet DNSSEC resolver which retrieves from
> the parent zone via a DNS exchange and cache the RRset according to
> the DNS rules, that is respecting the TTL and RRSIG expiration time. 
> Such constraints do put some limitations to the type of disruption
> the proposed architecture can handle. In particular, the disruption
> is expected to start after the DS RRset has been resolved and end
> before the DS RRset is removed from the cache. One possible way to
> address such concern is to describe mechanisms to provision the DS
> RRset to the Homenet DNSSEC resolver such as HNCP for example. Such
> work is out of the scope of this document and is left from future
> work. """
> 
> Similarly, the zone content is also a bit out of scope of the
> document and the admin is supposed to be responsible for what he is
> publishing. The text mentions the publication of ULA with a may, as
> an example. I think it is useful to have this as a consideration but
> elaborating on this may end up in a complete book of managing the
> homenetwork, which I do not think is the purpose of this - already
> long - document. Removing the text would not affect the scope of the
> document, but I think it is useful information to avoid some
> mis-conceptions. </mglt>
> 
>> reboot/power outage at the DSLAM, which happens maybe twice a year.
>> How would this protocol handle that? Would the DM get overloaded
>> maybe?
>> 
>> <mglt>
> As per RFC 8415, 7291, I expect CPE are gradually brought up.

The CPE doesn't go down in the scenario I mentioned. All
the CPEs in some local region get renumbered at once though.

> However, assuming such a crowd event happens, it seems reasonable to
> assume the DM is able to deal with DNS  SERVFAIL, TLS internal_error,
> TCP RST, HTTP 503...  I see this as a standard service provided by
> any cloud provider. It is also unclear to me how this is different
> from all CPE reconnecting to a common service/app such as Google Mail
> for example. I do not think additional text is needed here, but maybe
> you would like something being added into the Security configuration.
> Is that what you had in mind ? </mglt>

I wasn't looking for specific text, but wondering if that
crowd event scenario had been considered.

> 
> 
>> #5 The arguments why this is better than DDNS don't convince me,
>> except for the last one (new RR types).  Given that DDNS is 
> To me scalability a standard interface for (any) DNS RRSet that is
> scalable is the most convincing argument. Currently Dynamic DNS
> consists of multiple distinct protocols. [1] lists 11 of them, I am
> not sure Gandi has been included either [2], not all versions are
> using TLS. Their usage is mostly intended for a single or a very
> limited number of RRsets. The HNA seems more appropriate for a home
> network. For example, if all devices have a client, all devices need
> to be manually provisioned every time you change your homenet domain,
> every time your account/provider changes... which hardly scales.

Sure, I get that. My own conclusion for now differs - I don't
see this as being sufficiently better than DDNS in enough
scenarios to displace the already-deployed thing. But that's
just one opinion.

> 
> [1] https://ddclient.net/protocols.html [2]
> https://github.com/rmarchant/gandi-ddns </mglt>
> 
>> not? E.g. say an ISP has the DOI servers "first" in how it resolves
>> names for a local area, what'd stop some home from claiming to be
>> windowsupdate.com?
>> 
>> <mglt>
> The situation is similar as today, the DOI needs to have some
> guarantees you really own the domain. The DOI is expected to be a
> sort of registrar which could be limited to owning a domain. 

Sorry I don't get that. Why would the DOI need to be a
registrar for anything?

> In the
> example windowsupdate.com I hardly see .com doing the delegation to
> the DOI without strong evidence that the DOI owns windowsupdate.com.
> 
> To me this looks obvious, so we may have underestimated this aspect.
> I have opened an issue, to carefully address this. If you have any
> text you would like to see, please feel free to propose it. 

Windowsupdate.com is just an example of a frequently
targetted name. The set of such names in any particular
context is never really obvious, to me at least;-)

> <mglt> It is unclear to me if you are referring to a specific
> paragraph in the document, but it is likely that the CPE will perform
> some kind of checks and a DNSSEC resolution to a domain it owns is
> likely to be done. Sure the DOI may cheat, but if that is the case,
> the DS will hardly provide any significant protection as the DOI may
> still respond non DNSSEC to user users than the homenet. This will
> make it hard to detect. I currently do not see this as a major
> threat, but I might be missing something. </mglt>

Anyone who can write/replace the DS in the parent zone can
at any time spoof as the child, should they wish to.

>> long the home n/w can handle ISP disruption? If so, be good to say
>> so. I also wonder if that limits the added-value here or not.
>> 
>> <mglt>
> Currently the DS puts some limit to the ISP disruption, but section
> 3.1 mentions that other mechanisms to enable resolutions to the DNS 
> authoritative servers may be designed in the future. This
> specification does not change the DNS, nor create HNCP mechanisms.
> If future usage requires it, specific handling will need to be
> defined. To my perspective, such mechanism
> 
> We added some specific text in the Security Consideration ( see
> above regarding the disruption).
> 
> </mglt>
> 
>> RECOMMENDED), seems like a circular dependency. How does the HNA
>> get that client-cert before/at the start?
>> 
>> <mglt>
> I am reading the following text in section 3.2 where we mandate a
> mutually authenticated communication and recommend TLS among the
> other protocols that can do that. I suspect you added "TLS" when we
> mentioned mutually authenticated, but we may also have made a
> mistake, so please let us know.

Huh? The only protocol specified in the draft that
can (in theory) provide mutual auth is DNS/TLS aka
DoT. If the intent was that some other option was
really well-defined enough to be usable, then I
think there's a bunch of text missing.

> 
> """ The entity within the DOI responsible to handle these
> communications is the DM and communications between the HNA and the
> DM MUST be protected and mutually authenticated.  While Section 4.6
> discusses in more depth the different security protocols that could
> be used to secure, it is RECOMMENDED to use TLS with mutually
> authentication based on certificates to secure the channel between
> the HNA and the DM. """
> 
> There are two common cases to get the client cert. The first one is
> out-of band configuration. The second is using a self signed
> certificate when the ISP for example identifies the lines. We
> believed it was better to mandate mutually authenticated users at all
> times to avoid multiple versions / capabilities of the HNA. </mglt>

ISTM, that client-cert causes all sorts of ramifications for
when this proposal could really work. I'm not sure those are
well understood, for me at least.

>> this.  Wouldn't this kind of thing need a bunch of people to have
>> implemented and interop'd before we could be confident of the
>> spec?
>> 
>> 
> <mglt> I think this statement overestimates the complexity. 

Well, maybe others will find things, but TBH, I've not heard
anyone say that. Does anyone else think I'm wrong?

> The
> exchanges described are fairly standard and the space for confusion
> is limited.  We have an implementation which I think is sufficient.
> The apparent complexity may come from the use of NSUPDATE itself that
> we are less familiar with than AAAA. </mglt>
> 
>> the reverse zone stuff, nor do I see the overall thing here would
>> work where the ISP provides those reverse-IP stanzas for a zone
>> file but where that ISP has no way to update the parent's DS
>> record. Are there a set of "just doens't work" configurations there
>> really?  If so, shouldn't that be either stated or solved somehow?
>> 
>> 
> <mglt> I do not understand the comment. 

I'm asking who'll be doing reverse lookups. The only case I
can think of is if the service inside the homenet is a mail
server, but there's likely much more to do to try get such
a thing working in the modern mail ecosystem.

(I'm a bit short of time now, so there's only one more
comment below, but TBH I think it's a bit of a killer
argument here if I'm right about it;-(

> I suppose the ISP owns the
> prefix it is delegating. Please point me to the text that is
> confusing, I am happy to clarify it. </mglt>
> 
>> requirements but also things needed for interop (e.g. use DoT on
>> 853). I'm not convinced that's a good plan if we want multiple
>> implementations that interop.
>> 
>> <mglt>
> I think that section 10 and 14 may be merged together. On the
> contrary, I see that defining default values and parameters will help
> interoperability. I have created the following issue: 
>> - abstract: "often" where's the evidence for that? Why do you even
>> need to make that (questionable) assertion? Better to just set out
>> the mechanism.
>> 
>> <mglt>
> correct. often has been removed. </mglt>
> 
>> - abstract: "using names" should probably be "using DNS names or
>> similar"
>> 
>> <mglt>
> I am fine changing this to DNS names. The reason for having names
> here was that most people using these names do not even know they are
> using DNS names. In other words, the motivation is more on the names
> than the use of DNS. Changed to DNS names. </mglt>
> 
> changed to : """This document describes how to automate the process
> through...""" </mglt>
> 
>> - abstract: "servers" - you don't know, and shouldn't require that,
>> the FQDNs published are those of servers.
>> 
>> <mglt>
> """This document describes how to automate the process through the
> creation of a Homenet Naming Authority (HNA), whose responsibility is
> to select, sign and publish DNS names to a set of publicly visible 
> DNS servers."""
> 
> </mglt>
> 
>> - abstract: "the naming service" - what's that exactly? Isn't this
>> just a new flavour of feeding zones to a DNS authoritative?
>> 
>> <mglt>
> The naming service of a homenet is the ability to respond to (DNS)
> names that corresponds to the homenet.  Changed to: """the home
> network naming service.""" </mglt>
> 
> <mglt> The intent is to mention that all representations publicly
> available are expected to be in this Zone.  This contrast with DNS
> split as well as various possible resolutions, discovery mechanisms
> that could be used. </mglt>
> 
>> 
>> justification. Seems more likely a VPN could/would set a different
>> DNS recursive for clients and ULAs could be handled there.
>> 
> <mglt> Apparently this is a use case people had, but it is also
> important in my view to mention that the type of address does not
> define the type of resolution / discovery mechanism. </mglt>
> 
>> 
>> probably a bad idea to name specific commercial DDNS services.
>> 
>> <mglt>
> We removed Dyn, Gandi and added the ddclient link to DDNS. </mglt>
> 
>> - section 2: "DOI" isn't a good choice - every RFC has one of those
>> and it's not what's defined here:-) If you could avoid the acronym
>> collision that'd be better. Maybe "domain name outsourcing
>> infrastructure"/DNOI?
>> 
>> <mglt>
>> - section 2: I'm not seeing why you need (new?) terms for types of
>> recursive resolver. Aren't those already defined elsewhere?
>> 
>> <mglt>
> position and define them clearly. I do not think we would have a
> common understanding with terms defined elsewhere. Typically, some
> resolvers resolve internally while others do not. The term public
> resolver is often used but also raised some discussions. """ Homenet
> home network for the Public Homenet Zone.  The resolution is
> performed requesting the Homenet Authoritative Servers.
> 
> DNSSEC Resolver:  a resolver that performs a DNSSEC resolution on
> the Internet for the Public Homenet Zone.  The resolution is
> performed requesting the Public Authoritative Servers. """ </mglt>
> 
>> - 3.1: I have no idea what is meant by: " The ".local" as well as
>> ".home.arpa" are explicitly not considered as Public Homenet zones
>> and represented as Homenet Zone in Figure 1." That seems like an
>> important thing to be clear about.
>> 
>> <mglt>
> Changed to:
> 
>> scenario as CPE kit breaks or is discarded. That might or might not
>> be something needing protocol but it definitely needs mention.
>> 
>> <mglt>
> I do not think that this should be mentioned in the architecture
> overview section as no mention of the ZSK/KSK have been made. We add
> the following section in the security consideration
> 
> """ ## Operational Considerations
> 
> The HNA is expected to sign the DNSSEC zone and as such hold the
> private KSK/ZSK. To provide resilience against CPE breaks, it is
> RECOMMENDED to backup these keys to avoid an emergency key roll over
> when the CPE breaks. """ </mglt>
> 
> BIND and Unbound uses OpenSSL which supports client authentication.
> Note that the DM can be implemented with a limited set of exchanges. 
> </mglt>

Nah, that's not enough. There's a lot more code needed to
get to client-auth for DoT. Do we then agree that there's
no current way to get to mutually authenticated DoT? Isn't
that a bit of a killer here?

Cheers,
S.

> We did not provide the ability of the DM to be configured as a
> secondary on a different IP address than the one used . Similarly we
> also wanted the synchronization channel and the control channel to
> use the same protocol. This was believed to bring unnecessary
> complexity. Such capabilities may be added in the future. </mglt>
> 
>> 
>> - 4.5.1: "MUST send a DNS request of type AXFR associated to the
>> Registered Homenet Domain" - what if the domain is already
>> used/populated/whatever?
>> 
>> <mglt>
> This AXFR is just to retrieve the configuration parameters the DOI
> expect to appear in the Public Zone. These parameters are expected to
> remain stable, and regularly checked by the HNA. </mglt>
> 
>> - 4.5.1: Where else is there the concept of a "zone template"? If
>> nowhere else then I wonder if that concept needs some more review?
>> (I can well imagine how to make a zone file template and am sure
>> many have done so, but I bet there are corner-cases galore.)
>> 
> 
> <mglt> The DNS template is used to carry some specific information
> and explicitly lists how this information is carried. I do not see
> corner cases. It is not a template that is globally applied. The
> reason we designate it as a template is that these parameters are
> likely to be reused by all clients. </mglt>
> 
>> 
>> - section 5: What are YYYY, ZZZZ and XX supposed to be?  At least
>> XX seems to require an IANA action or the re-use of some port
>> number?
>> 
>> <mglt>
> specification. In this specification XX is likely to designates DoT.
> The reason for using the letters is to clearly explain that the
> Control Channel and Synchronization Channel cannot be mixed.
> 
> The following text should clarify the concern: """ The DM
> Synchronization Channel is used for communication between the HNA and
> the DM for synchronizing the Public Homenet Zone.
> 
> construction different channels even though there they may use the
> same IP address. Suppose the HNA and the DM are using a single IP
> address and let designate by XX, YYYY and ZZZZ the various ports
> involved in the communications.
> 
> In fact the Control Channel is set between the HNA working as a
> client using port number YYYY (a high range port) toward a service
> provided by the DM at port number XX (well known port such as 853 for
> DoT).
> 
> """
> 
> </mglt>
> 
>> should be a way to make it work but I don't think I've seen any
>> worked-out description of using DANE for DoX.
>> 
>> <mglt>
> The intention of the text is to mention that other mechanisms can be
> used. DANE is only used to carry the certificate. </mglt>
> 
> 
>> - 5.1: "baked-in" isn't right - typically those lists are updated
>> by the OS (e.g. OpenWRT) or via application s/w update. (My nearest
>> OpenSSL install has an /etc/ssl/certs directory.)
>> 
> <mglt> In this case I imagine the certificate being specific to the
> HNA (application) and provisioned as a sort of TA, CA... In
> particular I do not think the backed-in should be used for any other
> purposes. I opened an issue to clarify that point. 
>> here but I didn't read RFC8672 just now so maybe it's all clear
>> from tha - is it?
>> 
>> <mglt>
> This is to ensure that the DM you started with remains the same one
> across the exchanges. </mglt>
> 
>> up automatically the relation between HNA and the DNS Outsourcing
>> infrastructure as described in 
> The ISP manages a DOI for the IP prefix domain name, identifies the
> line to which the IP prefix is assigned which makes out-of band
> configuration of the client unnecessary. Without such out-of-band
> step, the process can be completely automated. </mglt>
> 
>> - section 9: "2001:db8:babe:0001::2" - the string "babe" has both
>> innocent and less innocent interpretations, not sure if you want to
>> risk the latter being some reader's interpretation.
>> 
>> <mglt>
> Thanks. You are correct I prefer not to take the risk. When reading I
> did not go further than it is a word and the one I know is a kid's
> movie, so I did not pay attention. I changed it to aeae. </mglt>
> 
>> just one is probably better, unless there's a reason they ought
>> differ.
>> 
>> <mglt>
> Changed to myhome.example. Thanks. </mglt>
> 
>> - 11.1: is a subsection needed there really? (I kinda skipped all
>> that text TBH;-) _______________________________________________ 
>> homenet mailing list [email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Fri, 28 May 2021 20:57:14 -0400

Hi Stephen,

Please find inline some responses or follow-up discussion.

Yours,
Daniel

> really solve robustness issues.
It seems to me that your concern is that the HNA (while not serving the
zone to the internet or in the homenet) remains exposed with a listening
port (on the internet) to sync the zone with the secondary servers (DM).
If that is correct, I believe that section 7 addresses this concern. In
short, the HNA does not expose any listening port, as communications are
restricted to the DM and thus protected by a firewall. While out of scope
of the document, a similar configuration may be applied between the Homenet
Authoritative server and the HNA if these two entities were not co-located.
Does it address the concern ?

Now that this listening port concern has been fixed. I believe we can agree
that the proposed architecture provides a more robust way (internally and
externally) to host a DNS service for the homenet, than hosting the server
on the CPE.

> publishing ULAs in the public DNS has any downsides.)
Thanks for the clarification. It seems to me that the response to the
"overall better" is DNS versus hosts files.
If you are taking a new device during the disruption, we can expect the
cache to be empty, in which case a DNS resolution is needed. In this case
the main advantage provided by a local resolution is that every device has
the same view of the network.
For a device / app that has the DNS RRSet in its cache, a reconnection will
be possible as long as the TTL has not expired. The larger the TTL is the
higher the probability we have to overcome an ISP disruption. Now very long
TTLs also come with some drawbacks. Suppose the disruption generates a
renumbering, you may access your device using ULA which is likely to remain
unaffected, but not the GUA. As a result, the use of DNS seems to at least
improve dynamic configuration and consistency.

> We considered it, but I do not see it as an issue, so I am wondering if
there is something specific you would like us to address.
My interpretation regarding the scenario of a DSLAM going down is that
renumbering is performed via DHCPv6 which prevents all CPE to be configured
at the same time.  Is there anything I am missing in the scenario ?

> There might be different segments. It is also unlikely DDNS will evolve in
a common way without any (IETF) standard for it.

> Sorry I don't get that. Why would the DOI need to be a
First there is a check that the name matches the one of the
registered homenet domain.

Regarding the registered homenet domain, I hardly see a DOI committed to
serving names without evidence of ownership. Such ownership may be provided
via a client account, a name assigned,....
In addition, updating the DS RRset to the parent zone may be similarly hard
without proof of ownership associated.
That said, I think the scenario you describe is that the Homenet Resolver
is configured as a forwarder with the DOI. More specifically, the Homenet
Resolver will FIRST look at the DOI, and then perform a DNS resolution over
the Internet. This is not how resolvers behave in general. As a result, the
DOI would contain information that is published globally but that is only
applicable locally. If I understand it correctly, such policies will have
no effect globally - as these will be ignored by any other resolvers.

> I agree. This is true also without DNSSEC, so with any request without
DNSSEC enabled, or any time DNSSEC RRsets are not provided in the response.

> The architecture requires a mutually authenticated channel. We recommend
TLS, but other mechanisms could be used.  Section 4.6 describes different
alternatives as well as the rationale for recommending TLS. I see TLS,
IPsec, (eventually) TSIG/SIG(0) providing mutual authentication. XoT has
already defined DNS over mutually authenticated TLS. I interpete "(in
theory)" as doubting that mutually authenticated TLS  is feasible. If that
is the case, I am wondering why we have such a statement.

I however agree that the current text might better position the use of TLS
regarding the XoT work, as TLS is the recommended protocol.

> well understood, for me at least.
Maybe you could expand the issues you envision. The most straightforward
way to provision the client certificates is that the DOI provides both the
key and certificate to the client. ACME is also one possibility the client
uses to generate its certificate. How the certificate is provisioned or
generated is thought out of scope of the document.
That said, I suggest you provide more details regarding your concerns and
mention to what extent we differ from the other cases where client
certificates are used.

> a thing working in the modern mail ecosystem.

The document describes how the reverse zone can be provisioned. More
specifically, the provisioning uses the same mechanism as the forward zone
with some simplification, which in my opinion is worth mentioning. Whether
this will be useful or not is a bit orthogonal to the document and
such discussion is delegated to RFC 8501. As far as I can tell, reverse IP
addresses are not limited to mail servers and I do see some advantages at
least for management purposes.

> that a bit of a killer here?
I do not agree saying that mutual authentication requires a lot more code
than strict TLS nor that there is no current way to to get mutual
authentication. Mutual authentication is implemented by OpenSSL. I do not
see what prevents a DNS exchange to be run over a mutually authenticated
TLS session.
In addition, XoT specifies client authentication for DoT and recommends
client authentication. OARC35 [1] announced ongoing support for XoT by NSD,
Unbound, BIND, PowerDNS and [2] is the commit "New configuration variables
for client-side certificate".  I believe we can reasonably say mutual
authentication is on its way to become widely available.

[1]
https://indico.dns-oarc.net/event/38/contributions/857/attachments/802/1470/oarc35-xot-slides.pdf
[2]
https://github.com/NLnetLabs/nsd/commit/044c4b5d267dba69996267164395c6ed799e389b

-- 
Daniel Migault
Ericsson