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

Thank you very much Roman for the review. I believe the current version
addresses all your concerns. You can check the updates below:
https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/2eb84ee5febafc4ab02c5fe0de3a49ac1e03edcd

You can also find more details in the text below. When I noted "from a
previous comment" the intention is to explain why it does not appear in the
commit associated with your comments - just in case.

We also received many comments on the section that are informations
(Dynamic DNS, deployment scenarios)  if these sections do raise more
concerns that they do clarify. we can easily omit these sections or move
them to the appendix.

We believe the comments combined with those from Matt, were very helpful to
clarify the security of each channel.

Yours,
Daniel

On Wed, Oct 19, 2022 at 1:49 PM Roman Danyliw via Datatracker <
noreply@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-homenet-front-end-naming-delegation-18: 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:
> ----------------------------------------------------------------------
>
> (1) The security properties of the communication channels would benefit
> from
> refinement.  In trying to piece them together, there appear to be
> inconsistencies:
>
> ** Section 3.2.
>    The information exchanged between the HNA and the DM uses DNS
>    messages protected by DNS over TLS (DoT) [RFC7858].  In the future,
>    other specifications may consider protecting DNS messages with other
>    transport layers, among others, DNS over DTLS [RFC8094], or DNS over
>    HTTPs (DoH) [RFC8484] or DNS over QUIC [RFC9250].
>
> -- Is this guidance scoped to all of the information exchanged between the
> HNA
> and the DM?
>
> We do not provide any guidance, but what we are saying is that the
protocol is not stucked with DNS over TLS but can evolve when other
transport protocols will be available. How these protocol could be used is
out of scope. We are aware things can change but the list can be removed if
that causes an issue.

-- (Editorial, treat as COMMENT). If so, please explicitly state the use of
> DoT
> with normative language -- "DNS over TLS (DoT) MUST be used for ..."
>
> This is not an issue. I am currently clarifying with Matt if what he is
willing is XoT AXFR over TLS. I keep this comment in mind.

> -- If so, this suggests to me that all traffic is over TLS.  This text
> doesn’t
> align with the Section 4.6’s weaker guidance that “[s]ecure protocols
> (like TLS
> [RFC8446]) SHOULD be used to secure the transactions between the DM and the
> HNA” as the text in this section does not make for allowance for anything
> beyond DoT.
>

I think in Section 4.6 the following text address your concern - changing
SHOULD by MUST.
Secure protocols (like TLS {{!RFC8446}}) MUST be used to secure the
transactions between
the DM and the HNA.

> ** Section 4.6.  Thanks for discussing the flexible deployment options in
> section.  My concern is that the mandatory to implement security
> properties are
> not sufficiently specified for an interoperable solution.  The statement
> “The
> control channel between the HNA and the DM MUST be secured at both the HNA
> and
> the DM” is helpful.  How does one conform to it?  What exact security
> properties are required (MUST)?
>
> Various text hints at these properties:
> (a) Section 3.2 said that HNA and DM communication uses DoT (no normative
> language)
>
> (b) Section 3.2, “it is RECOMMENDED to use TLS with mutually authentication
> based on certificates to secure the channel between the HNA and the DM.”
>
> (c) Section 4.5, “ The provisioning process SHOULD provide a method of
> securing
> the Control Channel, so that the content of messages can be
> authenticated.”
>
> (d) Section 4.6, “Secure protocols (like TLS) SHOULD ...” be used
>
> (e) Section 4.6., “HNA SHOULD authenticate inbound connections from the DM
> …”
>
> (f)  Section 4.6., “DM SHOULD authenticate the HNA …
>
> Even assuming DoT is a MUST (which is not stated), all of these statements
> are
> SHOULD or RECOMMENDED suggesting that the HNA might not need to
> authenticate to
> the DM.
>

Yes you are correct. This is mostly due to the fact we considered all
security requirements and all different means to secure the communication.
I think the following updates of the sections address your concern.

## Securing the Control Channel {#sec-ctrl-security}

TLS {{!RFC8446}}) MUST be used to secure the transactions between the DM
and the HNA and
the DM and HNA MUST be mutually authenticated.
The DNS exchanges are performed using DNS over TLS {{!RFC7858}}.

The HNA may be provisioned by the manufacturer, or during some
user-initiated onboarding
process, for example, with a browser, signing up to a service provider,
with a resulting OAUTH2 token to be provided to the HNA. (see {{hna
-provisioning}}.
In the future, other specifications may consider protecting DNS messages
with other tran
sport layers, among others, DNS over DTLS {{?RFC8094}}, or DNS over HTTPs (
DoH) {{?RFC84
84}} or DNS over QUIC {{?RFC9250}}.

## Securing the Synchronization Channel {#sec-synch-security}

The Synchronization Channel uses standard DNS requests.

First the HNA (primary) notifies the DM (secondary) that the zone must be
updated and le
aves the DM (secondary) to proceed with the update when
possible/convenient.

More specifically, the HNA sends a NOTIFY message, which is a small packet
that is less
likely to load the secondary.

Then, the DM sends  AXFR {{!RFC1034}} or IXFR {{!RFC1995}} request. This
request consist
s in a small packet sent over TCP (Section 4.2 {{!RFC5936}}), which also
mitigates refle
ction attacks using a forged NOTIFY.

The AXFR request from the DM to the HNA MUST be secured with TLS {{!RFC8446}})
following
DNS Zone Transfer over TLS {{!RFC9103}}.

While {{!RFC9103}} MAY not consider the protection by TLS of NOTIFY and SOA
requests, th
ese MAY still be protected by TLS to provide additional privacy.

When using TLS, the HNA MAY authenticate inbound connections from the DM
using standard
mechanisms, such as a public certificate with baked-in root certificates on
the HNA, or
via DANE {{?RFC6698}}.

In addition, to guarantee the DM remains the same across multiple TLS
session, the HNA a
nd DM MAY implement {{?RFC8672}}.

The HNA SHOULD apply an ACL on inbound AXFR requests to ensure they only
arrive from the
DM Synchronization Channel.

In this case, the HNA SHOULD regularly check (via a DNS resolution) that
the address of
the DM in the filter is still valid.

>
> ** Section 12.1.
>
> The channels between HNA and DM are mutually authenticated and
>    encrypted with TLS [RFC8446] and its associated security
>    considerations apply.
>
> I would recommend this design.  Where is this stated in a normative
> fashion?
> The text in Section 4.6 and 5.1 states that mutual authentication is a
> SHOULD.
>
> I think this has been updated. Thanks for pointing out this.

> (2) Why would internal clients have to use public DNS for internal services
> given that there is an authoritative server for the Homenet Zone in the
> internal network?
>
> ** Section 1.3
>    When the resolution is performed from within the home network, the
>    Homenet DNSSEC Resolver MAY proceed similarly.
>
> 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.
>

This is not the desired behavior this is why we put MAY and then
detailed how it SHOULD do. The main issue is that the DNSSEC resolver must
be able to validate the chain of trust.  He might have the retrive that
part of the chain from the Public resolver.
I think the following text addresses your concern where we do not emphasize
the worst case and the retrieval of the DS via a DNS request to the outside
world may just be considered as a particular way to configure it.

I removed:
When the resolution is performed from within the home network, the Homenet
DNSSEC Resolv
er MAY proceed similarly.

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I support Warren's DISCUSS position and tried to be more specific on the
> rational in my DISCUSS write-up.  I also support John's DISCUSS position
> which
> highlights similar or potentially identical issues.  I have not attempted
> to
> deconflict them.
>
> ** Section 1.
>    Home network owners often have devices and services that they wish to
>    access outside their home network - i.e., from the Internet using
>    their names.  To do so, these names needs to be made publicly
>    available in the DNS.
>
> Note: this paragraph is also in the abstract
>
> This text isn’t clear on the problem setup.
> -- Per “… using their names”, names defined where?
>
> -- Is there the unstated assumption that these devices are hosted on the
> home
> network?
>
> NEW
> Home network owners may have devices or services hosted on this home
> network
> that they wish to access from the Internet (i.e., from a network outside
> of the
> home network).  To enable this access, the names and IP addresses of these
> devices and services needs to be made available in the public DNS.
>
> thanks for the proposed text. We took that text.

> ** Section 1.
>
>    This document describes how a Homenet Naming Authority (HNA) can
>    instruct a DNS Outsourcing Infrastructure (DOI) to publish a Public
>    Homenet Zone on its behalf.
>
> -- Editorially, this paragraph doesn’t bridge at all from the previous one
> describing the “home network” with “devices and services”.  What is the
> relationship between the HNA, DOI and Public Homenet Zone and that
> previously
> described network
>
> we propose the following text:
 The names and IP address of the home network are present in the Public
Homenet Zone by the Homenet Naming Authority (HNA), which in turn instructs
the DNS Outsourcing Infrastructure (DOI) to publish the zone on the behalf
of the HNA.
This document describes how an HNA can instruct a DOI to publish a Public
Homenet Zone on its behalf.
>
> ** Section 1.  The last two paragraphs describe the role of most of the
>

> sections in the document.  However, they omit Section 2.
>
>  The terminology section... yes, given the restructuring of the document
we need to rewrite this section.
 The new text is:
The remainder of the document is as follows.
Section 2 defines the terminology, Section 3 presents the general problem
of publishing names and IP addresses, Section 4 presents an alternative
solution to the current mechanism described in this document and Section 5
presents some deployment scenarios.

** Section 1.1
> (a)    While this document does not create any normative mechanism to
> select
>    the names to publish, this document anticipates that the home network
>    administrator (a human being), will be presented with a list of
>    current names and addresses.
>
> (b)   The administrator would mark which devices and services (by name),
>    are to be published.
>
> (c) The HNA would then collect the IPv6 address(es)
>    associated with that device or service, and put the name into the
>    Public Homenet Zone.
>
> Per (c), why does the HNA need to collect the IPv6 addresses if the
> selecting
> and marking processes of (a) and (b) already appear to have both the
> names+IP
> addresses?  Aren’t the “marked” names+IP addresses from (b) getting fed
> into
> the HNA?
>

correct, in the scenario we envisioned, as far as I remember, the marking
that is (a) and (bn) was maybe done via your phone not the HNA.

This should address your concern:
will be presented with a list of current names and addresses either
directly on the HNA or via another device such as a phone.

>
> ** Section 1.2
>    An alternative existing solution is to have a single zone, where a
>    host uses a RESTful HTTP service to register a single name into a
>    common public zone.
>
> Why does it have to be a “single name”?  For example, the edge
> CPE/NAT/reverse
> proxy device running the DDNS client could resolved to multiple public
> names
> using the inbound SNI as a discriminator.
>

What we mean here is that your name is under a zone shared by many. This is
a free service.

> ** Section 1.2.  the limitation sub-bullets #1 and 2 (“the CPE/HNA router
> …”)
> makes reference to an HNA router without defining what it is.  If there is
> going to be a comparison to the current practice to what’s proposed in this
> specification, the architectural elements which are being compared need to
> be
> introduced.  Baring that, at least provide a forward reference.
>

 We replaced it  with :
* When devices are individually configured with Dynamic DNS, any
centralized network man
agement entity such as the CPE router
* Similarly, the CPE router cannot control the process.

