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

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

Hi Michael, authors,

I’ve just re-reviewed -10.I still think that the English to be cleaned up further.  I know that the RFC editor would likely find and fix most of these, but improving the English now will likely improve the overall quality and also help the IETF LC reviewers and ADs and also save the authors work in terms of the amount of comment that comes back from the reviews.

Hence, I’ve done a full read through of -10 and my comments are below.  Please can you address all these along with checking the grammar warnings and post a -11, and then I should be able to initiate IETF LC.  As before, I’m running out of time as an AD, hence addressing these quickly makes it more likely that this will get approved by the IESG before I step down …

Minor level comments:



(1) p 2, sec 1.  Introduction



   [RFC8520] provides a standardized way to describe how a specific

   purpose device makes use of Internet resources.  Access Control Lists

   (ACLs) can be defined in an RFC8520 Manufacturer Usage Description

   (MUD) file that permit a device to access Internet resources by DNS

   name.



"specific purpose device" sounds like slight strange phrasing to me.





(2) p 2, sec 1.  Introduction



   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.



"many different common ways" sounds like strange phrasing to me.  How

can something be both different and common, which do you mean?





(3) p 2, sec 1.  Introduction



   At the MUD policy enforcement point -- the firewall -- there is a

   problem.  The firewall has only access to the layer-3 headers of the

   packet.  This includes the source and destination IP address, and if

   not encrypted by IPsec, the destination UDP or TCP port number

   present in the transport header.  The DNS name is not present!



"önly access" -> "äccess only"





(4) p 2, sec 1.  Introduction



   It has been suggested that one answer to this problem is to provide a

   forced intermediate for the TLS connections.  This could in theory be

   done for TLS 1.2 connections.  The MUD policy enforcement point could

   observe the Server Name Identifier (SNI) [RFC6066].  Some Enterprises

   do this already.  But, as this involves active termination of the TCP

   connection (a forced circuit proxy) in order to see enough of the

   traffic, it requires significant effort.



"This could in theory be done" => "In theory, this could be done", or "This could, in theory, be done".





(5) p 3, sec 1.  Introduction



   The second section of this document details how common manufacturer

   anti-patterns get in the way of this mapping.

   The third section of this document details how current trends in DNS

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



Do you really mean pathology here?





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



Perhaps just "with MUD supporting IoT devices".  Otherwise what is the difference between a general purpose IoT device and a specific purpose IoT device?





(7) p 3, sec 3.  Strategies to map names



   The most naive method is to try to map IP addresses to names using

   the in-addr.arpa (IPv4), and ipv6.arpa (IPv6) mappings.



For readability, it might be helpful to indicate when this mapping would occur.





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



Please consider whether it would read better as: "but the DNS lookup must be repeated, e.g., in a few hours or days, when the cached IP address to name binding expires."





(9) p 4, sec 3.1.2.  Reveals patterns of usage



   By doing the DNS lookups when the traffic occurs, then a passive

   attacker can see when the device is active, and may be able to derive

   usage patterns.  They could determine when a home was occupied or

   not.  This does not require access to all on-path data, just to the

   DNS requests to the bottom level of the DNS tree.



Is it worth mentioning that there are now mechanisms available (like DoH, or Ohttp that can be used to mitigate this)?





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



   In order to compensate for this, the MUD controller SHOULD regularly

   perform DNS lookups in order to never have stale data.  These lookups

   must be rate limited to avoid excessive load on the DNS servers, and

   it may be necessary to avoid local recursive resolvers.  The MUD

   controller SHOULD incorporate its own recursive caching DNS server.

   Properly designed recursive servers should cache data for many

   minutes to days, while the underlying DNS data can change at a higher

   frequency, providing different answers to different queries!



I suggest changing "for many minutes to days" to "for at least some number of minutes, up to some number of days".





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



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



Should it be "avoid in IP address literal in the URL"?  Also, inhouse => in-house.





(12) p 9, sec 4.1.  Use of IP address literals in-protocol



   Finally, third-party content-distribution networks (CDN) tend to use

   DNS names in order to isolate the content-owner from changes to the

   distribution network.

   A non-deterministic name or address that is returned within the

   update protocol, the MUD controller is unable to know what the name

   is.  It is therefore unable to make sure that the communication to

   retrieve the new firmware is permitted by the MUD enforcement point.



The first sentence above doesn't make sense to me, please can it be rephrased.





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



   The firmware vendor is therefore likely to be asked to point a CNAME

   to the CDN network, to a name that might look like "g7.a.example",

   with the expectation that the CDN vendors DNS will do all the

   appropriate work to geolocate the transfer.  This can be fine for a

   MUD file, as the MUD controller, if located in the same geography as

   the IoT device, can follow the CNAME, and can collect the set of

   resulting IP addresses, along with the TTL for each.  The MUD

   controller can then take charge of refreshing that mapping at

   intervals driven by the TTL.

   In some cases, a complete set of geographically distributed servers

   is known at ahead of time, and the firmware vendor can list all of

   those addresses in the name that it lists in the MUD file.  As long

   as the active set of addresses used by the CDN is a strict subset of

   that list, then the geolocated name can be used for the firmware

   download itself.  This use of two addresses is ripe for confusion

   however.



