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

Thanks John for the careful review. I believe that all your concerns have
been addressed. You can see the changes here:
https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/b1fda0d6b3a0fc5f259bc6a4867b3ed5411baa8d

as well as in line.

We did appreciate the time you took to propose some alternative or some
expected text. That was very helpful.

Yours,
Daniel

On Wed, Oct 19, 2022 at 12:06 PM John Scudder via Datatracker <
noreply@ietf.org> wrote:

> John Scudder 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:
> ----------------------------------------------------------------------
>
> This isn't my only concern with this document but Warren Kumari has broadly
> covered the space with his own DISCUSS.  I did want to highlight this one,
> though.  I think it should be relatively easy to fix.
>
> Section 4.6, "Securing the Control Channel", almost-mandates security:
>
> ```
>    The control channel between the HNA and the DM MUST be secured at
>    both the HNA and the DM.
> ```
>
> It does not, however, specify any mandatory-to-implement security
> mechanism,
> although it provides an interesting and wide-ranging discussion of many
> options.  It's very difficult for me to see how interoperable
> implementations
> can be built, that comply with the quoted requirement, by someone working
> from
> the current specification. It does seem from other hints in the document
> that
> the authors consider TLS mandatory even though it's not stated as such in
> Section 4.6. For example, Security Considerations subsection 12.1 says,
>
> ```
>    The channels between HNA and DM are mutually authenticated and
>    encrypted with TLS [RFC8446] and its associated security
>    considerations apply.
> ```
>
> Another hint that TLS is viewed as mandatory-to-implement is from a
> different
> document also currently under review,
> draft-ietf-homenet-naming-architecture-dhc-options-21 (Sections 4.2 and
> 4.3):
>
> ```
>       The bit for DNS over TLS [RFC7858] MUST be set.
> ```
>
> I talk about this more in my comment on Section 4.6, but there's just no
> way to
> read this paragraph as mandating TLS:
>
> ```
>    Secure protocols (like TLS [RFC8446]) SHOULD be used to secure the
>    transactions between the DM and the HNA.
> ```
>
> It doesn't even quite mandate secure transport in general, since it's a
> SHOULD
> (so presumably there are times when an implementor can sensibly ignore it,
> though these are not discussed). What's more, TLS is only given as an
> example
> of one transport that would be OK, not as the mandatory-to-implement secure
> transport. As written, any secure transport, for example TCP-AO, would
> satisfy
> this SHOULD.
>
> Based on the hints throughout the rest of the document set, that the
> authors
> think of TLS as the mandatory-to-implement base transport, I think this
> section
> should be rewritten to match that expectation.
>
>
> Yes. The sections for the security of the channel have been rewritten. I
think they should 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 transport layers, among others, DNS over DTLS {{?RFC8094}}, or
DNS over HTTPs (DoH) {{?RFC8484}} 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 leaves 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 consists in a small packet sent over TCP (Section 4.2
{{!RFC5936}}), which also mitigates reflection 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, these 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 and 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.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # RTG AD John Scudder's comments for
> draft-ietf-homenet-front-end-naming-delegation-18
>
> CC @jgscudder
>
> Thanks for the work on this document, it clearly reflects a lot of effort.
> I
> hope these comments help you get it over the finish line.
>
> Although I'm not enough of a DNS expert to evaluate the details of what the
> document specifies, the number of inconsistencies and minor errors I've
> flagged
> in my review makes me concerned that there may be problems with
> implementability.  For this reason I support Warren Kumari's DISCUSS.
>
> In my comments below I've flagged a few grammar nits, but for the most part
> I've tried to restrict myself to cases where it seemed like there was a
> risk of
> misunderstanding if not corrected.  Even when/if these are fixed I think
> the
> document would benefit from a full go-over either manually or using an
> automated grammar checker, before sending it to the RFC Editor.  (Yes the
> RFC
> Editor will do their best to fix all of these.  But it's better for the
> authors
> to do it to the best of their ability, including because occasionally,
> despite
> their best efforts, the RFC Editor introduces a "fix" that results in an
> unwanted normative change.)
>
> ## COMMENTS
>
> ### Global - "associated to"
>
> There are at least 13 occurrences of the phrase "associated to".  Can
> these all
> be replaced by the more idiomatically correct "associated with"?  I
> hesitate,
> because "associated to" in computing can have a technically-distinct
> meaning,
> however if that's the case in any of these I think such uses of
> "associated to"
> may need clarification.
>
> So, to be clear: I suggest either replacing these by "associated with", or
> if
> that's inappropriate, clarifying the meaning.
>
> fixed