>
> ** Section 1.2.
>      the CPE/HNA router is unaware of the process, and cannot respond
>       to queries for these names and communications to these names
>       require an Internet connectivity is order to perform the DNS
>       resolution.  Such dependence does not meet the requirement for
>       internal communications to be resilient to ISP connectivity
>       disruptions [RFC7368].
>
> Can you please provide a more specific section number in RFC7368
> enumerating
> the requirement that the CPE must serve the DNS queries for the services
> behind
> it.
>
>

added section 3.7.5.

** Section 1.2.
>    *  the CPE/HNA router cannot control the process.  Any host can do
>       this regardless of whether or not the home network administrator
>       wants the name published or not.  There is therefore no possible
>       audit trail.
>
> -- Can’t the CPE and home network interdict the communication of the
> clients
> contacting and registering an DDNS provider
>

via some firewall rules, but actually the concern was mostly a management
issue. How do you stop a node to update its IP address?

>
> ** Section 1.2
>       This is not a
>       problem for a technical user to do with one or two hosts, but it
>       does not scale to multiple hosts and becomes a problem for non-
>       technical users.
>
> Why does sharing of DDNS credentials not scale for technical users beyond
> one
> or two hosts.  Is there an assumption that these are being shared by hand?
>
> yes... and credentials may be changed - think of light bulbs.

> ** Section 1.2
> "all the good names are taken"  -current services provide a small
>       set of zones shared by all hosts across all home networks.  More
>       especially, there is no notion of a domain specific home network.
>       As there are some commonalities provided by individual home
>       networks, there are often conflicts.
>
> I’m having trouble following the thesis of this bullet.
>
When you register under free-provider.com, it is unlikely that the name of
your choice has not been taken. As warren suggested there are option where
you can use a specific domain of your choice., but these are not the free
option.

>
> -- Per “current services provide …”, is it current “dynamic DNS services
> …”?
>
> yes and more specifically where a shared domain name is used.

> -- what is a “domain specific home network”?
>
> each node is taken individually, you cannot have at least as a primary
option myhoiment_domain.the_free_dynamic_domain.com

> -- what are the “commonalities provided by individual home networks …”?
>
> everyone has a nas, a tv... some mytv, mynas my laptop are hostname likely
to be common.

** Section 1.2.
>
> The RESTful services do not always support all RR types.
>
> Is there a sense for what kinds of devices or services for which this is an
> impediment?  Put in another way, many Dynamic DNS doesn’t support this
> now, so
> what are the things running on the home network now that would benefit?
>

RRSIG, CNAME, at least any RRSet whose purpose is to manage the zone.

>
> ** Section 1.3.  Editorial. Given the sequencing of the text, the
> deployment
> scenarios are not illustrative and largely opaque.  They rely on knowledge
> and
> terminology of the proposed solution not yet explained in the document.
> There
> are no forward references to orient the reader.
>
>  This is correct - the intention was to clear out some questions.

** Section 1.3.1
>
> Instead these
>    keys are solely used by the HNA to proceed to the authentication.
>    Normally the keys should be necessary and sufficient to proceed to
>    the authentication. The reason to combine the domain name and the
>    key is that DOI are likely handle names better than keys and that
>    domain names might be used as a login which enables the key to be
>    regenerated.
>
> -- What does “proceed to authentication” mean?  Is there some kind of MFA
> happening? -- The text says “The reason to combine the domain name and key
> …”,
> but the text prior didn’t explain that this was happening.
>
> From a previous comment we have changed the text to:
 Instead these keys are solely used by the HNA for the authentication to
the DM.

** Section 1.3.1.  Editorial.
>
> OLD
> An CPE that is not preconfigured may also take advantage to the
>    protocol
>
> NEW
> An CPE that is not preconfigured may also take advantage of the
>    protocol
>
> the text from a previous comment has been change dto:
A CPE that is not preconfigured may also use the protocol

defined in this document but some configuration steps will be needed.