Where are the addresses being listed?  In the DNS or with the CDN?





(14) p 10, sec 4.3.  Use of a too generic DNS name



   Some CDNs make all customer content at a single URL (such as

   s3.amazonaws.com).  This seems to be ideal from a MUD point of view:

   a completely predictable URL.



"Make all customer content at" => "Make all customer content available at"





(15) p 11, 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 the network

   communications by their device.



Could "The remaining difficulty is now the semantic contents of what is in the MUD file." is a bit vague, could it be more precisely explained please?





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



   The ADD WG has written [I-D.ietf-add-dnr] and [I-D.ietf-add-ddr] to

   provided.



This sentence doesn't scan.





(17) p 12, sec 7.  Privacy Considerations



   The use of DoT and DoH eliminates the threat from passive

   eavesdropping, but still exposes the list to the operator of the DoT

   or DoH server.  There are additional methods, such as described by

   [RFC9230].



Perhaps "There are additional methods to help preserve privacy, such as ..."





(18) p 13, sec 7.  Privacy Considerations



   The use of DoT and DoH eliminates the threat from passive

   eavesdropping, but still exposes the list to the operator of the DoT

   or DoH server.  There are additional methods, such as described by

   [RFC9230].

   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.



Use of an Encrypted ...  is the preferred choice.







Nit level comments:



(19) p 4, sec 3.1.3.  Mappings are often incomplete



   In some cases there are multiple layers of CNAME between the original

   name and the target service name.  This is often due to a layer of

   load balancing in DNS, followed by a layer of load balancer at the

   HTTP level.



"Load balancing layer in the DNS" and "Load balancing layer at the HTTP level" would probably read better.





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



   3.  if any addresses have been omitted in a round-robin DNS process,

       the cache will have the set of addresses that were returned.



Possibly, "the same set of addresses"?





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



   The firmware vendor is therefore likely to be asked to point a CNAME

   to the CDN network, to a name that might look like "g7.a.example",

   with the expectation that the CDN vendors DNS will do all the

   appropriate work to geolocate the transfer.  This can be fine for a

   MUD file, as the MUD controller, if located in the same geography as

   the IoT device, can follow the CNAME, and can collect the set of

   resulting IP addresses, along with the TTL for each.  The MUD

   controller can then take charge of refreshing that mapping at

   intervals driven by the TTL.

   In some cases, a complete set of geographically distributed servers

   is known at ahead of time, and the firmware vendor can list all of

   those addresses in the name that it lists in the MUD file.  As long

   as the active set of addresses used by the CDN is a strict subset of

   that list, then the geolocated name can be used for the firmware

   download itself.  This use of two addresses is ripe for confusion

   however.



at ahead of time => ahead of time.  all of those => all those





(22) p 13, sec 7.  Privacy Considerations



   The use of a publically specified firmware update protocol would also

   enhance privacy of IoT devices.  In such a system the IoT device

   would never contact the manufacturer for version information or for

   firmware itself.  Instead, details of how to query and where to get

   the firmware would be provided as a MUD extension, and an Enterprise-

   wide mechanism would retrieve firmware, and then distribute it

   internally.  Aside from the bandwidth savings of downloading the

   firmware only once, this also makes the number of devices active

   confidential, and provides some evidence about which devices have

   been upgraded and which ones might still be vulnerable.  (The

   unpatched devices might be lurking, powered off, lost in a closet)



publically => publicly





(23) p 13, sec 7.  Privacy Considerations



   The use of a publically specified firmware update protocol would also

   enhance privacy of IoT devices.  In such a system the IoT device

   would never contact the manufacturer for version information or for

   firmware itself.  Instead, details of how to query and where to get

   the firmware would be provided as a MUD extension, and an Enterprise-

   wide mechanism would retrieve firmware, and then distribute it

   internally.  Aside from the bandwidth savings of downloading the

   firmware only once, this also makes the number of devices active

   confidential, and provides some evidence about which devices have

   been upgraded and which ones might still be vulnerable.  (The

   unpatched devices might be lurking, powered off, lost in a closet)



In such a system the => In such a system, the


Spellings:
inhouse,
inprotocol,
middleboxes

Grammar Warnings:

Section: 3.1.3, draft text:
To limit 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', unless you mean 'regardless of whether'.
Suggested change:  "whether"