> ### Global - SHOULD vs. MUST
>
> A quick grep shows 32 instances of SHOULD or SHOULD NOT in the document
> (not
> counting the two in the boilerplate). I haven't audited each one, but for
> many
> of these it's difficult to see why they're SHOULD and not MUST. My own
> heuristic is to think of SHOULD as a "must/unless" pair -- it's desirable
> to
> provide some guidance to the implementator as to what circumstances would
> justify ignoring the SHOULD. If you can't actually think of good reasons
> to do
> that, consider changing the SHOULD to a MUST. Or if you're using SHOULD in
> the
> sense of "we think you ought to implement it this way but we are trying to
> be
> considerate and not yell MUST at you all the time" it's also reasonable to
> use
> lower-case words instead of RFC 2119 keywords.
>
> I won't comment separately on each individual SHOULD in the document but I
> encourage you to review them.
>
> we have now 24 SHOULD (NOT) which represents a significant drop 30%. I
will review more carefully each SHOULD, but I think the main complexity
came from the previous transport security you raised in your discuss.

### Section 1
>
> "KSK (DS RRset)"
>
> Please provide a reference or other hints for those readers who don't speak
> DNSSEC as a first language (like me). "KSK" could probably use to be
> expanded
> on first use, too.
>
>  expanded

### Section 1.1
>
> ```
>    However, since communications
>    are established with names which remains a global identifier
> ```
>
> I don't understand what that clause means.
>
Communications are established with names means that we usually sai we are
connected to www.example.com as opposed to the IP addressed. Names are
global identifiers.

I think the sentence has been clarified since then and the current one is:
  Since communications are established with names which remain a global
identifier, the communication can be protected by TLS the same way it is
protected on the global Internet - using certificates.

>
> ### Section 1.2
>
> ```
>    even adapted to IPv6 and ignoring those associated to an IPv4
>    development
> ```
>
> I don't understand what this clause means. Is there a word missing between
> "those" and "associated", and perhaps "to" should be "with"?
>
> The current sentence is:
Dynamic DNS - even adapted to IPv6 and ignoring those associated with an
IPv4 developmen
t - does suffer from some severe limitations:

> ### Section 1.3.2
>
> Please expand "CSR" on first use (and provide a reference if appropriate).
>
>  It seems this has been removed.

### Section 3.1 - "as described"
>
> ```
>    as
>    described in Figure 1
> ```
>
> Perhaps "as depicted in Figure 1"? I don't think Figure 1 can be said to
> be a
> (full) description of anything.
>
> It seems you are saying some lements are missing which one do you think
are missing. The figure has been updated since the version you reviewed.

> ### Section 3.1 - "answer to"
>
> "it is not expected to answer to DNS requests" --> "it is not expected to
> answer DNS requests" (changed "answer to" to just "answer", there is a
> slightly
> different shade of meaning)
>
> changed

> ### Section 3.2
>
> ```
>    The visible NS records
>    SHOULD remain pointing at the cloud provider's server IP address"
> ```
>
> This is the sole mention of a "cloud provider" in the document. Re-word?
>
>  change dto :
typically,  the visible NS records of the Public Homenet Zone (built by the
HNA) SHOULD remain pointing at the DOI's Public Authoritative Servers' IP
address -- which in many cases will be an anycast address.

> ### Section 4
>
> ```
>    the IP address and port number to use and protocol to
>    set secure session
> ```
>
> I don't understand what that clause means (in particular "protocol to set
> secure session").
>
> changed to:
As such the HNA has a prior knowledge of the DM identity (X509
certificate), the IP addr
ess and port number to use and protocol to establish a secure session.

> ### Section 4.2
>
> For this text,
>
> ```
>    By accepting the DS RR, the DM commits in taking care of advertising
>    the DS to the parent zone.  Upon refusal, the DM clearly indicates it
>    does not have the capacity to proceed to the update.
> ```
>
> Would the below rewrite be correct? If not, please propose another.
>
> ```
>    By accepting the DS RR, the DM commits to advertise
>    the DS to the parent zone.  On the other hand if the DM
>    does not have the capacity to advertise the DS to the
>    parent zone, it indicates this by refusing the DS RR.
> ```
>
> works for me.

