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 <[email protected]>
Date: Thursday, 26 October 2023 at 23:21
To: Michael Richardson <[email protected]>
Cc: Eliot Lear <[email protected]>, Rob Wilton (rwilton) <[email protected]>,
[email protected] <[email protected]>,
[email protected]
<[email protected]>
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 <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
--
---
[email protected]
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