Section: 3.1.4, draft text:
For instance, github.io, which is used for hosted content, including the Editors' copy of internet drafts stored on github, does not actually publish any names.
Warning:  The official name of this software platform is spelled with a capital "H".
Suggested change:  "GitHub"

Section: 3.1.4, draft text:
For instance, github.io, which is used for hosted content, including the Editors' copy of internet drafts stored on github, does not actually publish any names.
Warning:  The official name of this software platform is spelled with a capital "H".
Suggested change:  "GitHub"

Section: 3.1.4, draft text:
Instead a wildcard exists to answer all potential names: requests are routed appropriate once they are received.
Warning:  A comma may be missing after the conjunctive/linking adverb 'Instead'.
Suggested change:  "Instead,"

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 a hyphen.
Suggested change:  "round-robin"

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 a 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', unless you mean 'regardless of whether'.
Suggested change:  "whether"

Section: 4.1, draft text:
The current firmware model of the device is sometimes provided and then the authoritative server provides a determination if a new version is required, and if so, what version.
Warning:  Use a comma before "and" if it connects two independent clauses (unless they are closely connected and short).
Suggested change:  ", and"

Section: 4.2, draft text:
Even if the content provider chosen names are deterministic they may change at a rate much faster then MUD files can be updated.
Warning:  Did you mean faster than?
Suggested change:  "faster than"

Section: 4.2, draft text:
This use of two addresses is ripe for confusion however.
Warning:  Consider inserting a comma before 'however'.
Suggested change:  ", however"

Section: 4.3, draft text:
Exactly what the risk is depends upon what the other customers are doing: it could be limited to simply causing a distributed denial of service attack resulting in high costs to those customers, or such an attack could potentially include writing content.
Warning:  It appears that hyphens are missing.
Suggested change:  "denial-of-service"

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.5, draft text:
The ADD WG has written [I-D.ietf-add-dnr] and [I-D.ietf-add-ddr] to provided.
Warning:  The verb after "to" should be in the base form.
Suggested change:  "provide"

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"

Regards,
Rob





From: Toerless Eckert <[e-mail]>
Date: Thursday, 26 October 2023 at 23:21
To: Michael Richardson <[e-mail]>
Cc: Eliot Lear <[e-mail]>, Rob Wilton (rwilton) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08
On Thu, Oct 26, 2023 at 05:49:08PM -0400, Michael Richardson wrote:
>     > Sure, but that DNSSEC issue equally applies to TLS proxies, right ?
>     > DNSSEC is not mentioned in the docs paragraphs discussing TLS.
>
> TLS proxies do not change/break DNS(SEC).
> They "attack" at the TCP layer (in the same way NAT44 does), forcing traffic
> through their engine.

If they do, sure. I don't think that there is an actual definition that
says so, and i thought i've seen different ones as well.

> The TLS validation step is really a separate thing, and with what you
> suggested, an IP address per destination, and a circuit-layer forward proxy,
> then the device would actually be connected (at layer-4) to the real target.
> So whatever TLS certificate validation they do would just continue to work.

That was the idea. Obvious the experience from BRSKI proxy popped up reading this
thread..

>     > Of course, one could always extend MUD to explicitly allow clients
>     > to look for local-domain domain names to explicitly support TCP/UDP or TLS
>     > proxies in case such proxies are desired. TLS proxies of course still
>     > being a highly desirable option to support (likely independent of this draft),
>     > to allow the operator of the MUD devices to actually inspect the traffic
>     > between te devices the operator owns and their cloud services.
>
> I don't really understand what you are saying here.
> Yes, some people would like to inspect traffic from their IoT devices.
> Others see that as a serious risk to the device, and specifically do not want
> the liability.  Even enterprises that do forced TLS inspection are apparently
> recognizing that they MUST exempt banking and health traffic; or face serious
> legal consequences.

Once personal devices of factory floor workers start to have MUD profiles,
we can start worrying about privacy right violations in TLS proxies in the context of MUD.
I was thinking about devices for which those don't apply.

For industrial devices, especially those coming from all type of international vendors
it could easily start becoming a simple security requirement that the operator of
a factory installation must be able to verify the traffic to that (foreign) manufacturers
cloud devices. And use of standardized encoding protocols/semantics wouldn't make that
a big deal for a good application layer firewall. And provisioning LDevID so the
private key of the industrial devices can be shared with the installation firewall is certainly
possible with some enrollment protocols.

Aka: I think the actual TLS proxy case should not be dismissed as the draft currently
does. It's certainly not something one may want to recommend solely to solve the DNS
issue, but if it's required for security of the opeational deployment, then MUD should
not stand in its way. For example, if the TLS proxy just intercepts at L4 as you
say, then it seems it should actually work pretty well with SNI: The firewall
will act as TLS proxy, read the SNI, validate it, and break the connection if
not allowed by MUD.

Cheers
    Toerless
>
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>



--
---
[e-mail]