[OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-opsawg-mud-iot-dns-considerations-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 7.
   The use of a publicly 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.

Why does the use of a “publicly specified firmware update protocol” necessarily
enhance privacy?  Do all such protocols have the properties described in the
second sentence?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Chris Wood for the SECDIR review.

I support the DISCUSS position of Paul Wouters.  Judging by the title,
abstract, framing in Section 1 and the tradeoff presenting in Section 8, it
isn’t clear if this guidance is for “all IoT devices” or “only IoT devices that
support MUD”; and if this is intended for enterprise and home deployments.  In
the spirit of simplifying the adjudication of feedback, I tried my best not
duplicate points from Paul's COMMENT ballot.  Some of the points below are
further examples of this scope confusion.

** Section 1.
   In TLS 1.3, with or without the use of ECH, middleboxes cannot rely
   on SNI inspection because malware could lie about the SNI.

Can’t malware also lie about the SNI in TLS 1.2?

** Section 2.
   Although this document is not an IETF Standards Track publication, it
   adopts the conventions for normative language to provide clarity of
   instructions to the implementer.

Isn’t common for BCPs to use RFC2119 language.

** Section 3.1.3.  Who are these service providers whose role it is to maintain
reverse mappings relative to the actors I thought were in question – device
manufacturer and owner/operator?

** Section 4.1  Editorial. Is it “4.1.  Use of IP address literals inprotocol”
or “in-protocol”?

** Section 4.1.  Editorial.
  (often over
   HTTPS, sometimes with a POST, but the method is immaterial)

If is immaterial, why mention it?

** Section 4.1
   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.

What’s the authoritative server in this model?  Is it the “vendor system”
mentioned in the previous sentence?

** Section 4.1
   The first is that it eliminates problems with firmware updates that
   might be caused by lack of DNS, or incompatibilities with DNS.

I’m confused on what is the anti-pattern.  It’s acceptable for the device to
initial query the authoritative server via IP (I say acceptable because there
isn’t guidance cautioning against it), but if the authoritative server responds
back with an URI with an IP, this is a problem?

** Section 4.1
   The first is that the update service server must decide whether to
   provide an IPv4 or an IPv6 literal.  A DNS name can contain both
   kinds of addresses, and can also contain many different IP addresses
   of each kind.

Couldn’t the update service know which IP address family it was contacted over
and serve a response back in that family (in addition to including both
addresses in the HTTP API)?

** Section 4.1
   Finally, it is common in some content-distribution networks (CDN) to
   use multiple layers of DNS CNAMEs in order to isolate the content-
   owner's naming system from changes in how the distribution network is
   organized.

Understood.  Who is this a problem for?  What if the vendor doesn’t use a CDN?

** Section 4.3.  Who is this section directed at?  Based on Section 4’s title
of “DNS and IP Anti-Patterns for IoT device Manufacturers”, it seems like it is
manufacturers.  However, the text in this section seems to be discussing CDN
behavior.  Are manufacturers supposed to avoid CDNs that follow this behavior?

** Section 5.  What is the actionable BCP or design guidance from this section?

** Section 6.
   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 actual list of expected connections to put in the MUD file.
   An IoT manufacturer must now spend some time reviewing the network
   communications by their device.

How is this germane to MUD and DNS?

** Section 6.5

   Should the network provide
   such a resolver for use, then there is no reason not to use it, as
   the network operator has clearly thought about this.

Can more be said about the basis of this confidence.  I can see the rationale
in some enterprise scenario.  Section 7 makes a case for the opposite advice --
“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 Wi-Fi is used.”

** Section 7.  I found this Privacy Considerations lacking a basic explanation
of the DNS-focused threat model.  I think the start of that threat assessment
is that “many IoT devices are automatically configured to connect to the public
internet to enable automatic updates, send telemetry to the manufacturers, or
enable integration with manufacturer or third-party services”.

Using the tradeoff template of the security considerations in Section 8, a
privacy consideration trade-off might be that “device owners/operators want to
leak as little onto the internet and to the device manufacturer while still
getting the functionality of the IoT device”.

** Section 7.

   IoT devices that reach out to the manufacturer at regular intervals
   to check for firmware updates are informing passive eavesdroppers of
   the existence of a specific manufacturer's device being present at
   the origin location.

-- Is it common in an enterprise setting for IoT devices to be able to
auto-updated themselves from firmware download off the internet?  In my limited
enterprise experience, other end-points and network device are typically
managed.  Is there some nuance that these devices can only be managed the
manufacturer?

-- In an enterprise setting wouldn’t it be best practice to prevent devices
from beaconing out to the internet with DNS blackholing or IP address filters?

** Section 7.
   IoT device manufacturers are encouraged to find ways to anonymize
   their update queries.  For instance, contracting out the update
   notification service to a third party that deals with a large variety
   of devices would provide a level of defense against passive
   eavesdropping.

This is good advice.

-- Is the DNS footprint of most IoT devices predominately queries for updates? 
To revisit the previous comment about the threat model, don’t some IoT devices
use DNS to initiate traffic for more things than just update queries negating
the benefit of a third-party update infrastructure?

-- Not knowing much about this is done in production, is this realistic
guidance based on current IoT manufacturer practices?  Collecting less data
from device owner/operators seems to be opposite of the trends I have seen.