> ** Section 1.3.1.  Editorial.
>
> OLD
> The owner of the home network buys a domain name to a registrar
>
> NEW
> The owner of the home network buys a domain name from a registrar
>
> this as been changed also from a previous comment

** Section 3.  Typo. s/detaille din/detailed in/
>
> changed from previous comment

> ** Section 3.  Editorial.  Make clear this is a statement about the
> example.
>
> OLD
> The Public Homenet Zone is identified by the Registered Homenet
>    Domain Name - myhome.example.
>
> NEW
> In this example, the Public Homenet Zone is identified by the Registered
> Homenet Domain Name - myhome.example.
>
> changed

> ** Section 3
>
> the HNA communicates and
>    synchronizes it with the DOI using a primary/secondary setting as
>    described in Figure 1.
>
> I understand the intent of the text and who is operating as the primary and
> secondary from it.  However, I don’t see how Figure 1 reflects the primary
> and
> secondary configuration.
>
> we added primary and secondary

> ** Section 3.  Editorial.  The term “hidden primary” is not in used in
> RFC8499.
>  I believe the term there is “hidden master” which we stopped using for
> inclusive language reasons.  Cite Section 6 or provide bridging text
> between
> the old and new term.
>
> we  changed to hidden master (now designated as hidden primary)
{{?RFC8499}}

** Section 3.  Typo.  Missing close parentheses.  s/ one or more
> Distribution
> Channels (Section 6 that/one or more Distribution Channels (Section 6)
> that/
>
> addressed form previous comment

> ** Section 3.2.
> The visible NS records
> SHOULD remain pointing at the cloud provider's server IP address.
>
> Who is the cloud provider in Figure 1?  Is cloud provide the DOI?  If so,
> please use consistent terminology in the normative language.
>
> changed to  DOI's Public Authoritative Servers' IP address

** Section 4.5. s/any any/
>
> changed

> ** Section 10.  Typo. s/The remaining of the/The remainder of this/
>
> change din a previous commnent

> ** Section 11.
>
> The Public Homenet Zone lists the names of services hosted in the
>    home network.  Combined with blocking of AXFR queries, the use of
>    NSEC3 [RFC5155] ...
>
> Thanks for calling out that NSEC3 provides some mitigation for zone
> enumeration.  Since it’s use is not mandatory (only RECOMMENDED), please
> explicitly state the consequence of it NOT being used (i.e., an enumerated
> list
> of services on your internal network).
>
> I have the impression the current text already address your concern in the Privacy
Considerations. Let me know if anything needs to be added.
Combined with blocking of AXFR queries, the use of NSEC3 {{!RFC5155}} (vs
NSEC {{!RFC4034}}) prevents an  attacker from being able to walk the zone,
to discover all the names.

Section 12.2.  The analysis in this section seems to be focused on IPv6
> addresses. Section 1.1. seems to allow for IPv4.  Please reflect that.
>
> This is correct, initially homenet was only IPv6 and the described
mechanism was extended to IPv4.
we added:
IPv4 Addresses are 4 bytes long leading to 2**32 possibilities.
With IPv6 addresses, the Interface....

> ** Missing Operational Considerations.
>
> HomeNet technologies makes it easier to expose devices and services to the
> Internet.  This imposes broader operational considerations for the
> operator and
> the Internet:
>
> -- The home network operator must carefully assess whether a device or
> service
> previously fielded only on a home network is robust enough to be exposed
> to the
> Internet
>
> -- The home network operator will need to increase the diligence to
> regularly
> managing these exposed devices due to their increased risk posture of being
> exposed to the Internet
>
> -- Depending on the operational practices of the home network operators,
> there
> is an increased risk to the Internet architecture through the possible
> introduction of additional internet-exposed system that are poorly managed
> and
> likely to be compromised.  Carriers may not to deployed additional
> mitigations
> to ensure that attacks do not originate from their networks.
>
>
> Thank you very much, I added an Operational considerations section.

>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Daniel Migault
Ericsson