[dnsdir] draft-ietf-iotops-iot-dns-guidelines-01 early Dnsdir review

[Patrick Mevzek via Datatracker <[e-mail]>]

Document: draft-ietf-iotops-iot-dns-guidelines
Title: IoT DNS Security and Privacy Guidelines
Reviewer: Patrick Mevzek
Review result: Almost Ready

Hi,

I have been selected as the DNS Directorate reviewer for this draft. The
DNS Directorate seeks to review all DNS or DNS-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the ADs.
For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir

I don't think the draft is ready as it stands, while not being maybe very far
from it. I didn't check on the specific working group mailing list if there
were already discussions on the draft. I didn't read the research paper,
either. Sorry in advance if I am repeating points already raised.

Here are my comments in a loosely decreasing order of importance (from
“showstoppers” to “I don't understand fully/Could be clearer” and then
“nitpicks”):

— Generic comment: the title says “guidelines” but then the document uses “BCP”
a lot of times; I don't think IETF BCPs are written by referencing themselves
as BCP, since this “status” comes only at publication time (and if for some
reason the BCP status is not achieved, then the document reads all strange); I
don't know the IETF process close enough, but maybe there is a need to
specifically request to be published as a BCP, if that is the goal. Also, the
first mention of BCP (in “While the recommendations in this BCP”) outside IETF
boilerplate is not expanded to be explained.

— Generic comment: related to above, I am confused by various paragraphs that
mention RFCs but don't actually give “guidelines” at all, saying things like
“device manufacturers should consider the benefits and any impact of using
this.” (for example, for the “serve stale” part). This is very vague and high
level, so looks more like “List of stuff to look around” than actionable
examples (like possible positive or negative impacts to study) and guidelines.

— I find it a bit strange to have “Security” right in the title of the
document, but basically an empty Security Considerations section. I don't think
only protocol changes have security impact. If nothing else, there should be at
least a short paragraph summarizing again why the application of above
guidelines given will increase security (and possibly clearly explaining
impacts on security of device, impacts on security of network around the
device, and impacts on the DNS zones and resolution process used by the IoT
devices using these guidelines).

— “the maximum packet size SHOULD be set to 1220 bytes as a default”. Why 1220?
2020 DNS Flag Day (https://www.dnsflagday.net/2020/) recommended everyone to
switch to 1232. But otherwise maybe reference RFC 9715 which deals with
fragmentation and recommends 1400, and by doing so you avoid having to chose
and hardcode any value yourself.

— subjective and maybe just me, but by reading the abstract and then all the
document, it was never 100% clear to me if the goal was to define security for
the IoT device itself, for the, supposedly manufacturer of said IoT device
controlled network security, or for security at large of any Internet resource
based on that device behavior. It seems to me each part is touched by the
document somehow. Also, as for structure, since all these RFCs cited are
everywhere in the document, maybe consider have a list of them in a specific
section summarizing quickly how they relate to IoT devices and a one sentence
summary of what to get from them in this context?

— “stub resolver” is introduced very early, but not explained. Probably
reference RFC 9499 on DNS Terminology, and specifically §6. I see RFC 9499
mentioned later (“DNS terminology in this draft conforms to RFC 9499.” but
strangely that RFC is not listed in references?) and then stub resolver
explained, but I believe the order should be swapped so that you define stub
resolver even before going into the bullet points of §1. Also, I don't think
Stub Resolver and Server needs uppercases (or else, they should be there for
all occurrences). Some global uniformity could be goal too as later we have
“Configuration of DNS servers” but immediately after “DNS resolvers” so I think
it would be better to choose once for all “DNS server” or “DNS resolver” and
use it accordingly everywhere (otherwise it might always bring the questioning
if those are 2 different things or not?)

— “The first one that results in a discovered service should be selected.”
Seems a big vague for me. What does “discovered service” exactly mean? Getting
at least one working reply? What does “first one” also exactly means,
considering multiple servers can be defined for each case?

— “IoT devices do not typically have security agents installed on them”: what
are “security agents”? No examples given (which would make it easier to
understand why IoT devices don't have them contrary to generic computers, I
guess?). Agents securing against what? Same remark later in §4 about “security
software agents”.

— in §3.2 I am not sure of the usefulness and clarity of the end with “to
ensure Source Port randomization and Transaction ID randomization as required
by [RFC1035].”, specifically since RFC1035 doesn't talk at all about
randomization

— in §3.3 “In case of unsuccessful resolution, such as when the resolver is
unavailable, IoT devices should implement exponential back-off strategies.”
could be improved I think, because “unsuccessful resolution” could be either no
reply or negative reply, and in later case the negative TTL should apply.
RFC9520 details all cases of “unsuccessful” and maybe could be referenced here?
(§3.2 of it mention backoff).

— in §3.5 not sure why serve stale is mentioned here because it is obviously
about serving data, so it applies to a plain resolver, not a stub one. This is
again mentioned, and then correctly placed I think, in §4.3

— in §3.6, not sure about “for enhanced privacy, security, and compatibility.”
after mentioning DoT/DoQ/DoH… privacy of? The IoT device? Compatibility about
what and between what?

— “In addition, IoT devices MUST support using TCP for queries when a TC bit is
returned from the resolver [RFC1035].” this seems to me to imply that TCP is
only for those cases, where the initiator should be free to use UDP or TCP at
anytime (and has to use TCP for case of TC=1), so relax things to allow TCP for
any case?

— §3.7.2 “Devices will need to be shipped with a root trust anchor and have a
mechanism to securely update this”. No mention of RFC5011 for automated updates
of root anchors?

— in §3.7.2 last sentence seems basically to tell “do 3.7.1 instead”, and if
so, that advice seems to me better in 3.7 before detailing the options.

— in §4.2: “Manufacturer Usage Descriptions (MUDs)” is mentioned without
explanations of what it is or reference about it, yet the capitalization and
acronym makes it look like as something widespread/well-known/obvious.

— Not sure, but shouldn't at least the following “should” be IETF “SHOULD”
instead: * “IoT devices should implement exponential back-off strategies.” *
“Devices should cache results including intermediate validation results to
reduce repeated computation” * “As described in Section 3.7 resolvers should be
configured to validate DNS responses using DNSSEC.” * “Network operators should
implement DNS Response Rate Limiting (RRL) on resolvers to mitigate high query
volumes from devices causing DoS to the DNS infrastructure.”

— nit: “mitigating the risks identified in this draft” s/draft/document/ or
similar — nit: “may apply to all DNS stub resolver behavior” no plural? — nit:
“The BCP is primarily concerned” s/The/This/ ? — “For example the
implementation of {#configuring-resolvers} and Section 3.2”: missing/wrong
reference for the {} part? — maybe better phrasing: “For example the
implementation […] would be appropriate to any implementation,” to reduce
duplication of implementation? — nit: “When Encrypted resolver options” the RFC
referenced, RFC9463 has either “encrypted resolver” (no uppercase) or
“Encrypted DNS Option” (all uppercase), I recommend picking either of the terms
from the RFC — nit (consistency): “If the stub-resolver has this capability”
please choose between “stub resolver” (13 occurrences) and “stub-resolver” (10
occurrences) across the whole document — nit (layout): broken bullet points
after “IoT stub-resolvers may adopt one of two models for validation:” — nit:
§3.7.2 “Device stub-resolvers can perform validation themselves” why the plural?