Hi Michael, A few comments/clarifications inline ...
> -----Original Message----- > From: Michael Richardson <[email protected]> > Sent: Wednesday, October 18, 2023 4:37 PM > To: Rob Wilton (rwilton) <[email protected]> > Cc: [email protected]; [email protected] > 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 [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
