[secdir] draft-ietf-iotops-iot-dns-guidelines-04 early Secdir review

[Stephen Farrell via Datatracker <[e-mail]>]

Document: draft-ietf-iotops-iot-dns-guidelines
Title: IoT DNS Security and Privacy Guidelines
Reviewer: Stephen Farrell
Review result: Has Issues

I marked this as "has issues" just because it's an early review and
everything at that stage has issues:-) I'd say "on the right track"
would be more accurate.

general:

- this has a lot of MUST statements that together seem over-optimistic, is
  that the right target? I wonder how many device vendors or n/w operators
  have reviewed this? (If "not many" then getting such review would seem
  like a good plan.)

- The last para of 3.7.2 seems to amount to: do s/w updates - why not say
  it that way? And make that a high level recommendation?

- I see no mention of mDNS, mightn't that be used for finding services?

specific:

- abstract: what's a management zone?

- 3.1: is the "MUST NOT fall back" to public recursives really practical or
  likely to be honoured?

- 3.1: how likely is it that DDR will be implemented?

- 3.1: the bullet list: any guidance on how often to run that recursive
  selection alg? on reboot? every day?

- 3.2: did you consider randomising the capitalization of the QNAMEs? (I
  forget if that's currently considered good or bad:-)

- 3.3: "manufs MUST configure" sounds like RFC6919 "but we know you won't"

- 3.6: Most forms of encrypted DNS implies some root store - that's maybe
  new for IoT devices, so how's it expected to work? If the answer is to
  mosly do that depending on the OS root store, that'd be ok but maybe 
  worth a mention.

- 3.6: Why not SHOULD be padded?

- 3.7: "Note that manufacturers MUST have signed public zones used for
  device management and services so that validation can take place" - that
  seems like a bogus MUST. s/MUST/need to have/ would seem more accurate.
  (Same in 4.1)

- 3.7.1: "falls back to unvalidated queries" seems wrong, aren't those
  unvalidated answers? 

- 3.7.2: wouldn't the additional DNS traffic be an issue for some devices?

- 3.7.2: the DNSSEC trust anchor is easy enough, compared to the root
  store for DoT/DoH. Seems odd to mention the easy one and not the
  hard one.

- 5.2: MUD could do with a reference.