Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Michael,

A few comments/clarifications inline ...

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Wednesday, October 18, 2023 4:37 PM
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08
> 
> 
>     > (10) p 12, sec 7.  Privacy Considerations
> 
>     > The use of DoT and DoH eliminates the minimizes threat from passive
>     > eavesdropped, but still exposes the list to the operator of the DoT
>     > or DoH server.  There are additional methods, such as described by
>     > [I-D.pauly-dprive-oblivious-doh].
>     > 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, assuming that the trust anchor for
>     > the local DNS server can be obtained, such as via
>     > [I-D.reddy-add-iot-byod-bootstrap].
> 
>     > Presumably there should also be a recommendation to use encrypted WiFi
> too.
> 
> Well, I want to push back here on what we suggest and where.
> We can make all sorts of security suggestions, but this document is about
> DNS, not general network security.  And actually unencrypted WiFi is not a
> problem if you are using DoT/DoH!    "Encrypted" Wifi through coffee-shop
> WPA-PSK is subject to trivial on-path attacks that allow for active
> eavesdropping.  I don't think this document should go there.
[Rob Wilton (rwilton)] 
Okay.


> 
>     > (11) p 12, sec 7.  Privacy Considerations
> 
>     > While possession of a Large (Kitchen) Appliance at a residence may be
>     > uninteresting to most, possession of intimate personal devices (e.g.,
>     > "sex toys") may be a cause for embarrassment.
> 
>     > Not sure whether the example is needed here, but don't object if you
>     > want to keep it.  I would change "Large (Kitchen) Appliance" to just
>     > "kitchen appliance".
> 
> I said large for a reason: refridgerators do not move, while a small
> counter-top coffee maker might be loaned to neighbours or taken to/from
> office.
[Rob Wilton (rwilton)] 
Okay.


> 
>     > (12) p 13, sec 8.  Security Considerations
> 
>     > This document takes the view that the two requirements do not need to
>     > be in conflict, but resolving the conflict requires some advance
>     > planning by all parties.
> 
>     > Rather than "requires some advance planning by all parties", perhaps
>     > "requires careful planning on how the DNS can be safely and effectively
>     > used by MUD controllers and IOT devices."
> 
> I'm using your text, but the reason I said "advance" is that it the situation
> needs to be considered when writing the code, planning the software updates,
> and exactly how DNS names are going to be used.   This needs to be done by
> the IoT vendor.
[Rob Wilton (rwilton)] 
Okay.  Maybe "careful design and planning on how"?

> 
>     > (14) 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.
> 
>     > hours to days => hours or days.
> 
> No, it's not hours or days, it's >hours <days.
> (Also: it's mutually exclusive: hours xor days)
> I think that my text is correct.
[Rob Wilton (rwilton)] 
I think that your text is hard to comprehend, as is your explanation ;-)

You first comment seems to suggest that the range is between 1 hours and 23 hours, but your second comment suggests it can be X hours or Y days.



> 
>     > (24) p 8, sec 4.1.  Use of IP address literals in-protocol
> 
>     > Third-party content-distribution networks (CDN) tend to use DNS names
>     > in order to isolate the content-owner from changes to the
>     > distribution network.
> 
>     > I suggest "Finally, Third-party content-distribution ..."
> 
> fixed.
> upper-case Third? I don't think so.
[Rob Wilton (rwilton)] 
Yes, "Finally, third-party ..."

> 
>     > (34) p 13, sec 8.  Security Considerations
> 
>     > This document deals with conflicting Security requirements:
> 
>     > Security => security
> 
> i loaded it all into Google Docs, which does pretty well with markdown, and
> used it to check this all.
[Rob Wilton (rwilton)] 
Okay.  Thanks.

I presume you will post (or point to an updated version of the doc) once you have text for the other issues that you have flagged as github issues.

Regards,
Rob


> 
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [