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

[Michael Richardson <[e-mail]>]

Rob Wilton (rwilton) <[e-mail]> wrote:
    > 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).

okay.

    > 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.

https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/issues/4

    > (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

fixed.

    > (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.

https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/issues/4

    > (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.

https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/issues/6

    > (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?

https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/issues/7

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

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

changed.
I'm not sure that generic is correct, but I agree it is closer to general understanding.

    > (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?

Yeah, the /DoH is missing, and has been added.
It's that a *local* DoT/DoH is preferred.

    > (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.

Done.

    > (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, ..."

fixed.

    > (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.

Well, I want to push back here on what we suggest and where.
We can make all sorts of security suggestions, but this document is about
DNS, not general network security.  And actually unencrypted WiFi is not a
problem if you are using DoT/DoH!    "Encrypted" Wifi through coffee-shop
WPA-PSK is subject to trivial on-path attacks that allow for active
eavesdropping.  I don't think this document should go there.

    > (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".

I said large for a reason: refridgerators do not move, while a small
counter-top coffee maker might be loaned to neighbours or taken to/from office.

    > (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."

I'm using your text, but the reason I said "advance" is that it the situation
needs to be considered when writing the code, planning the software updates,
and exactly how DNS names are going to be used.   This needs to be done by
the IoT vendor.

    > 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

fixed.

    > (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.

No, it's not hours or days, it's >hours <days.
(Also: it's mutually exclusive: hours xor days)
I think that my text is correct.

    > (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

fixed.

    > (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."

fixed.

    > (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

fixed.

    > (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

fixed.

    > (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

fixed

    > (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

fixed.

    > (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"

Fixed as you suggest.

    > (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"

fixed.

    > (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".

fixed.

    > (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 ..."

fixed.
upper-case Third? I don't think so.

    > (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 ...

fixed.

    > (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."

ok

    > (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

fixed.

    > (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

fixed

    > (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

fixed.

    > (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.


ok.

    > (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?

agreed.

    > (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.

fixed.

    > (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, ...)

fixed.

    > (34) p 13, sec 8.  Security Considerations

    > This document deals with conflicting Security requirements:

    > Security => security

i loaded it all into Google Docs, which does pretty well with markdown, and
used it to check this all.


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [