[OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08

["Rob Wilton (rwilton)" <[e-mail]>]

Hi,

Here is my AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08.

I found quite a few cases where the grammar is incorrect, which I find somewhat distracting and makes the document harder to review for technical content/correctness.  I've flagged as many of these that I can in my review (and some other questions).  I've also run the text through a grammar checker which may highlight potential additional changes, but can also have some false positives (MCR, please can you check these).  Please can you post an updated version and then I may give it a second read before starting IETF LC.

Minor level comments:

(1) p 2, sec 1.  Introduction

     In TLS 1.3 with or without
   the use of ECH, middlebox cannot rely on SNI inspection because a
   malware could lie about the SNI and middlebox without acting as a TLS
   proxy does not have visibility into the server certificate.

I find it very hard to read/understand this sentence.

Did you mean something like:

   In TLS 1.3, with or without the use of ECH, middleboxes cannot rely on
   SNI inspection because malware could lie about the SNI.  In addition,
   middleboxes do not have visibility into the server certificate unless
   they are acting as TLS proxies.


(2) p 3, sec 1.  Introduction

   The fourth section of this document makes a series of recommendations
   ("best current practices") for manufacturers on how to use DNS, and
   IP addresses with specific purpose IoT devices.

DNS, and => DNS and


(3) p 5, sec 3.1.4.  Names can have wildcards

   github would be unable to provision all infinity of possible names
   into the PTR records.

This sentence is somewhat unclear.


(4) p 8, sec 4.1.  Use of IP address literals in-protocol

   And with any non-determistic name or address that is returned, the
   MUD controller is not challenged to validate the transaction, as it
   can not see into the communication.

I'm not sure that I understand what this paragraph is trying to convey.


(5) p 9, sec 4.2.  Use of non-deterministic DNS names in-protocol

   This in particular may apply to the location where firmware updates
   may be retrieved.

Would it be worth more explicitly stating what the proposed alternative is here.  I.e., to use stable URLs at well known stable domains?


(6) p 9, sec 4.3.  Use of a too inclusive DNS name

Rather than "too inclusive" perhaps consider "too generic"?


(7) p 11, sec 6.5.  Prefer DNS servers learnt from DHCP/Route Advertisements

   IoT Devices should prefer doing DNS to the network provided DNS
   servers.  Whether this is restricted to Classic DNS (Do53) or also
   includes using DoT/DoH is a local decision, but a locally provided
   DoT server SHOULD be used, as recommended by
   [I-D.reddy-add-iot-byod-bootstrap].

Should it be DoT/DoH server SHOULD be used, or do you mean to specifically recommend DoT over DoH here?


(8) p 11, sec 7.  Privacy Considerations

   The use of DoT and DoH eliminates the minimizes threat from passive
   eavesdropped, but still exposes the list to the operator of the DoT
   or DoH server.  There are additional methods, such as described by
   [I-D.pauly-dprive-oblivious-doh].

This reference can be updated to RFC 9230.


(9) p 11, sec 7.  Privacy Considerations

   The use of DoT and DoH eliminates the minimizes threat from passive
   eavesdropped, but still exposes the list to the operator of the DoT
   or DoH server.  There are additional methods, such as described by
   [I-D.pauly-dprive-oblivious-doh].

"... eliminates the threat from passive eavesdroppers, ..."


(10) p 12, sec 7.  Privacy Considerations

   The use of DoT and DoH eliminates the minimizes threat from passive
   eavesdropped, but still exposes the list to the operator of the DoT
   or DoH server.  There are additional methods, such as described by
   [I-D.pauly-dprive-oblivious-doh].
   The use of unencrypted (Do53) requests to a local DNS server exposes
   the list to any internal passive eavesdroppers, and for some
   situations that may be significant, particularly if unencrypted WiFi
   is used.  Use of Encrypted DNS connection to a local DNS recursive
   resolver is a preferred choice, assuming that the trust anchor for
   the local DNS server can be obtained, such as via
   [I-D.reddy-add-iot-byod-bootstrap].

Presumably there should also be a recommendation to use encrypted WiFi too.


(11) p 12, sec 7.  Privacy Considerations

   While possession of a Large (Kitchen) Appliance at a residence may be
   uninteresting to most, possession of intimate personal devices (e.g.,
   "sex toys") may be a cause for embarrassment.

Not sure whether the example is needed here, but don't object if you want to keep it.  I would change "Large (Kitchen) Appliance" to just "kitchen appliance".


(12) p 13, sec 8.  Security Considerations

   This document takes the view that the two requirements do not need to
   be in conflict, but resolving the conflict requires some advance
   planning by all parties.

Rather than "requires some advance planning by all parties", perhaps "requires careful planning on how the DNS can be safely and effectively used by MUD controllers and IOT devices."



Nit level comments:

(13) p 3, sec 1.  Introduction

   The second section of this document details how common manufacturer
   anti-patterns get in the way this mapping.
   The third section of this document details how current trends in DNS
   presolution such as public DNS servers, DNS over TLS (DoT), DNS over
   QUIC (DoQ), and DNS over HTTPS (DoH) cause problems for the
   strategies employed.  Poor interactions with content-distribution
   networks is a frequent pathology that can result.

presolution => resolution


(14) p 4, sec 3.1.1.  Too slow

   While subsequent connections to the same site (and subsequent packets
   in the same flow) will not be affected if the results are cached, the
   effects will be felt.  The ACL results can be cached for a period of
   time given by the TTL of the DNS results, but the lookup must be
   performed again in a number of hours to days.

hours to days => hours or days.


(15) p 6, sec 3.2.  A successful strategy

   In order to compensate for this, the MUD controller SHOULD regularly
   do DNS lookups in order to get never have stale data.

regularly do => regularly perform
to get never have => to never have


(16) p 6, sec 3.2.  A successful strategy

     These lookups
   need to be rate limited in order to avoid load.  It may be necessary
   to avoid local recursive DNS servers.

Suggest "These lookups must be rate limited to avoid excessive load on the DNS servers, and it may be necessary to avoid local recursive resolvers."


(17) p 6, sec 3.2.  A successful strategy

   A MUD controller that is aware of which recursive DNS server that the
   IoT device will use can instead query that server on a periodic
   basis.  Doing so provides three advantages:

server that the => server the


(18) p 7, sec 3.2.  A successful strategy

   The solution of using the same caching recursive resolver as the
   target device is very simple when the MUD controllers is located in a
   residential CPE device.  The device is usually also the policy
   enforcement point for the ACLs, and a caching resolver is typically
   located on the same device.  In addition the convenience, there is a
   shared fate advantage: as all three components are running on the
   same device, if the device is rebooted, clearing the cache, then all
   three components will get restarted when the device is restarted.

the convenience => to convenience


(19) p 7, sec 3.2.  A successful strategy

   Where the solution is more complex is when the MUD controller is
   located elsewhere in an Enteprise, or remotely in a cloud such as
   when a Software Defines Network (SDN) is used to manage the ACLs.
   The DNS servers for a particular device may not be known to the MUD
   controller, nor the MUD controller be even permitted to make recusive
   queries that server if it is known.  In this case, additional
   installation specific mechanisms are probably needed to get the right
   view of DNS.

The scenario where the solution is more complex is when ...
that server => to that server
of DNS => of the DNS


(20) p 7, sec 4.  DNS and IP Anti-Patterns for IoT device Manufacturers

   This section describes a number of things with IoT manufacturers have
   been observed to do in the field, each of which presents difficulties
   for MUD enforcement points.

with IoT => which IoT


(21) p 8, sec 4.1.  Use of IP address literals in-protocol

   An authoritative server might be tempted to provided an IP address
   literal inside the protocol: there are two arguments (anti-patterns)
   for doing this.
   One is that it eliminates problems to firmware updates that might be
   caused by lack of DNS, or incompatibilities with DNS.  For instance
   the bug that causes interoperability issues with some recursive
   servers would become unpatchable for devices that were forced to use
   that recursive resolver type.

Suggest "One is that" -> "The first is that ..."
"the bug that" -> "a bug that"


(22) p 8, sec 4.1.  Use of IP address literals in-protocol

   A second reason to avoid a DNS in the URL is when an inhouse content-
   distribution system is involved that involves on-demand instances
   being added (or removed) from a cloud computing architecture.

Suggest "A second" -> "The second"


(23) p 8, sec 4.1.  Use of IP address literals in-protocol

   But, there are many problems with use of IP address literals for the
   location of the firmware.

Perhaps change "many problems" => "more problems".


(24) p 8, sec 4.1.  Use of IP address literals in-protocol

   Third-party content-distribution networks (CDN) tend to use DNS names
   in order to isolate the content-owner from changes to the
   distribution network.

I suggest "Finally, Third-party content-distribution ..."


(25) p 9, sec 5.  DNS privacy and outsourcing versus MUD controllers

   A described above in Section 3 the MUD controller needs to have
   access to the same resolver(s) as the IoT device.

A described ... => As described ...


(26) p 10, sec 6.  Recommendations to IoT device manufacturer on MUD and DNS usage

   The difficult part is determining what to put into the MUD file
   itself.  There are currently tools that help with the definition and
   analysis of MUD files, see [mudmaker].  The remaining difficulty is
   now the semantic contents of what is in the MUD file.  An IoT
   manufacturer must now spend some time reviewing what the network
   communications that their device does.

what the network ... => "reviewing the network communications by their device."


(27) p 10, sec 6.  Recommendations to IoT device manufacturer on MUD and DNS usage

   This document has discussed a number of challenges that occur
   relating to how DNS requests are made and resolved, and it is the
   goal of this section to make recommendations on how to modify IoT
   systems to work well with MUD.

has discussed => discusses
it is the goal => and the goal
section to make => section is to make


(28) p 10, sec 6.2.  Use primary DNS names controlled by the manufacturer

   While it used to be costly to have a large number of aliases in a web
   server certificate, this is no longer the case.  Wildcard
   certificates are also commonly available which allowed for an
   infinite number of possible names.

allowed for => allow for


(29) p 10, sec 6.3.  Use Content-Distribution Network with stable names

   When aliases point to a Content-Distribution Network (CDN), prefer to
   use stable names that point to appropriately load balanced targets.
   CDNs that employ very low time-to-live (TTL) values for DNS make it
   harder for the MUD controller to get the same answer as the IoT
   Device.  A CDN that always returns the same set of A and AAAA
   records, but permutes them to provide the best one first provides a
   more reliable answer.

prefer to use stable => prefer stable


(30) p 11, sec 6.4.  Do not use geofenced names

   Due the problems with different answers from different DNS servers,
   described above, a strong recommendation is to avoid using such
   things.

Due to the problems ...
.... is to avoid using geofenced names.


(31) p 11, sec 6.5.  Prefer DNS servers learnt from DHCP/Route Advertisements

   It is recommended that use of non-local resolvers is only done when
   the locally provided resolvers provide no answers to any queries at
   all, and do so repeatedly.  The use of the operator provided
   resolvers SHOULD be retried on a periodic basis, and once they
   answer, there should be no further attempts to contact public
   resolvers.

Perhaps change last should to SHOULD?


(32) p 12, sec 7.  Privacy Considerations

   Identifying the IoT device type empowers the attacker to launch
   targeted attacks to the IoT device (e.g., Attacker can advantage of
   the device vulnerability).

can take advantage of any known vulnerabilities on the device.


(33) p 12, sec 7.  Privacy Considerations

   The more complex case of section Section 4.1 postulates that the
   version number needs to be provided to an intelligent agent that can
   decided the correct route to do upgrades.  The current [RFC9019]
   specification provides a wide variety of ways to accomplish the same
   thing without having to divulge the current version number.

section Section 4.1 => Section 4.1
The current [RFC9019] specification provides => "RFC 9019 provides" (Or you can say current, at the time of publication, ...)


(34) p 13, sec 8.  Security Considerations

   This document deals with conflicting Security requirements:

Security => security


Spellings to check:
Enteprise,
consistitute,
consititute,
funnelled,
inhouse,
inprotocol,,
liimt,
middlebox,
permutted,
presolution,
recusive,

Grammar Warnings:
Section: 1, draft text:
Use of a DNS name rather than IP address in the ACL has many advantages: not only does the layer of indirection permit the mapping of name to IP address to be changed over time, it also generalizes automatically to IPv4 and IPv6 addresses, as well as permitting loading balancing of traffic by many different common ways, including multi-CDN deployments wherein load balancing can account for geography and load.
Warning:  Consider using many.
Suggested change:  "many"

Section: 1, draft text:
The Security Considerations section covers some of the negative outcomes should MUD/firewall managers and IoT manufacturers choose not to cooperate.
Warning:  If the text is a generality, 'of the' is not necessary.
Suggested change:  "some"

Section: 3.1.3, draft text:
The same is not true for reverse names: they can often be incomplete or incorrect for months or even years without visible affect on operations.
Warning:  Did you mean effect?
Suggested change:  "effect"

Section: 3.1.3, draft text:
To liimt churn of DNS PTR records, and reduce failures of the MUD ACLs, operators would want to add all possible names for each reverse name, whether or not the DNS load balancing in the forward DNS space lists that end-point at that moment.
Warning:  Consider shortening this phrase to just whether. It is correct though if you mean 'regardless of whether'.
Suggested change:  "whether"

Section: 3.1.4, draft text:
Instead a wildcard exists to answer.
Warning:  Did you forget a comma after a conjunctive/linking adverb?
Suggested change:  "Instead,"

Section: 3.1.4, draft text:
github would be unable to provision all infinity of possible names into the PTR records.
Warning:  This sentence does not start with an uppercase letter.
Suggested change:  "Github"

Section: 3.2, draft text:
The MUD controller and the device get a matching set, and the ACLs that are setup cover all possibilities.
Warning:  The verb 'set up' is spelled as two words. The noun 'setup' is spelled as one.
Suggested change:  "set up"

Section: 3.2, draft text:
The simplest is when the round robin does not return all addresses. 
Warning:  This word is normally spelled with hyphen.
Suggested change:  "round-robin"

Section: 3.2, draft text:
In addition the convenience, there is a shared fate advantage: as all three components are running on the same device, if the device is rebooted, clearing the cache, then all three components will get restarted when the device is restarted.
Warning:  Did you forget a comma after a conjunctive/linking adverb?
Suggested change:  "addition,"

Section: 4.1, draft text:
A common pattern for a number of devices is to look for firmware updates in a two step process. 
Warning:  This word is normally spelled with hyphen.
Suggested change:  "two-step"

Section: 4.1, draft text:
An initial query is made (often over HTTPS, sometimes with a POST, but the method is immaterial) to a vendor system that knows whether or not an update is required.
Warning:  Consider shortening this phrase to just whether. It is correct though if you mean 'regardless of whether'.
Suggested change:  "whether"

Section: 4.1, draft text:
An authoritative server might be tempted to provided an IP address literal inside the protocol: there are two arguments (anti-patterns) for doing this.
Warning:  Did you mean to provide?
Suggested change:  "to provide"

Section: 4.1, draft text:
A DNS name can contain both kinds of addresses, and can also contain many different IP addresses of each kind.
Warning:  Consider using many.
Suggested change:  "many"

Section: 4.2, draft text:
Even if the content provider chosen names are deterministic they may change at a rate much faster than MUD files can be updated.
Warning:  "Even if" at the beginning of a sentence requires a 2nd clause. Maybe a comma, question or exclamation mark is missing, or the sentence is incomplete and should be joined with the following sentence.

Section: 6, draft text:
It can even be done without code changes via the use of a QR code affixed to the packaging (see [RFC9238].
Warning:  Unpaired symbol: ')' seems to be missing

Section: 6.2, draft text:
While it used to be costly to have a large number of aliases in a web server certificate, this is no longer the case. 
Warning:  Specify a number, remove phrase, or simply use many or numerous
Suggested change:  "many"

Section: 6.4, draft text:
Due the problems with different answers from different DNS servers, described above, a strong recommendation is to avoid using such things.
Warning:  It appears that a preposition is missing after 'Due'.
Suggested change:  "Due to the"

Section: 7, draft text:
The use of unencrypted (Do53) requests to a local DNS server exposes the list to any internal passive eavesdroppers, and for some situations that may be significant, particularly if unencrypted WiFi is used. 
Warning:  Did you mean Wi-Fi? (This is the officially approved term by the Wi-Fi Alliance.)
Suggested change:  "Wi-Fi"

Section: 7, draft text:
Instead, details of how to query and where to get the firmware would be provided as a MUD extension, and a Enterprise-wide mechanism would retrieve firmware, and then distribute it internally. 
Warning:  Use an instead of 'a' if the following word starts with a vowel sound, e.g. 'an article', 'an hour'
Suggested change:  "an"

Regards,
Rob