Re: [Last-Call] [homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18

Hi Matt,

Thanks for the review. I am only responding to the major comments - for
now. I apologize for the partial response but I promise I will go through
all other comments tomorrow (my) morning and hope you will still have this
partial response (your) morning.

Yours,
Daniel

On Mon, Oct 17, 2022 at 9:11 AM Matt Brown via Datatracker <noreply@ietf.org>
wrote:

> Reviewer: Matt Brown
> Review result: Not Ready
>
> Kia ora,
>
> I'm a recent addition to dnsdir and have been asked to review this draft -
> this
> is my first formal IETF review, so apologies in advance if I don't quite
> hit
> the right spot in terms of what's looked for here - in particular I'm not
> sure
> how calibrated my "Result" status selection is...
>
> Review Conclusion:
>
> The intent and proposed mechanism the draft seeks to achieve is clear and
> the
> proposed high-level architecture of a hidden master is consistent with the
> overall format of the DNS ecosystem.
>
> The proposed implementation of the control channel requires a mode of
> communication (mutual TLS authentication via DoT) that is not an existing
> standards, nor specified in this document and therefore appear infeasible
> to me
> without further specification taking place.
>
> There are a number of other gramatical nits and improvements in wording
> which
> are needed to improve the clarity and understandability of the standard
>
> Major Issues (aka Not Ready):
>
> Mutual TLS and DoT - 3.2 and 4.6 recommend that the HNA and DM secure their
> control channel communications using mutual TLS and DoT - but DoT is not
> specified to support mutual authentication. While mutual TLS auth at the
> underlying TLS layer is clearly viable - how to integrate that at the DNS
> layer, and whether that is compatible with DoT on the existing port, or
> would
> need a further port allocation (and subsequent IANA consideration in 13)
> would
> need to be addressed. None of the alternative future protocols listed in
> 3.2
> support mTLS either as far as I am aware.
>
> Given the recommendation to use XoT (RFC9103) (which does specify mTLS
> capability) for the Synchronization channel in 5.1 - I wonder why this
> protocol
> has not also been considered for the control channel instead of DoT?
>
> The section securing the Synchronization channel  mentions:

The AXFR request from the DM to the HNA SHOULD be secured and the use of
TLS is RECOMMENDED {{!RFC9103}}.

So this is effectively what we rely on, mostly for the following reasons:
1) most of our exchanges are IXFR/AXFR and these are the one with the main
concern, and 2) we wanted to reuse what is implemented in major
distributions.
To put it in another way, we wanted the transaction between the HNA and the
DM to be protected by TLS, and probably split from DNS over TLS to DoT. Would
replacing DoT by XoT address your concern ?

I would be happy to understand though why DoT would be an issue. The only
point I can see is that 7858 specifies that it limits its scope to client
-to resolver communications while admitting such restriction is due to a
charter limitation. Since XoT mentions it is heavily relying on DoT, and
resolvers and authoritative servers both handle DNS packets, I tend to
assume that we may consider DoT can be used for any DNS communications, but
I might be missing something.

Another point I would like to clarify is why another port would be needed
for mTLS as this is a capacity announced by the TLS server. The support of
mTLS is simply announced by the server by sending a CertificateRequest. The
TLS client may only accept such communications. I do not necessarily see
this as an issue, but again maybe I am missing something.

