[homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-20: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-homenet-front-end-naming-delegation-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(updated ballot for the -20 text)

(1) (per -18 and -20) The security properties of the communication channels
would benefit from refinement.

Thanks for the effort to harmonize the text around TLS usage noted in my ballot
on -18 per
https://mailarchive.ietf.org/arch/msg/homenet/Qc2sOcBD4P7j3LXYKP61pra7w_E/.

The much clear text in Section 5.2:

   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.
   ...
   The information exchanged between the HNA and the DM uses DNS
   messages protected by DNS over TLS (DoT) [RFC7858].

Still appears to conflict with the text:

-- Section 5.2
   While Section 6.6 discusses in more depth
   the different security protocols that could be used to secure, it is
   RECOMMENDED to use TLS with mutual authentication based on
   certificates to secure the channel between the HNA and the DM.

-- Section 14.1
   At the time of writing TLS 1.2 or TLS 1.3 can be used and TLS 1.3 (or
   newer) SHOULD be supported.  It is RECOMMENDED that all DNS exchanges
   between the HNA and the DM be protected by TLS to provide integrity
   protection as well as confidentiality.

Per the TLS guidance in Section 14.1, should this document define it’s own
guidance, follow what comes with DoT/RFC7858 (which points to RFC7525), or
point to draft-ietf-uta-rfc7525bis?  What is written here is slightly different
than RFC7858 so I recommend draft-ietf-uta-rfc7525bis or something stronger.

(2) Section 6.5

   The provisioning process SHOULD provide a method of securing the
   Control Channel, so that the content of messages can be
   authenticated.

Per the changes made in (1), and the strict requirement to mutually
authenticate with TLS, why isn’t this a MUST?

** Section 1.3

[per -18]
   When the resolution is performed from within the home network, the
   Homenet DNSSEC Resolver MAY proceed similarly.

[per -18] I’m not sure if this my misreading of the behavior of internal
clients.  To clarify, the (internal) Homenet DNSSEC Resolver will “... resolves
the DS record on the Global DNS and the name associated to the Public Homenet
Zone (myhome.example) on the Public Authoritative Servers.”?  Why would the
internal resolver serving a request for an internal client for an internal
service go to the Global DNS if the information if it could come from the
internal Homenet Zone it is already configured with?  As an operational
consideration, why go outside of the network if you don’t need to?  As a
privacy consideration, why leak the request to an outside entity if the network
already has the information.

[per -20] Thanks for the revised text:
   On the other hand, to provide resilience to the Public Homenet Zone
   in case of WAN connectivity disruption, the Homenet DNSSEC Resolver
   SHOULD be able to perform the resolution on the Homenet Authoritative
   Servers.

-- Please also point out that the use of the Homenet resolver would enhance
privacy since the user on the home network would no longer be leaking
interactions with internal services to an external DNS provider and to an
on-path observer.

-- Is there a reason this can’t be a MUST?

-- Editorial (comment level, but adding here for convenience) Consider if you
want to use the “DNSSEC Resolver” or “DNS(SEC) Resolver” (as was introduced
later) since DNSSEC is not mandatory.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Warren, John and Paul’s DISCUSS positions.

Thank you for addressing my COMMENTs.