{my appologies for the lateness of this reply}
{I'm posting the new version, -14, but I think that I have some more review
comments to catch up with.}
Dave Thaler via Datatracker <nore...@ietf.org> wrote:
> Section 4.1 (Use of IP address literals inprotocol)
> This is the section I had the most problems with. It purports to give
> reasons _not_ to do this, and which is then used to justify a
recommendation
> against it in section 6.1. Let's walk through them...
> It starts with "there are two arguments (anti-patterns) _for_ doing this."
> Great. The first reason _for_ doing it is given, which makes a lot of
> sense to me. It then goes on to say:
I have rewritten this section:
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/commit/248ee9d3e23687a5fb2479e2276c3adf8f2443c8
> First, it's listed as a reason "to avoid" in the list of arguments "for"
> doing this, which doesn't make sense. Second, I don't buy this as a
> reason to avoid literals. If the update server provides URLs on demand,
> the server can ensure provide the latest URLs when needed. If the address
> is removed right after being returned, without any transition time, then
> I’d argue that something else is operationally problematic in that
network.
> But even then, if it doesn’t work, the device can just re-query the update
> server for a new URL. So I think this paragraph is a red herring, at least
> as currently phrased.
Yes, I've rewritten it.
An update protocol certainly can be created that can return multiple address
literals (v4+v6), and which always returns them from a set that is covered by
a DNS name that can be placed into a MUD file.
I think that literals should be avoided in such protocols if possible,
because it is harder to manage the TLS certificates and SNI, but that's not
an argument that MUD should make.
> only one. I might buy that an anti-pattern is that some implementations
> DO only provide one, and then the recommendation should be to fix the
> “only one” design. Bottom line: it’s not the use of literals that are
> the problem.
Fair enough, and I think my rewrite gets at this.
BTW: I first observed this with my printer firmware update.
After a trip to the https://updates.firmware.printerco.example, (easily
placed into a MUD file) it did no DNS requests that I could see, and then
happily went off with HTTP to an IP associated with some S3 bucket.
>> A third problem involves the use of HTTPS. IP address literals do
>> not provide enough context for TLS ServerNameIndicator to be useful
>> [RFC6066]. This limits the firmware repository to be a single tenant
>> on that IP address, and for IPv4 (at least), this is no longer a
>> sustainable use of IP addresses.
> So... make the use of *IPv4* literals be NOT RECOMMENDED then. (Even
> then, if the firmware image is signed and non-secret, then TLS is of
> course good but not strictly required for many classes of attack.)
> I don't believe this section has presented sufficient motivation to
> make IPv6 literals be NOT RECOMMENDED (as 6.1 tries to do), especially
> given the valid reasons _for_ doing it that are pointed out in the draft.
I couldn't tell if my printer's firmware was signed or not, alas.
I sure hope so. I agree that IPv6 makes IP-per-tenant trivial and cheap, but
are the HTTPS certificates for each one so easy? I hope my rewrite has
eliminated such harsh words.
> Finally the section concludes:
>> 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 above paragraph is really hard to follow. What is meant by
> “non-deterministic name or address”? And what does “unable to make
> sure” mean in practice?
I have rewritten that as:
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/commit/9ceb6803831b18d2206427e44d5fa913dcf81b50
When a name or address is returned within an update protocol for which a MUD
rule cannot be written, then the MUD controller is unable to authorize the
connection.
In order for the connection to be authorized, the set of names returned
within the update protocol needs to be known ahead of time, and must be from
a finite set of possibilities.
Such a set of names or addresses can be placed into the MUD file as an ACL in
advance, and the connections authorized.
> Section 4.2 (Use of non-deterministic DNS names in-protocol):
> This section seems to confuse various roles (or at least terminology).
> The first two paragraphs introduce the issue (correctly, I think)
> as not being specific to firmware updates, but really about any type
> of content the device might access. But then things get confusing...
>> Such names may be unpredictably chosen by the content provider, and
>> not the content owner, and so impossible to insert into a MUD file.
> Who is the "content owner"? Firmware image owner? Device manufacturer?
> If you have a device that (say) accesses weather information at a
> third-party site, then the MUD file is still provided by the device
> manufacturer NOT the “content owner” if the “content” is the weather data.
> Another paragraph says:
>> A solution is to use a deterministic DNS name, within the control of
>> the firmware vendor.
> Firmware updates are not the only type of content the device may access
> that section 4.2 applies to. If this paragraph is not specific to
> firmware updates, then is “firmware vendor” still the right term?
> Or should it be “device manufacturer”? (since a MUD file is a
> *M*anufacturer usage description, not a *F*irmware usage description
> (FUD))
I have rewritten this section slightly, shortened it, and made the content
more general than firmware. I added a reference to RFC6707 for CDN*
terminology, I realized that things are worse as "modern" CDNs make use of
multiple layers of 30x redirects.
please see:
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/commit/e31f3419213ce06a0869fa282b0f246de4dbe8c5
I think that there could be further improvements, but I'm not sure what to say.
> Section 6.5 (Prefer DNS servers learnt from DHCP/Route Advertisements):
>> IoT Devices SHOULD prefer doing DNS with the DHCP provided DNS servers.
> Why are DHCP-provided DNS servers preferred over RA-provided DNS servers?
> Elaborate.
That's really just an v4-ism on my part. (How embarassing)
I've added RAs as well.
>> Use of public resolvers instead of the provided DNS resolver, whether
>> Do53, DoQ, DoT or DoH is discouraged. Should the network provide
>> such a resolver for use, then there is no reason not to use it,
> See comment below about this "there is no reason" statement…
>> as the network operator has clearly thought about this.
>>
>> Some manufacturers would like to have a fallback to using a public
>> resolver to mitigate against local misconfiguration.
> Claiming “there is no reason” assumes omniscience, that no device
> manufacturer has come with any reason. Maybe some device manufacturer
> doesn’t trust local network operators and wants to hide DNS query details
> from such observers. Even the next paragraph (the last sentence quoted
> above) seems to contradict this statement by providing a potential
> reason (“to mitigate against local misconfiguration”).
There has been a great deal of tussle between what operators want and what
device makers want. Many networks rely upon observation of DNS request
patterns to deduce that there is malware present.
I've removed, "there is no reason"
> Section 7 (Privacy Considerations):
>> The use of non-local DNS servers exposes the list of names resolved
>> to a third party, including passive eavesdroppers.
> Not necessarily. If the non-local DNS server is provided by the device
> manufacturer, it’s not a third party.
That really seems a quibble to me.
>> Use of Encrypted DNS connection to a local DNS recursive
>> resolver is the preferred choice.
> This still exposes DNS names to the local network. Communication
> inherently exposes destination IP addresses (in the IP header) to the
> local network operator, but not DNS names.
That's true.
I think there is a wide variety of operational situations; I agree that in
some situations, you don't want to expose the DNS names to the local
recursive DNS operator. In such a trust-less scenario, would MUD even be
deployable? I'm thinking about work or university campuses, with bring your
own (IoT) device.
> There’s a significant
> disclosure difference when you have many names hosted at the same IP.
> Hence this should be called out as a privacy issue that some device
> manufacturers might be concerned about.
I'm not following you here.
I'm posting the new version, but I think that I have some more review
comments to catch up with. April just didn't happen for me.
https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-mud-iot-dns-considerations-13&url2=draft-ietf-opsawg-mud-iot-dns-considerations-14&difftype=--html
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