As written (recommending DoT with mTLS), I do not believe this standard is
> implementable.
>
>
> Minor Issues (aka Ready with Issues):
>
> 2 and 3.1: DNSSEC Resolver - is the exclusion of unsigned/non-DNSSEC
> resolvers
> in the terminology and architecture overview intentional? Section 9
> confirms
> that DNSSEC is not required (only RECOMMENDED), so it is possible that
> both the
> public and internal resolvers being used are not DNSSEC capable -
> therefore it
> seems strange for the architecture overview and terminology to imply that
> DNSSEC is required.
>
> 3.2: The 4th paragraph begins describing "the main issue", the solution to
> which is not explained in the paragraph, or in the referenced Section 4.2
> (which is DNSSEC/DS specific vs the NS, A, AAAA context of the paragraph).
> In
> either case, the semantics of how the DM treats the information it receives
> from the HNA seems out of place in a section describing and primarily
> focused
> on the mechanics of the communication channel itself. I suggest removing or
> rewriting this 4th paragraph to improve the clarity.
>
> 4: I find the format of this section confusing and hard to understand with
> sections 4.1-4.4 describing the information to be conveyed, but not how it
> is
> conveyed, and then the message formats being described in 4.5. I suggest it
> would be much clearer and more understandable to combine the details in
> 4.5.x
> with the earlier sections (e.g. put the AXFR details from 4.5.1 into 4.1,
> and
> the DNS update details from 4.5.2/4.5.3 into 4.2 and 4.3.
>
> 12: I wonder how protected the HNA actually is and whether more
> exploration/discussion of the risks invovled is required here - in an IPv4
> use-case, the IP for the services published in the Public Homenet Zone is
> highly likely to be the same IP with an open DNS port for the DM to
> connect to
> for XFR, and while the relationship in IPv6 is not as straightforward
> given the
> likely use of privacy addressing, etc it's not particularly hard to scan
> the
> enclosing /64 or beyond for an address with an open DNS port.
>
> Given the HNA is already opening a control connection to the DM, was
> consideration given to re-using that connection (or a 2nd HNA initiated
> connection to a different address if there is the need for different
> servers in
> the DM implementation between control/sync channesl) to prevent the need
> for
> opening any listening port on the HNA WAN addresses at all?
>
>
> Nits (aka Ready with Nits):
>
> 1.1: This section is titled Selecting *Names* to Publish, but spends the
> majority of its words actually discussing the nuances of which *addresses*
> to
> publish for the selected names. This section may be more accurately and
> cleary
> named to include address selection.
>
> 1.3: There is a missing word (scenarios) in the first sentence which I
> think
> needs to read: "A number of deployment *scenarios* ...
>
> 1.3.1: The example would be simpler and clearly if it just stated that the
> vendor provisions each device with a TLS key pair and certificate matching
> the
> assigned name which are used for mutual authentication. The current
> discussion of
> 'proceeding to authentication' is confusing, as it's not a phrase I've
> encoutered
> before and implies to me that authentication is not completed using the
> cert/keys, while the explanation about needing both names/keys for
> regeneration
> seems neither necessary or correct (any trusted key can be used to replace
> itself, whether or not a certificate with name is also present).
>
> 1.3.2: I think it would be simpler and clearer if the example focused
> solely on
> establishing trust between DOI/HNA via the provision of credentials and
> omitted
> the speculation about verification of ownership that may or may not be
> required, and seems like a very separate concern at a different level of
> the
> stack.
>
> 2. Clarification of some definitions
>
> Registered Homenet Domain: Given there can be multiple Public Homenet
> Zones,
> presumably there can also be multiple Registered Homenet Domains which
> should
> be stated here for clarity.
>
> Public Authoritative Servers: s/for the Homenet Domain/for the Registered
> Homenet Domain/ - 'Homenet Domain' alone is not a defined term.
>
> Homenet Reverse Zone: Why is this not called the 'Public Homenet Reverse
> Zone'?
> Given the 'Homenet Zone' is private, and this is considered the reverse
> for the
> 'Public Homenet Zone' this seems like a confusing inconsistency. Every
> other
> term starting Homenet refers to an internal resource, while the
> corresponding
> external resources all start with 'Public' except in this case. So I would
> expect the Homenet Reverse Zone to be the private zone matching home.arpa
> containing RFC1918 and IPv6 ULA addresses, etc.
>
> 3.1: s/detaille din/detailed in/ - in the final sentence of the first
> paragraph.
>
> 3.1: "The DOI is also responsible for ensuring the DS record has been
> updated
> in the parent zone." - This statement is too authoritative, and conflicts
> with
> 4.2 which clarifies (correctly) that DS updates in the parent zone are
> optional. I suggest removing this statement, or correcting it to somethign
> like
> "Depending on configuration, the DOI may also be responsible...".
>
> 3.2: s/RECOMMENDED to use TLS with mutually authentication/RECOMMENDED to
> use
> TLS with mutual authentication/ - in the final sentence of the 2nd
> paragraph.
>
>
>
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Daniel Migault
Ericsson