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
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