> ### Section 4.3
>
> I don't understand what this paragraph is telling me about the provision
> of the
> IP address by the HNA:
>
> ```
>    The HNA works as a primary authoritative DNS server, while the DM
>    works like a secondary.  As a result, the HNA must provide the IP
>    address the DM is using to reach the HNA.  The synchronization
>    Channel will be set between that IP address and the IP address of the
>    DM.  By default, the IP address used by the HNA in the Control
>    Channel is considered by the DM and the specification of the IP by
>    the HNA is only OPTIONAL.  The transport channel (including port
>    number) is the same as the one used between the HNA and the DM for
>    the Control Channel.
> ```
>
> You start out by saying the "the HNA must provide the IP address the DM is
> using to reach the HNA". (By the way when you say "is using" I think you
> mean
> "should use". No?) I note the use of "must".
>

>
> But then you go on to say that "the specification of the IP by the HNA is
> only
> OPTIONAL". (I assume that "the IP" here means "the IP address" that was
> discussed a few sentences back, probably you should add the word "address"
> if
> so.)
>
> These two sentences, the "must" in the first one and the "OPTIONAL" in the
> later, seem directly in opposition to one another. :-(
>
> To set the synchronization channel the secondary needs to know the IP
address of the secondary. (must).
Either the IP is derived as the IP addressed used in the control channel or
the IP address is explicitly provided. The latest option is optional.
I  hope the addition of explicit addresses your concerns:

By default, the IP address used by the HNA in the Control Channel is
considered by the DM and the explicit specification  of the IP by the HNA
is only OPTIONAL.

### Section 4.5.2
>
> ```
>    The DM SHOULD ignore non-empty the Pre-requisite and
>    Additional Data section"
> ```
>
> I don't know what this means. If "non-empty" weren't there, I would get
> it, it
> would just mean "ignore the pre-req and additional data sections no matter
> what
> their content is" -- so maybe the easiest fix is to delete "non-empty" (and
> changing "section" to "sections" while you're at it), as in
>
> changed

> ```
>    The DM MUST ignore the Pre-requisite and Additional Data
>    sections, if present.
> ```
>
> ### Section 4.5.2
>
> These two paragraphs seem a little inconsistent:
>
> ```
>    An error indicates the MD does not
>    update the DS, and other method should be used by the HNA.
>
>    The regular DNS error message SHOULD be returned to the HNA when an
>    error occurs.  In particular a FORMERR is returned when a format
>    error is found, this includes when unexpected RRSets are added or
>    when RRsets are missing.  A SERVFAIL error is returned when a
>    internal error is encountered.  A NOTZONE error is returned when
>    update and Zone sections are not coherent, a NOTAUTH error is
>    returned when the DM is not authoritative for the Zone section.  A
>    REFUSED error is returned when the DM refuses to proceed to the
>    configuration and the requested action.
> ```
>
> I would have guessed that the implication of some of the errors cited in
> the
> second paragraph is that the HNA should correct the problem and then
> retry.
> But the first paragraph seems to indicate that an HNA shouldn't bother even
> considering the error code, because "and other method should be used by the
> HNA".
>
> I'm not sure how, or if, to resolve this seeming inconsistency.
>
> ok I see.
th efirst paragraph is changed to:
An error indicates the MD does not update the DS, and the HNA needs to act
accordingly or other method should be used by the HNA.

### Section 4.5.3
>
> ```
>    Similarly to Section 4.5.2, DNS errors are used and an error
>    indicates the DM is not configured as a secondary.
> ```
>
> Related to the previous comment -- is this true regardless of what error
> code
> is returned, for example would a FORMERR mean that the DM is not
> configured as
> a secondary?
>
> Even given that any error implies that the operation failed, what if the
> DM had
> already been previously configured as secondary, and the operation were
> merely
> updating some parameter? Would the previous configuration be voided, as the
> text currently implies? Or would the DM remain configured as secondary,
> using
> the previous configuration?
>
> We used DNS errors to imply that the standard DNS behavior is expected.
When teh update fails, the data remains in its previous step.

> ### Section 4.6
>
> These two paragraphs seem inconsistent:
>
> ```
>    The control channel between the HNA and the DM MUST be secured at
>    both the HNA and the DM.
>
>    Secure protocols (like TLS [RFC8446]) SHOULD be used to secure the
>    transactions between the DM and the HNA.
> ```
>
> MUST the channel be secured?  Or is it only SHOULD?  Also, does the second
> paragraph really mean "secure *transport* protocols", or is the ambiguity
> intentional?  By ambiguity, I suppose the paragraph as written might be
> satisfied by object-level security, for instance, and for that matter it
> leaves
> it up to the reader to even define exactly what they mean by "security".
> Finally, see also my DISCUSS comments -- if you actually want to mandate
> TLS
> (as implied by some of the other parts of this document, and
> draft-ietf-homenet-naming-architecture-dhc-options-21), you need to make
> some
> changes to this section.
>
> these sections have been completely re-written.

> ### Section 4.6
>
> Please expand SAN on first use.
>
I think the text has been removed.

>
> ### Section 7
>
> ```
>    Depending how the communications between the HNA and the DM are
>    secured, only packets associated to that protocol SHOULD be allowed.
> ```
>
> This is too vague. What specifically about the means of securing the
> communications would lead the implementor to follow, or disregard, the
> SHOULD?

Only TLS packet or potentially some DNS packets (see XoT) packets SHOULD be
allowed.

This concerns firewall rules so not necessarily mandatory.

>
> ### Section 10
>
> ```
>    Then,
>    the HNA advertises the DM via a NOTIFY, that the Public Homenet Zone
>    has been updated
> ```
>
> Probably you mean "advertises to" or maybe better, "advises", where you've
> written "advertises"? If not, then I don't understand what's happening in
> this
> part.
>
> ok changed to advertises to.

> ### Section 12.2
>
> Consider using "their" instead of "his".
>
> changed

> ### Section 14
>
> Was "its" chosen as the pronoun for two persons being thanked, based on
> those
> persons' preferences? If not then consider whether you've used the right
> pronoun in those two places, in my experience it's fairly rare -- but not
> unheard-of! -- for a person to prefer to be referred to as "it" rather
> than the
> more common "he", "she", or "they".
>
> changed.

> ### Appendix A.1
>
> I'm a little confused -- the first couple of paragraphs led me to believe
> that
> this section was just going to tell me what parameters are required, but
> wasn't
> going to mandate the means of providing them. But then we come to,
>
> ```
>    The above parameters MUST be be provisioned for ISP-specific reverse
>    zones, as per [I-D.ietf-homenet-naming-architecture-dhc-options].
> ```
>
> The "MUST" combined with the "as per" implies you're mandating that DHCPv6
> be
> used to provision the parameters. If you really do intend to make
> dhc-options
> mandatory, it needs to be a normative reference. On the other hand if, as I
> think is likely, you only intended to use dhc-options as an example,
> perhaps
> something like this rewrite?
>
> ```
>    The above parameters MUST be be provisioned for ISP-specific reverse
>    zones. One example of how to do this can be found in
>    [I-D.ietf-homenet-naming-architecture-dhc-options].
> ```
>
> changed thanks.

> ### Appendix B - "registered_domain" or "zone"?
>
> This threw me off -- in the CDDL you show "registered_domain" but in the
> explanatory text you describe (what I think is) this field as "Registered
> Homenet Domain (zone)". Should the latter be "Registered Homenet Domain
> (registered_domain)" instead? (Or, rename "registered_domain" in the CDDL
> as
> "zone"?)

 changed thanks.

>
> ### Appendix B - 2119 keywords
>
> It's weird that you lead with "This section is non-normative" but then
> pepper
> the content with the RFC 2119 keyword "OPTIONAL". I think probably you
> don't
> mean it's "non-normative" (that generally means something like "this is an
> example, it doesn't define anything, it can safely be ignored"). Rather, I
> think you mean implementing it is optional. I think you could fix this by
> deleting the words "is non-normative and".
>
> changed.

> Also, "MANDATORY" isn't an RFC 2119 keyword but you've capitalized it like
> one.
> If you want to introduce your own keyword to put the the force of VERY
> SERIOUS
> NORMATIVE CAPITALIZATION behind this word, I think it would be a good idea
> to
> define it in your Terminology section, probably right after the RFC 2119
> boilerplate paragraph. Alternately, you could just change all your uses of
> "mandatory" and "optional" in this section to lower-case. It would still be
> clear, IMO.
>
> done

> ## NITS
>
> - "these names needs" --> "these names need"
> - "The remaining of the document" --> "the rest of the document"
> - "buys a domain name to a registrar" --> "buys a domain name from a
> registrar"
> - "DOI has a roof of ownership" --> "roof" should be... "proof"?
> - "as detaille din further details below" --> "as detailed below"
> - "rsynch" --> "rsync"
> - "meth of" --> "method"
>
> changed.

> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
>
>
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Daniel Migault
Ericsson